| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <trinity-760989cf-0ea4-496a-9992-02ed85a5ffe5-1409039594977@3capp-gmx-bs38> Date: Tue, 26 Aug 2014 09:53:15 +0200 From: "Fedor Babkin" <fedor.babkin@....net> To: "Julian Anastasov" <ja@....bg> Cc: netdev@...r.kernel.org Subject: Aw: Re: Routes with unreachable gateways are staying in the routing table and they are functional Hello Julian, Thanks for your feedback. For IPv4 the situation is clear, you have to configure more that one subnet to the interface in order to start experiencing this issue. However exactly the same issue exists in IPv6, where once you configure a single address, you have to count on effectively having 2 addresses on the interface, due to the presence of a link-local address fe80::xxxx. Moreover with IPv6 stateless address autoconfiguration (RFC 4862), there is more address configuration dynamics in IPv6 comparing to IPv4. I would say this issue has a higher visibility and side-effect potential. Is there anyone looking into this issue from IPv6 perspective? Thanks, Fedor Hello, On Fri, 22 Aug 2014, Fedor Babkin wrote: > Hello, > > I noticed that in case a network interface has two addresses assigned (no matter if IPv4 or IPv6) from subnets A and B, the route to reach subnet C via the gateway in A is staying configured and functional when subnet A is removed from the interface. Let me illustrate the behavior with IPv4 example. > > Starting point. eth0 has 2 subnets, the route to reach 3-rd subnet via gw in one of them is present: > eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 > link/ether 52:54:00:12:34:57 brd ff:ff:ff:ff:ff:ff > inet 10.20.10.3/24 brd 10.20.10.255 scope global eth0 > valid_lft forever preferred_lft forever > inet 10.30.10.3/24 brd 10.30.10.255 scope global eth0 > valid_lft forever preferred_lft forever > inet6 fe80::5054:ff:fe12:3457/64 scope link > valid_lft forever preferred_lft forever > root@...ntu14-4-vm:~# ip ro ls > 10.11.10.0/24 via 10.30.10.1 dev eth0 > 10.20.10.0/24 dev eth0 proto kernel scope link src 10.20.10.3 > 10.30.10.0/24 dev eth0 proto kernel scope link src 10.30.10.3 > > Delete 10.30.10.3/24, the indirect route persists: > root@...ntu14-4-vm:~# ip ro ls > 10.11.10.0/24 via 10.30.10.1 dev eth0 > 10.20.10.0/24 dev eth0 proto kernel scope link src 10.20.10.3 > > Ping to destinations in 10.11.10.0/24 works, unreachable gateway 10.30.10.1 is resolved, even recovers in case of neighbor flushes. > root@...ntu14-4-vm:~# ping 10.11.10.1 > PING 10.11.10.1 (10.11.10.1) 56(84) bytes of data. > 64 bytes from 10.11.10.1: icmp_seq=1 ttl=64 time=0.706 ms > root@...ntu14-4-vm:~# ip n l > 10.30.10.1 dev eth0 lladdr 52:54:00:12:34:56 REACHABLE > > The above was observed with kernel version 2.6.32 and confirmed with 3.13.0 In case of IPv6 this behavior is more disturbing as there is always LLA assigned, so applications have to orchestrate the removal of unreachable routes. > If it's an intended implementation, would be helpful to know a reason behind it. Thanks for your support. It is expensive to implement solution for this problem. If we try to be very strict by handling it at FIB level (catch route removal) simple operations like secondary address promotion or route replacement can lead to cascade of route removals. At the end, it is again the user who have to take care to add all lost routes back. So, it is a complex task to solve. Here is recent discussion on such topic: http://marc.info/?t=139030500700005&r=1&w=2 http://marc.info/?t=139055890700002&r=1&w=2 Regards -- Julian Anastasov -- Gesendet: Freitag, 22. August 2014 um 18:28 Uhr Von: "Julian Anastasov" <ja@....bg> An: "Fedor Babkin" <fedor.babkin@....net> Cc: netdev@...r.kernel.org Betreff: Re: Routes with unreachable gateways are staying in the routing table and they are functional Hello, On Fri, 22 Aug 2014, Fedor Babkin wrote: > Hello, > > I noticed that in case a network interface has two addresses assigned (no matter if IPv4 or IPv6) from subnets A and B, the route to reach subnet C via the gateway in A is staying configured and functional when subnet A is removed from the interface. Let me illustrate the behavior with IPv4 example. > > Starting point. eth0 has 2 subnets, the route to reach 3-rd subnet via gw in one of them is present: > eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 > link/ether 52:54:00:12:34:57 brd ff:ff:ff:ff:ff:ff > inet 10.20.10.3/24 brd 10.20.10.255 scope global eth0 > valid_lft forever preferred_lft forever > inet 10.30.10.3/24 brd 10.30.10.255 scope global eth0 > valid_lft forever preferred_lft forever > inet6 fe80::5054:ff:fe12:3457/64 scope link > valid_lft forever preferred_lft forever > root@...ntu14-4-vm:~# ip ro ls > 10.11.10.0/24 via 10.30.10.1 dev eth0 > 10.20.10.0/24 dev eth0 proto kernel scope link src 10.20.10.3 > 10.30.10.0/24 dev eth0 proto kernel scope link src 10.30.10.3 > > Delete 10.30.10.3/24, the indirect route persists: > root@...ntu14-4-vm:~# ip ro ls > 10.11.10.0/24 via 10.30.10.1 dev eth0 > 10.20.10.0/24 dev eth0 proto kernel scope link src 10.20.10.3 > > Ping to destinations in 10.11.10.0/24 works, unreachable gateway 10.30.10.1 is resolved, even recovers in case of neighbor flushes. > root@...ntu14-4-vm:~# ping 10.11.10.1 > PING 10.11.10.1 (10.11.10.1) 56(84) bytes of data. > 64 bytes from 10.11.10.1: icmp_seq=1 ttl=64 time=0.706 ms > root@...ntu14-4-vm:~# ip n l > 10.30.10.1 dev eth0 lladdr 52:54:00:12:34:56 REACHABLE > > The above was observed with kernel version 2.6.32 and confirmed with 3.13.0 In case of IPv6 this behavior is more disturbing as there is always LLA assigned, so applications have to orchestrate the removal of unreachable routes. > If it's an intended implementation, would be helpful to know a reason behind it. Thanks for your support. It is expensive to implement solution for this problem. If we try to be very strict by handling it at FIB level (catch route removal) simple operations like secondary address promotion or route replacement can lead to cascade of route removals. At the end, it is again the user who have to take care to add all lost routes back. So, it is a complex task to solve. Here is recent discussion on such topic: http://marc.info/?t=139030500700005&r=1&w=2 http://marc.info/?t=139055890700002&r=1&w=2 Regards -- Julian Anastasov -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists