This is not exactly true. The modern Linux kernel (2.6) uses some amount
of flow tracking in order to do route caching. You can check this out on
your system by:
"ip route show cache"
Okay...
# ip route show cache
ip: Command not found.
It keeps track of Src/Dst/QoS/Ethernet adapters/etc.. Additionally most
systems have the iptables modules loaded in kernel and the conntrack
module in kernel. This immediately activates connection tracking,
therefore considerably slowing down software routing. The most optimal
way of speeding this up would be sticking the route cache into somewhat
faster memory. Though it would be fairly nice to get rid of the route
cache as that can cause problem with eccentric setups. Also, as cache
entries take a moment to be deleted, or degrade leading to convergence
times being higher.Note .. to .. self .. Linux .. makes .. crappy .. router. Got it.
Guess we'll continue to use FreeBSD, and the lesson to come away with
is that it probably pays to avoid technologies that are suboptimal
for the task at hand. Not everything is created equal. It also pays
to tune things. If "conntrack" hurts, then remove it.
You can use Linux without conntrack. You can either do "rmmod
ip_conntrack" (unload the module), rm /var/lib/modules/ip_conntrack
(or something like that to erase the file) or use the RAW queue to
forward some packets without connection tracking (-j NOTRACK) and some
others with conntrack (proxy redirection, captive portal and thinks
like that requires stateful forwarding in any platform).
I would be more worried about the prefix match and route cache done by
the operating system you are considering for use as a router. That
cannot be circunverted by turning off conntrack, pf or anything that
might do more with the packet that plain simple routing.
Rubens
Rubens Kuhl Jr. wrote:
You can use Linux without conntrack. You can either do "rmmod
ip_conntrack" (unload the module), rm /var/lib/modules/ip_conntrack
(or something like that to erase the file) or use the RAW queue to
forward some packets without connection tracking (-j NOTRACK) and some
others with conntrack (proxy redirection, captive portal and thinks
like that requires stateful forwarding in any platform).I would be more worried about the prefix match and route cache done by
the operating system you are considering for use as a router. That
cannot be circunverted by turning off conntrack, pf or anything that
might do more with the packet that plain simple routing.
Hi,
As of 2.6.x kernel version (at least on 2.6.17) there is a FIB implementation called LC_Trie which supposedly does an O(1) route lookup which is very fast.
Where I live there are a lot of linux boxes deployed as routers pushing line rate GE for hundreds to thousand nodes computer networks while also deliverying QoS for each and every node.
From what I see in this thread you're more worried about T3/E3 linecards than the actual Linux performance as a router.
As a personal example, I use a celeron 2.53Ghz with 512Mb of ram to push line rate 3 x 100Mbps cards wihout any discernable load reported either by top or uptime and that on top of Quagga with about ~ 5k prefixes.
Also, as an experiment I loaded a full routing table from one of my peers and besides of the increased RAM usage by Quagga to about 50MB the machine forwarded at the same rate, _maybe_ 1% incresed load.