[ppml] Technical reason why /52,/56,/60,/64 are bad

Christopher Morrow christopher.morrow at gmail.com
Sun Aug 19 21:46:33 EDT 2007

just a quick clarifying note (not to michael so much as eventually robin)

On 8/19/07, michael.dillon at bt.com <michael.dillon at bt.com> wrote:

> > problems.  These high end routers use trie-based algorithms
> > involving lookups into gigabytes of slow, shared, DRAM. This
> > can only be done some number of bits at a time, where that
> > number may by 5 to probably 20 or maybe 24 at the absolute maximum.

Actually the normal DFZ sorts of devices as listed below will have to
do lookups to a full 32 bits on many occasions... I suspect the
trie-based lookups (and tcam lookups) are able today to do at least 32
bit lookups.

In some cases the lookups actually are longer still as most of the
DFZ-type routers implement ACL's via the route-table. So some TCAM
based routers will use 'spare bits' in the tcam entry to cover
port/protocol, some TCAM based routes are able to do 64+ bits of
lookup actually since they can do in a single pass src and dest
lookups (to do both acls and uRPF functionality).

I suspect that the DRAM lookup type routers also have 64+ bits of
lookup since they can do src/dest ip and port/protocol for acl
functionality and uRPF.

> > This sounds really inefficient, compared to IPv4 in which DFZ
> > routers in practice need to look at 24 bits, at most, of the
> > destination address of IPv4 packets.  Since only about 1.23%
> > of the advertised space is for prefixes of 21 bits or more:

In practice they actually need more than 24 bits, see above and
consult your local vendor. The DFZ is not made up of just /24 and
larger routes :(


More information about the ARIN-PPML mailing list