From: Joe Buehler <hidden> Date: 2011-03-01 14:58:06
I have a LINUX box talking on many different networks at the same time. Since
IP addresses on the networks can overlap (they are completely different
networks) we use source routing and NAT to get packets going in and out of the
right interfaces.
Everything works great, with one exception. If I try to talk to a remote host
that happens to have the same IP address as one of my interfaces, the kernel
routes the packet to the local interface.
It looks to me as though the problem is that the source routes are lower
priority than the local interfaces. As soon as the kernel sees a destination
address that matches a local interface it routes to the local interface and pays
no attention to the source route.
I consider this a bug. Is there any way to change this behavior?
The kernel involved is 2.6.27.7, with patches from Cavium for support of their
hardware.
Joe Buehler
From: Chris Friesen <hidden> Date: 2011-03-01 19:07:26
On 03/01/2011 08:57 AM, Joe Buehler wrote:
I have a LINUX box talking on many different networks at the same time. Since
IP addresses on the networks can overlap (they are completely different
networks) we use source routing and NAT to get packets going in and out of the
right interfaces.
Everything works great, with one exception. If I try to talk to a remote host
that happens to have the same IP address as one of my interfaces, the kernel
routes the packet to the local interface.
It looks to me as though the problem is that the source routes are lower
priority than the local interfaces. As soon as the kernel sees a destination
address that matches a local interface it routes to the local interface and pays
no attention to the source route.
I consider this a bug. Is there any way to change this behavior?
How exactly do you expect it to handle this case? You've explicitly
told your host that its address is X, so why would it expect to find
that address assigned to another machine on the network? Suppose you
have an app listening on INADDR_ANY, and it gets a packet from that
adddres--how does it know whether the packet is destined to the local
machine or the remote one?
If you really want to modify things, have you looked at your ip rules?
"ip ru" will dump them. Typically it looks something like
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
The last item in each row is the name of the routing table. As you can
see, the first rule is for local interfaces, and a later rule deals with
the main and default routing tables.
You could move the local lookup to rule 1 and add in a new rule 0
specifically dealing with your situation.
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
From: Joe Buehler <hidden> Date: 2011-03-01 19:46:23
If you really want to modify things, have you looked at your ip rules?
"ip ru" will dump them. Typically it looks something like
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
The last item in each row is the name of the routing table. As you can
see, the first rule is for local interfaces, and a later rule deals with
the main and default routing tables.
You could move the local lookup to rule 1 and add in a new rule 0
specifically dealing with your situation.
We have tried some variations on modifications to ip rules, but the
kernel appears to treat rule 0 specially -- it cannot be deleted, for
example. This results in the enforcing of local interfaces before
source routes -- surely something that should be a policy decision, not
hard-coded.
Let me rephrase and ask: Does anyone know how to replace the priority 0
rule?
Joe Buehler
From: Ben Greear <hidden> Date: 2011-03-02 18:55:18
On 03/01/2011 11:31 AM, Joe Buehler wrote:
quoted
If you really want to modify things, have you looked at your ip rules?
"ip ru" will dump them. Typically it looks something like
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
The last item in each row is the name of the routing table. As you can
see, the first rule is for local interfaces, and a later rule deals with
the main and default routing tables.
You could move the local lookup to rule 1 and add in a new rule 0
specifically dealing with your situation.
We have tried some variations on modifications to ip rules, but the
kernel appears to treat rule 0 specially -- it cannot be deleted, for
example. This results in the enforcing of local interfaces before
source routes -- surely something that should be a policy decision, not
hard-coded.
Let me rephrase and ask: Does anyone know how to replace the priority 0
rule?
You can do this on more modern kernels (2.6.36 and later definately works..not sure
about earlier).
ip rule add pref 512 lookup local
ip rule del pref 0 lookup local
Thanks,
Ben
Joe Buehler
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Joe Buehler <hidden> Date: 2011-06-09 16:35:34
Ben Greear wrote:
You can do this on more modern kernels (2.6.36 and later definately
works..not sure
about earlier).
ip rule add pref 512 lookup local
ip rule del pref 0 lookup local
The kernel change for this in later kernels was simple enough -- there
is a flag that prevents deletion of the "local" table rule, just remove
the flag. Here is a patch for 2.6.24.7. The patch for 2.6.27.7 (I am
using both versions) is almost the same.