LARTC - Mar 2007 - BUG? re-ordering of tos routes in table

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

* 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