It seems like tos should be considered when sorting routes on insertion. Consider this out-of-order route creation: # ip route add 1.1.0.0/24 table 3 nexthop via 192.168.0.23 # ip route add 1.1.0.1/32 table 3 nexthop via 192.168.0.24 # ip route show table 3 1.1.0.1 via 192.168.0.24 dev eth3 1.1.0.0/24 via 192.168.0.23 dev eth3 ok... it's re-ordered the routes - it makes sense, the host route would have been masked by the net route, but what about this: # ip route add 1.1.0.0/24 tos 0x15 table 3 nexthop via 192.168.0.23 # ip route add 1.1.0.1/32 table 3 nexthop via 192.168.0.24 # ip route show table 3 1.1.0.1 via 192.168.0.24 dev eth3 1.1.0.0/24 tos 0x15 via 192.168.0.23 dev eth3 The routes as record will route all 1.1.0.1 traffic to 192.168.0.24 when it should only route non tos 0x15 traffic to 192.168.0.24 It strikes me that the re-ordering that seems to be based on netmask size should occur only in a larger ordering by tos, with tos of zero appearing last. i.e. when inserting routes, sort by descending order of tos and then by descending order of netmask size. For the last case this would give: 1.1.0.0/24 tos 0x15 via 192.168.0.23 dev eth3 1.1.0.1 via 192.168.0.24 dev eth3 as tos 0x0 (any) appears last. Sam _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
