linux-admin.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: Policy routing problem
@ 2012-10-25  9:25 Christoph Pleger
  2012-10-25 10:38 ` Giles Coochey
  0 siblings, 1 reply; 13+ messages in thread
From: Christoph Pleger @ 2012-10-25  9:25 UTC (permalink / raw)
  To: linux-admin

Hello,

> If there any particular reason why you have the DHCP server on the same
> subnet as your DHCP clients?

Routers do not forward broadcast messages to other broadcast domains.

Regards
  Christoph

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Policy routing problem
@ 2012-10-25 12:57 Christoph Pleger
  0 siblings, 0 replies; 13+ messages in thread
From: Christoph Pleger @ 2012-10-25 12:57 UTC (permalink / raw)
  To: linux-admin

Hello,

> I tried to set the correct IP address with
> SNAT, but it seems that SNAT refuses to use the same port where some
> application is listening on. So, if I use "iptables -t nat -A POSTROUTING
> ... --to-source 129.217.14.81:67", nothing is sent, in contrast to other
> ports.

For some experiments, I added an iptables-rule, so that the mark is not
only set if the source port is bootps, but also if the destination port is
bootpc. And now, I am completely confused, because I found out that though
there is a relation between the port I use in "iptables -t nat ..." and if
a message is sent, there must also be another reason why messages are not
sent with this kind of NAT. When a DHCP client sends a unicast request to
port bootps, the DHCP unicast reply is never sent when I use port 67 in
SNAT. But when I use netcat sessions in a command line on the DHCP server
to send messages to port bootpc of a client, messages are sent in some
netcat sessions, but in other sessions, they do not, no matter which port
I use in SNAT. Maybe the OS sometimes decides that the port is already in
use and refuses to send messages from that port?

Regards
  Christoph

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Policy routing problem
@ 2012-10-25  9:23 Christoph Pleger
  0 siblings, 0 replies; 13+ messages in thread
From: Christoph Pleger @ 2012-10-25  9:23 UTC (permalink / raw)
  To: linux-admin

Hello,

>If you create separate routing tables you must
>duplicate to it the same device routes as you have in main for these
>interfaces or/and play with src option.

Ok, somehow that works without making too many problems, but I would
really like to find a solution that simulates these device routes only if
the source port is 67.

In the meanwhile, I found out that my solution with for example "ip rule
add fwmark 114 table 114", "ip route add to 129.217.14.0/24 dev eth1.114
table 114" and "iptables -t mangle -A OUTPUT -p udp --source-port bootps
-d 129.217.14.0/24 -j MARK --set-mark 114" works in so far that unicast
DHCP replies are sent from the same device where the request came in, but
still the wrong IP is used. This does not change when I use a specific
source address in "ip route". I tried to set the correct IP address with
SNAT, but it seems that SNAT refuses to use the same port where some
application is listening on. So, if I use "iptables -t nat -A POSTROUTING
... --to-source 129.217.14.81:67", nothing is sent, in contrast to other
ports.

Regards
  Christoph

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Policy routing problem
@ 2012-10-23 15:14 Christoph Pleger
  2012-10-24 13:40 ` Oleg
  0 siblings, 1 reply; 13+ messages in thread
From: Christoph Pleger @ 2012-10-23 15:14 UTC (permalink / raw)
  To: linux-admin

> Are you have real tagged vlan interfaces or by vlan you mean an interface
> aliases (where multiple IP exists on one interface)?

I have real VLAN interfaces, but one of these interfaces has two IPs
(there are two Vservers in that subnet).

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Policy routing problem
@ 2012-10-23 11:05 Christoph Pleger
  2012-10-23 11:27 ` Oleg
                   ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Christoph Pleger @ 2012-10-23 11:05 UTC (permalink / raw)
  To: linux-admin

Hello,

I am running a DHCP-Server that serves multiple subnets. The server has
an IP address in all of these subnets, and its primary IP address in a
subnet that is not served by DHCP. Every IP address has its own VLAN
Ethernet interface, eth0.102, eth0.104, etc. In this setup, the DHCP
server often does not send its unicast replies on the interface where it
received the corresponding request, but on the interface of its primary
IP address, and with that IP. My first thought how to change this was by
setting routes depending on destination addresses, but this would cause
big problems with other services running on the same machine, so I tried
to combine iproute2 and iptables, like this:

iptables -t mangle -A OUTPUT -p udp --source-port bootps \
   -d xxx.xxx.22.0/24 -j MARK --set-mark 122

ip route add to xxx.xxx.22.0/24 dev eth0.122 table 122

ip rule add fwmark 122 table 122

Though I can see in my logs that iptables really sets that mark, routing
does not work as expected and the server still uses its primary IP address
for sending unicast DHCP replies.

What am I doing wrong and what must be done to achieve the desired
behaviour?

Regards
  Christoph



^ permalink raw reply	[flat|nested] 13+ messages in thread
end of thread, other threads:[~2012-10-25 12:57 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-25  9:25 Policy routing problem Christoph Pleger
2012-10-25 10:38 ` Giles Coochey
  -- strict thread matches above, loose matches on Subject: below --
2012-10-25 12:57 Christoph Pleger
2012-10-25  9:23 Christoph Pleger
2012-10-23 15:14 Christoph Pleger
2012-10-24 13:40 ` Oleg
2012-10-23 11:05 Christoph Pleger
2012-10-23 11:27 ` Oleg
2012-10-23 13:23   ` Christoph Pleger
2012-10-23 14:47     ` Oleg
2012-10-23 12:16 ` Jimmy Thrasibule
2012-10-23 14:14   ` Christoph Pleger
2012-10-24 14:27 ` Giles Coochey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).