[LARTC] Re: BUG? re-ordering of tos routes in table

[Amin Azez <azez@ufomechanic.net>]

* Amin Azez wrote, On 13/03/07 11:01:
> 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
>   
perhaps not... it would cause:

# ip route add 1.1.0.1/32 table 3 nexthop via 192.168.0.24
# ip route add 1.1.0.0/24 tos 0x15 table 3 nexthop via 192.168.0.23
# ip route show table 3

to result in (with tos 0 (any) last)

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

Which again is not what is wanted.

The conditions when route-creation order trumps subnet size seem to be:
1. that non-0-tos smaller subneted routes can't be automatically moved before any     0-tos route whose subnet contains the smaller subnet.
2. that     0-tos smaller subneted routes can't be automatically moved before any non-0-tos route whose subnet contains the smaller subnet.

because in both cases the tos mismatch would cause the smaller subnet to steal packets belonging to the other route, by virtue of route-creation order, which otherwise would result in sequences that could not easily be specified.

However this may result in islands of 0-tos, non-0-tos, 0-tos in the table that don't get merged in some cases because of the particular subnets in use but do in others. 

There is a simpler solution... not to use tos in a table at all, but relegate it solely to rules; or not to use tos in tables in such cases (being where tos is intended to trump subnet size ordering).

Sam

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc