[j-nsp] TCAM full on EX8200?

[Jeff Wheeler]

On Fri, Oct 14, 2011 at 3:52 AM, Michele Bergonzoni <bergonz at labs.it> wrote:
> can only be done with TCAM. For those who want more info on this issue, this
> is the very interesting reference that I received in a private email:
>
> http://www.firstpr.com.au/ip/sram-ip-forwarding/

I wouldn't use that particular document as a "reference."

On Fri, Oct 14, 2011 at 6:08 AM, Phil Mayers <p.mayers at imperial.ac.uk> wrote:
> On that topic; I'm familiar with how TCAM can be used to accelerate routing
> lookups, but less so with SRAM. Is the SRAM used to implement a "simple"

A CAM electronically searches all of its rows for matches at the same
time.  It is relatively expensive in terms of power/heat.  It has
never been a particularly smart way of doing many kinds of look-up
operations.  It is useful is when the data set is small, the size of
the rows / number of bits to search is fairly large, and distribution
of keys is basically random.  This is why CAM is used for Ethernet
switching, TLB in microprocessors, etc.

When your data set grows, like the DFZ, it is less expensive to have
an ordinary RAM and search algorithm.  Which particular kind of RAM is
in use is not all that exciting, but in routers that use some kind of
tree search, you can find all manner of SRAM and DRAM.

There has been some mention about TCAM being good at ACL matching.  It
can take a whole lot of ALU operations and RAM accessing to figure out
if a given packet should pass an ACL or not, and this is especially
true if you have those long ACLs blocking or allowing a ton of TCP
ports, etc.  At some point, it still becomes cheaper to implement ACL
with an ALU and RAM than with a TCAM.

The reason vendors do not want to do this is the TCAM can evaluate a
very large ACL in one step, while a ALU+RAM might be more
power-efficient, if you have a ACL with hundreds of entries, it will
take a long time to process packets, and you will not have wire speed
performance anymore, on packets trying to compare against that big
ACL.  Predictable performance is important and it is a lot easier to
predict the performance of a CAM/TCAM (because it is simple) than of
other methods.  From the operator's perspective, you don't want to
hear that you might lose wire speed forwarding if you have more than
17 ACL entries unless the optimizer figures out a clever way to
install them into the memory in which case 80 entries might work just
fine.  You just want your ACLs to work.

Of course, Juniper does do ACL with ALU+RAM in most boxes, and so you
can indeed create this problem for yourself.  This is often not
obvious until you have a few millions PPS passing through a filter
that it cannot optimize into anything clever.

It is nice to understand how your routers work at a deeper level.
More often than not, though, all it will do is make you wonder how a
given product ever shipped or make you angry that you can't just get
an MPLS P box for the same price as an Ethernet switch.  :-)

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts