Well, content addressable memory is great, but as we've said, it has some
limits that
are going to make it only applicable for layer two lookups.
Again, MAC addresses, this is a great fit.
We absolutely love using it for MAC addresses.
But what about the need to use a mask?
Again, I can't use a cam for a routing table lookups, otherwise I'd have to
have every
single IP address from a /32 perspective in my routing table.
It just wouldn't work.
We need the ability to use masks and cam doesn't support that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We need the ability to use masks and cam doesn't support that.
And so instead, we're going to look at a new type of memory known as "tournary"
content
addressable memory or "tournary cam" usually abbreviated as "tcam".
So just like with cam, this is going to be built on high speed memory.
It's actually a little bit expensive or very expensive depending on our point
of relationship
there.
But either way, we understand this is going to be high speed and expensive and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But either way, we understand this is going to be high speed and expensive and
therefore
it's also going to be limited.
We might actually run out of tcam space on our switches.
So we have to be very careful with how we allocate things from a tcam
perspective.
Now what exactly is "tournary cam"?
I mean, what does "tournary" even mean?
Well, this word "tournary" is a really fancy way of trying to say "three".
So just like "binary" has the root word in there, "bi" by that is in reference WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So just like "binary" has the root word in there, "bi" by that is in reference
to the
word "to", meaning we have a zero and a one as options, well "tournary" is
saying that
we have a third option.
So what is that third option?
Well, we have a zero, we have a one, and we have what we might call just an "x
".
And this "x" is saying that we do not care.
So if I'm for example going to search for something like this where I've got,
we'll
just use a handful of bits here, zero one, "xx1", zero. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
just use a handful of bits here, zero one, "xx1", zero.
Well those "x"s mean I don't care and just like when we think about it from a
perspective
of network subnet, or rather subnet masks on the rounding side, now that we're
using
a T-cam here, we can actually match several entries.
So for example, this would match against zero one, zero zero one zero, zero one
zero, zero
one one zero, as long as the first two bits and the last two bits match, then WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
one one zero, as long as the first two bits and the last two bits match, then
we are good
to go because we simply don't care about these two bits here in the middle.
They can be truly anything, whereas these other ones must match perfectly, and
we see
that they do.
So this entry here actually will match against four different addresses.
This is how we use the concept of masks when we're performing our table lookup. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is how we use the concept of masks when we're performing our table lookup.
And so when it comes to the breakdown for T-cam and how exactly it works, we're
going
to find that we have this VMR concept.
So it's going to have the idea here that we've got value for V, we've got our
mask for M,
and we have the result.
So we see now I'm actually providing two different concepts here, the value and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we see now I'm actually providing two different concepts here, the value and
the
mask, and this is what I receive.
I receive the result.
Another important aspect of ternary cam besides simply being high speed, and
therefore again
expensive, which is why it gets to be a little bit limited there, but either
way, another
value of this is it allows for parallel processing or parallel lookups.
With cam, I had to go through and look at every single entry until I find a
match, and
I just have to go sequentially until that match is found. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I just have to go sequentially until that match is found.
With T-cam, I can actually perform parallel lookups, meaning I can actually
look up different
bits at the same time.
And so that's going to make it go even faster, which is important when we
consider what we
use T-cam to accomplish.
And so what exactly do we use T-cam for on our devices?
Well, there's actually three main elements that we're going to expect to see
that we're
using T-cam for. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
using T-cam for.
One of which is simply IPv4 and IPv6 routing.
This is going to be one of the most important aspects to it.
As we're installing routes into our, well, what we'll find is the forwarding
information
base later, then each of these routes is going to tie up T-cam space, meaning
that we, the
larger the routing table, the more likely we are to start to run out of our T-
cam.
So we have to be careful on that of that when we're using lower end routing
platforms, which
might come with less T-cam space. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
might come with less T-cam space.
But we're also going to find that Cisco devices use T-cam for access control
lists, as well
as our QOS configurations, our class maps and our policy maps, which also apply
matching
and masks.
So all of these are going to utilize T-cam.
And so when we're talking about getting a result back, I mean, what exactly are
we receiving?
Well, we might get a next hop back.
If we're checking a route, if we're performing an access control list check, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we're checking a route, if we're performing an access control list check,
well, we might
get an allow or a deny result.
That might be what we're storing for that particular match.
And finally, with QOS, we might get information on what Q to place the packet
into.
And so there's all kinds of different results that we're going to receive back
from these
checks, but we see we're providing a value and a mask up front in order to look
and find
out what the result is going to be.
And that makes sense given these specific use cases. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that makes sense given these specific use cases.
And we also see how binary cam simply wouldn't work for any of these.
We've mentioned a few times that we might need to concern ourselves with T-cam
space.
This does tend, again, to be limited on a per-platform basis.
We'll have some platforms, especially higher-end platforms that have a lot of T
-cam and some
lower-end devices that have less T-cam space.
And we might have to manage that.
So the way Cisco does this is we get so much total T-cam space and then they WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the way Cisco does this is we get so much total T-cam space and then they
divide this
up into regions for us.
Namely, we're going to get a lot of it reserved for our routing and then some
amount of it
reserved for our ACLs and our QOS.
For a lot of our organizational deployments, the default settings are going to
be good
enough.
But in some cases, we might need to expand and move these boundaries around,
increasing
the amount of routing space, for example, which would decrease the amount of
ACL and QOS space, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ACL and QOS space,
or vice versa if we need to.
This especially gets to be a concern when we have IPv6 on the table.
If we have large IPv6 routing domains, then our T-cam space is going to get a
little more
difficult to manage.
And that's a lot to do with the fact that IPv6 routes consume two different T-
cam slots,
or twice what a normal routing or ACL or QOS entry would require.
And so that's just simply because IPv6 addresses are so large that we're going WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so that's just simply because IPv6 addresses are so large that we're going
to require additional
space based on how T-cam space was originally carved up.
So something to keep in mind, different platforms will have different ways of
managing these
regions.
Some of them have templates that we can select.
Some of them require these templates for IPv6 because IPv4 and IPv6 are going
to be two
separate spaces.
So if we're going to enable IPv6, we might actually have to dedicate that space
to T-cam WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to T-cam
before we can even enable it.
Again, totally depending on the platform.
But let's keep in mind what ternary-cam is, where it's used, and how exactly we
can
manage it on our Cisco devices.