netdev - Route flush on linkdown: physical vs virtual/stacked interfaces

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <184D23435BECB444AB6B9D4630C8EC8303C541C9@XMB-RCD-303.cisco.com>
Date:	Tue, 17 Apr 2012 12:33:46 -0500
From:	"Christian Benvenuti (benve)" <benve@...co.com>
To:	<netdev@...r.kernel.org>
Subject: Route flush on linkdown: physical vs virtual/stacked interfaces

When we assign an IP address to an interface, the kernel
configures a number of routes:
- /32 for the configured IP address
- /32 for the broadcast/s (two of them)
- /netmask for the network
The /32 generated routes go to the LOCAL table, and
the /netmask route goes to the MAIN table.
OK.

When you ifconfig down an interface, the kernel removes
the /netmask route from the MAIN table but keeps the /32
routes in the LOCAL table.
The same happens when there is a link down event on the same
interface.
And this is fine.

However, software/stacked devices (like vlan and bridges) behave
differently with regards to linkdown events:

- let's assume we assigned an IP address to a vlan interface
  # vconfig add eth0 100
  # ifconfig eth0.100 10.0.1.1 netmask 255.255.255.0

- when you ifconfig down the (physical) interface sitting
  below the vlan interface (eth0 in the above example), the
  kernel removes all the routes previously generated by
  the above vlan interface IP address configuration (ie, both
  the /32 routes and the /netmask route).

- However, when there is a linkdown event for the lower
  interface (again eth0 in the above example), the kernel
  does not remove any of the routes associated with the vlan
  interface. 

The same happens for example with a bridge if I enslave only
one NIC and I ifconfig down the latter.

The result is that the /netmask route derived from the vlan
interface ip config remains in the routing table and becomes
a black hole.
Applications will (hopelessly) use it instead of, for
example, receiving a "network is unreachable" kind of error
message or using an alternate route.

Since latest net-next still behaves this way, is this behavior
wanted or is this a bug?

/Chris

--
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