Re: 3.0: unexpected route cache entry for wrong segment?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Le jeudi 09 février 2012 à 21:02 +0400, Michael Tokarev a écrit :
> Hello.
> I'm observing a situation when just one single IP
> address from entirely different segment gets routed
> locally as if it were in a directly-connected network.
> Here's how.  The short version, to show the idea, first:
> A host with single eth0 interface and single IP address
> (not counting loopback interface):
> $ ip addr
> 8: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
>     link/ether 52:54:c0:a8:b1:02 brd ff:ff:ff:ff:ff:ff
>     inet scope global eth0
> $ ip route
> default via dev eth0
> dev eth0  proto kernel  scope link  src
> $ ip neigh
> ...
> dev eth0 lladdr 00:90:27:30:6d:1c REACHABLE
> dev eth0 lladdr 38:60:77:25:3f:95 REACHABLE
> dev eth0  FAILED
> dev eth0 lladdr 52:54:c0:a8:b1:15 REACHABLE
> The address in question is this -- it should
> not be tried on locally connected ethernet segment, but instead
> should go to the (default) gateway at
> This machine is running 3.0.18 kernel.  The gateway (also
> running this kernel) can access the IP in question just fine
> (it is 2 hops away from the gateway, not reachable directly
> neither from the gw nor from the machine in question).
> After some searching we found a very very similarly looking
> issue:
>   "Unable to flush ICMP redirect routes in kernel 3.0+"
> with a good reproducer:
> The issue however is that, in our case, I can't reproduce
> this problem at all using the way described by Ivan Zahariev
> in the last message: sending redirects from the geateay for
> "random" addresses does not make corresponding "persistent"
> cache entries, once the route on the gw gets removed, that
> IP address starts working again from the machine in question.
> So now we have only one IP address that behaves like this,
> and I can't get other addresses to repeat its behavour.
> The problem appeared suddenly, while the network was in
> use.
> What is also interesting here is that the gateway should
> never send a redirect like that because it has explicit
> route for that network pointing to entirely different
> machine.
> I can work around the _current_ problem we're facing by
> moving the host in question ( to another
> IP address.  But I'd love to understand what's going on
> here.
> Also, it appears that the patch that emerged from the
> mentioned discussion hasn't been released in any
> stable kernels so far - is there some issue with it?
> And since I can't reproduce the issue here as described
> above, I've one more question: should it be reproducible?
> And finally, here's some more details about our setup.
> It is actually a "bit" more complex, involving bridges,
> vlans, veth and tap devices.
> The "host" in question is a lxc guest on veth interface.
> Its veth iface is connected to a bridge "tls-br" on the
> host.  I'm omiting some details still (like other lxc
> guests which have very similar config, and also kvm
> guests with tap interfaces).
>  host$ ip addr
>  2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
>      link/ether 00:1f:c6:ef:e5:1b brd ff:ff:ff:ff:ff:ff
>  3: tls-vlan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master tls-br state UP
>      link/ether 00:1f:c6:ef:e5:1b brd ff:ff:ff:ff:ff:ff
>  4: tls-br: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
>      link/ether 00:1f:c6:ef:e5:1b brd ff:ff:ff:ff:ff:ff
>      inet brd scope global tls-br
>  9: veth-tsrv: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master tls-br state UP qlen 1000
>      link/ether 5e:e8:4f:67:80:17 brd ff:ff:ff:ff:ff:ff
> tls-br connects tls-vlan@eth0 and veth-tsrv.  It has an
> address from the same 192.168.177/26 segment as the guest
> in question.
>  host$ ip route
>  default via dev tls-br
> dev tls-br  proto kernel  scope link  src
>  (this is a complete routing table, there's no more routes)
> What is also very interesting is that this problem with
> this single IP address affects ALL lxc machines on this
> host at once, and the host itself:
>  host$ ip neigh
> dev tls-br lladdr 6c:f0:49:9d:f2:0c STALE
> dev tls-br  FAILED
> dev tls-br lladdr 38:60:77:25:3f:9c STALE
> dev tls-br lladdr 00:90:27:30:6d:1c DELAY
>  ...
> (after trying to ping it).
> Each "subdivision" on this host has its own arp table, but
> every subdivision (host itself or any of it lxc guests which
> all have similar config) always tries to reach thiis very
> IP address directly.
>  otherLXCguest$ ip n
> dev eth0  INCOMPLETE
> dev eth0 lladdr 00:1f:c6:ef:e5:1b STALE
> dev eth0 lladdr 00:90:27:30:6d:1c DELAY
> So.. it looks like something does not work right across
> namespaces.
> Any clue what's going on?
> Thank you!

Did you try to apply by hand commits :

7cc9150ebe8ec06cafea9f1c10d92ddacf88d8ae   // added in 3.2
(route: fix ICMP redirect validation)

(ipv4: fix redirect handling)

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Linux Kernel Discussion]     [Ethernet Bridging]     [Linux Wireless Networking]     [Linux Bluetooth Networking]     [Linux Networking Users]     [VLAN]     [Git]     [IETF Annouce]     [Linux Assembly]     [Security]     [Bugtraq]     [Photo]     [Singles Social Networking]     [Yosemite Information]     [MIPS Linux]     [ARM Linux Kernel]     [ARM Linux]     [Linux Virtualization]     [Linux Security]     [Linux IDE]     [Linux RAID]     [Linux SCSI]     [Free Dating]

Add to Google Powered by Linux