On Friday 2008-07-04 02:19, James King wrote: >> >> -N table5 >> -N table6 >> -A table5 -d 10.10.96.2 -j ROUTE --dev eth2 >> -A table5 -j ROUTE --via 10.10.96.1 --dev eth0 # default route! >> -A table6 -j ROUTE --via 10.11.96.1 --dev eth1 # also a default >> -A ROUTING -m mark --mark 5 -j table5 >> -A ROUTING -m mark --mark 6 -j table6 > >Wouldn't this break with normal routing concepts, since xtables >traverses the chain linearly, while routing lookups use longest prefix >match (most specific route wins)? Very well observed. However, - the kernel is likely to do a linear rule list search (in `ip ru l`) too, because I would not imagine how you could optimize _that_ more than Xtables when it has to compare src/dst addresses, fwmarks, etc. - you are right, the *routing* table is sorted by longest prefix, and that is probably why people tout it as "optimized for the case". But I would not see anything wrong with the user doing the sorting (or even Xtables). (Maybe I just want a new command-line interface for routing instead of a new in-core architecture...) > IOW, unless xtables automatically >inserted the rule into the correct spot in the chain (as opposed to >just appending to the end of the chain like -A implies), you could run >into situations where specifying the rules out of order would send the >packet to the wrong next-hop. Or you could actually optimize it. If, say 95% of all your packets go out on eth0, the following route table (which is dependent upon cabling), with its ordering, is suboptimal: 192.168.1.1/32 dev isp0 192.168.1.0/24 dev eth0 Relaxing the longest-prefix ordering would mean less traversal time through the chains (i.e. minimizing the time taken for routing table traversal for randomly distributed packets, but weighted according to network situation, over a given time period.) -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
