<> ted .
<> Thomas D. Nadeau <tdnadeau @
<> >"qj" == Quentin Johnson <quent .
<> >>What is the packet filtering overhead for a router?
<> >>qj> I've heard people mention that access lists impose a significant
<> >>qj> overhead; the box is so much faster than 56Kbps or T1 speeds that
<> >>qj> it doesn't matter.
<> > They do. Most access list lookups are not implemented in
<> >most efficient ways. Even those implemented using hash table lookups,
<> >still require the added overhead of the hash function calculation.
<> >Some routers implement a filter caching feature, which does speed
<> >things up a bit, but there is still a performance penalty, especially
<> >if the packets continually come from different locations which will
<> >break the cache.
<> This is precisely the problem you encounter trying to test performance.
<> To my knowledge, there is no multi-vendor test that has ever been
<> performed that tests more than weeny-level policies. Cache sizes are
<> typically 256 or 512 filters, and hashes can contain thousands of
<> filters. This is the level of testing you need to drive towards to
<> really determine how different products perform.
<> If anyone is interested in hosting a test, I'll get NSC involved.
<> - Ted
Other overhead/performance issues that I have noted is the order
in which the entries occur in the router access control list.
(at least this was true a year ago last time I did real testing
on the Cisco IGS)...
Since the accept or deny occurs on the first match for each
packet, you should order the list (which is sequentially processed)
by most often used (sent/rcvd) packets to the least often. So,
your most often used services don't have to wait for each packet
to go through a hundred other tests against the ACL before the
packet is forwarded.
I don't have qunatifiable stats. on how much this effects performance,
but logic would dictate that it is relevant.
/__,_ _ o ____ /_ __. __ Robert Bryan Reinhardt
/_) (_</_<_/ / <_/ /_(_/|_/ (_ @tomahawk.welch.jhu.edu