Pascal Hambourg wrote: > Bob Proulx a écrit : > > OT Rant: It annoys me that recent Linux kernels reverse the order of > > the route lines. Previously it would have been scanned from top to > > bottom and the first line matching wins. But now it is upside down > > and must be scanned from bottom to top. > > Can you please elaborate ? In Linux 2.6.32 in Debian Squeeze 6 the kernel would print the route table in normal order. That is the same order as Unix and BSD did. (Example from a laptop with a vpn and some interesting routes for the example.) $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 172.27.61.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 192.168.240.0 172.27.61.1 255.255.255.0 UG 0 0 0 tun0 192.168.224.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 192.168.230.0 172.27.61.1 255.255.255.0 UG 0 0 0 tun0 0.0.0.0 192.168.224.1 0.0.0.0 UG 0 0 0 wlan0 $ ip route show 172.27.61.1 dev tun0 proto kernel scope link src 172.27.61.4 192.168.240.0/24 via 172.27.61.1 dev tun0 192.168.224.0/24 dev wlan0 proto kernel scope link src 192.168.224.102 192.168.230.0/24 via 172.27.61.1 dev tun0 default via 192.168.224.1 dev wlan0 When determining a route for any particular network packet you can look at this as a table from top to bottom. That is convenient and matches normal human brain thinking. Let's say I am sending a ping to a device on my local subnet 192.168.224.10. First try to match against 172.27.61.1. No match. Then try against 192.168.240.0/24. No match. Then try against 192.168.224.0/24. Yes. Matched. Send the packet directly to wlan0 on the local subnet. Let's say I am sending a ping to www.debian.org on address 128.31.0.51. I would try to match against the first line with 172.27.61.1 (a host route). No match. Then try to match against 192.168.240.0/24, then 192.168.224.0/24, then 192.168.230.0/24. No matches. Then match against "default". Yes, match, send the packet to the interface indicated. But on Linux 3.2.0 in Debian Wheezy 7 the Linux kernel has reversed the order that it prints this output. This is a simpler set of routes but as you can see they are reversed in order from previously. $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.240.1 0.0.0.0 UG 0 0 0 eth0 192.168.240.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 $ ip route show default via 192.168.240.1 dev eth0 192.168.240.0/24 dev eth0 proto kernel scope link src 192.168.240.12 If on this machine I were to ping www.debian.org on address 128.31.0.51 I first have to mentally start at the bottom of the list and attempt a match against 192.168.240.0/24 first and then try to match against the top entry second. If you start matching at the top you would wrongly send all packets to the default interface. So on newer Linux systems I say that the printed display is upside down and we have to mentally match entries from bottom to top now. Of course this is just the display for human understanding. The programmed code in the kernel does what it does at machine speed and efficiency. It isn't upside down there. It is just the display. In the kernel it doesn't matter what order it is displayed to the user. But for me as a user trying to understand the routing configuration I find the new reversed ordering to be less nice than the former. When trying to explain and teach how networking and routing works to newbies this just adds additional noise and confusion to the problem. Also the former is how Unix and BSD and other systems have always displayed it. Linux is now different for no good reason. Bob P.S. I know I can pipe through tac to reverse the output. But I shouldn't have to do so. And this doesn't work nicely for 'route' which has headers. $ ip route show | tac 192.168.230.0/24 dev br0 proto kernel scope link src 192.168.230.119 default via 192.168.230.1 dev br0
Attachment:
signature.asc
Description: Digital signature