On Fri, Oct 14, 2011 at 3:52 AM, Michele Bergonzoni <[email protected]> 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 <[email protected]> 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 <[email protected]> Sr Network Operator / Innovative Network Concepts _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
