WEBVTT 1 00:00.000 --> 00:05.360 Well, content addressable memory is great, but as we've said, it has some 2 00:05.360 --> 00:06.000 limits that 3 00:06.000 --> 00:09.060 are going to make it only applicable for layer two lookups. 4 00:09.060 --> 00:12.320 Again, MAC addresses, this is a great fit. 5 00:12.320 --> 00:15.100 We absolutely love using it for MAC addresses. 6 00:15.100 --> 00:17.240 But what about the need to use a mask? 7 00:17.240 --> 00:22.890 Again, I can't use a cam for a routing table lookups, otherwise I'd have to 8 00:22.890 --> 00:23.640 have every 9 00:23.640 --> 00:28.200 single IP address from a /32 perspective in my routing table. 10 00:28.200 --> 00:29.200 It just wouldn't work. 11 00:29.200 --> 00:33.840 We need the ability to use masks and cam doesn't support that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 11 00:29.200 --> 00:33.840 We need the ability to use masks and cam doesn't support that. 12 00:33.840 --> 00:40.330 And so instead, we're going to look at a new type of memory known as "tournary" 13 00:40.330 --> 00:40.680 content 14 00:40.680 --> 00:47.320 addressable memory or "tournary cam" usually abbreviated as "tcam". 15 00:47.320 --> 00:51.920 So just like with cam, this is going to be built on high speed memory. 16 00:51.920 --> 00:56.720 It's actually a little bit expensive or very expensive depending on our point 17 00:56.720 --> 00:57.720 of relationship 18 00:57.720 --> 00:58.720 there. 19 00:58.720 --> 01:02.260 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 19 00:58.720 --> 01:02.260 But either way, we understand this is going to be high speed and expensive and 20 01:02.260 --> 01:02.800 therefore 21 01:02.800 --> 01:05.120 it's also going to be limited. 22 01:05.120 --> 01:08.600 We might actually run out of tcam space on our switches. 23 01:08.600 --> 01:12.420 So we have to be very careful with how we allocate things from a tcam 24 01:12.420 --> 01:13.440 perspective. 25 01:13.440 --> 01:15.280 Now what exactly is "tournary cam"? 26 01:15.280 --> 01:17.280 I mean, what does "tournary" even mean? 27 01:17.280 --> 01:23.400 Well, this word "tournary" is a really fancy way of trying to say "three". 28 01:23.400 --> 01:30.440 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 28 01:23.400 --> 01:30.440 So just like "binary" has the root word in there, "bi" by that is in reference 29 01:30.440 --> 01:30.760 to the 30 01:30.760 --> 01:36.120 word "to", meaning we have a zero and a one as options, well "tournary" is 31 01:36.120 --> 01:36.600 saying that 32 01:36.600 --> 01:38.680 we have a third option. 33 01:38.680 --> 01:39.840 So what is that third option? 34 01:39.840 --> 01:45.720 Well, we have a zero, we have a one, and we have what we might call just an "x 35 01:45.720 --> 01:45.840 ". 36 01:45.840 --> 01:53.480 And this "x" is saying that we do not care. 37 01:53.480 --> 01:57.660 So if I'm for example going to search for something like this where I've got, 38 01:57.660 --> 01:58.080 we'll 39 01:58.080 --> 02:04.840 just use a handful of bits here, zero one, "xx1", zero. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 39 01:58.080 --> 02:04.840 just use a handful of bits here, zero one, "xx1", zero. 40 02:04.840 --> 02:08.800 Well those "x"s mean I don't care and just like when we think about it from a 41 02:08.800 --> 02:09.640 perspective 42 02:09.640 --> 02:15.290 of network subnet, or rather subnet masks on the rounding side, now that we're 43 02:15.290 --> 02:15.800 using 44 02:15.800 --> 02:19.480 a T-cam here, we can actually match several entries. 45 02:19.480 --> 02:25.800 So for example, this would match against zero one, zero zero one zero, zero one 46 02:25.800 --> 02:26.040 zero, zero 47 02:26.040 --> 02:33.600 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 47 02:26.040 --> 02:33.600 one one zero, as long as the first two bits and the last two bits match, then 48 02:33.600 --> 02:34.480 we are good 49 02:34.480 --> 02:40.240 to go because we simply don't care about these two bits here in the middle. 50 02:40.240 --> 02:45.700 They can be truly anything, whereas these other ones must match perfectly, and 51 02:45.700 --> 02:46.040 we see 52 02:46.040 --> 02:47.240 that they do. 53 02:47.240 --> 02:55.520 So this entry here actually will match against four different addresses. 54 02:55.520 --> 03:02.480 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 54 02:55.520 --> 03:02.480 This is how we use the concept of masks when we're performing our table lookup. 55 03:02.480 --> 03:07.750 And so when it comes to the breakdown for T-cam and how exactly it works, we're 56 03:07.750 --> 03:08.000 going 57 03:08.000 --> 03:11.480 to find that we have this VMR concept. 58 03:11.480 --> 03:19.340 So it's going to have the idea here that we've got value for V, we've got our 59 03:19.340 --> 03:21.000 mask for M, 60 03:21.000 --> 03:24.200 and we have the result. 61 03:24.200 --> 03:30.020 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 61 03:24.200 --> 03:30.020 So we see now I'm actually providing two different concepts here, the value and 62 03:30.020 --> 03:30.360 the 63 03:30.360 --> 03:33.360 mask, and this is what I receive. 64 03:33.360 --> 03:37.760 I receive the result. 65 03:37.760 --> 03:42.010 Another important aspect of ternary cam besides simply being high speed, and 66 03:42.010 --> 03:42.840 therefore again 67 03:42.840 --> 03:46.190 expensive, which is why it gets to be a little bit limited there, but either 68 03:46.190 --> 03:46.920 way, another 69 03:46.920 --> 03:55.040 value of this is it allows for parallel processing or parallel lookups. 70 03:55.040 --> 03:59.320 With cam, I had to go through and look at every single entry until I find a 71 03:59.320 --> 03:59.920 match, and 72 03:59.920 --> 04:03.200 I just have to go sequentially until that match is found. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 72 03:59.920 --> 04:03.200 I just have to go sequentially until that match is found. 73 04:03.200 --> 04:07.250 With T-cam, I can actually perform parallel lookups, meaning I can actually 74 04:07.250 --> 04:08.200 look up different 75 04:08.200 --> 04:10.560 bits at the same time. 76 04:10.560 --> 04:14.690 And so that's going to make it go even faster, which is important when we 77 04:14.690 --> 04:15.760 consider what we 78 04:15.760 --> 04:18.360 use T-cam to accomplish. 79 04:18.360 --> 04:23.360 And so what exactly do we use T-cam for on our devices? 80 04:23.360 --> 04:28.290 Well, there's actually three main elements that we're going to expect to see 81 04:28.290 --> 04:29.080 that we're 82 04:29.080 --> 04:30.720 using T-cam for. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 82 04:29.080 --> 04:30.720 using T-cam for. 83 04:30.720 --> 04:36.800 One of which is simply IPv4 and IPv6 routing. 84 04:36.800 --> 04:39.880 This is going to be one of the most important aspects to it. 85 04:39.880 --> 04:43.470 As we're installing routes into our, well, what we'll find is the forwarding 86 04:43.470 --> 04:44.120 information 87 04:44.120 --> 04:49.440 base later, then each of these routes is going to tie up T-cam space, meaning 88 04:49.440 --> 04:50.840 that we, the 89 04:50.840 --> 04:54.370 larger the routing table, the more likely we are to start to run out of our T- 90 04:54.370 --> 04:54.800 cam. 91 04:54.800 --> 04:58.830 So we have to be careful on that of that when we're using lower end routing 92 04:58.830 --> 04:59.760 platforms, which 93 04:59.760 --> 05:03.800 might come with less T-cam space. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 93 04:59.760 --> 05:03.800 might come with less T-cam space. 94 05:03.800 --> 05:08.870 But we're also going to find that Cisco devices use T-cam for access control 95 05:08.870 --> 05:09.920 lists, as well 96 05:09.920 --> 05:15.130 as our QOS configurations, our class maps and our policy maps, which also apply 97 05:15.130 --> 05:15.720 matching 98 05:15.720 --> 05:17.280 and masks. 99 05:17.280 --> 05:21.400 So all of these are going to utilize T-cam. 100 05:21.400 --> 05:24.370 And so when we're talking about getting a result back, I mean, what exactly are 101 05:24.370 --> 05:25.400 we receiving? 102 05:25.400 --> 05:28.960 Well, we might get a next hop back. 103 05:28.960 --> 05:33.270 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 103 05:28.960 --> 05:33.270 If we're checking a route, if we're performing an access control list check, 104 05:33.270 --> 05:34.200 well, we might 105 05:34.200 --> 05:37.960 get an allow or a deny result. 106 05:37.960 --> 05:41.480 That might be what we're storing for that particular match. 107 05:41.480 --> 05:46.600 And finally, with QOS, we might get information on what Q to place the packet 108 05:46.600 --> 05:47.240 into. 109 05:47.240 --> 05:50.260 And so there's all kinds of different results that we're going to receive back 110 05:50.260 --> 05:50.760 from these 111 05:50.760 --> 05:55.720 checks, but we see we're providing a value and a mask up front in order to look 112 05:55.720 --> 05:56.400 and find 113 05:56.400 --> 05:59.240 out what the result is going to be. 114 05:59.240 --> 06:02.320 And that makes sense given these specific use cases. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 114 05:59.240 --> 06:02.320 And that makes sense given these specific use cases. 115 06:02.320 --> 06:06.320 And we also see how binary cam simply wouldn't work for any of these. 116 06:06.320 --> 06:11.280 We've mentioned a few times that we might need to concern ourselves with T-cam 117 06:11.280 --> 06:12.000 space. 118 06:12.000 --> 06:15.400 This does tend, again, to be limited on a per-platform basis. 119 06:15.400 --> 06:20.050 We'll have some platforms, especially higher-end platforms that have a lot of T 120 06:20.050 --> 06:20.800 -cam and some 121 06:20.800 --> 06:24.000 lower-end devices that have less T-cam space. 122 06:24.000 --> 06:26.360 And we might have to manage that. 123 06:26.360 --> 06:31.650 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 123 06:26.360 --> 06:31.650 So the way Cisco does this is we get so much total T-cam space and then they 124 06:31.650 --> 06:32.640 divide this 125 06:32.640 --> 06:35.200 up into regions for us. 126 06:35.200 --> 06:39.770 Namely, we're going to get a lot of it reserved for our routing and then some 127 06:39.770 --> 06:40.600 amount of it 128 06:40.600 --> 06:44.680 reserved for our ACLs and our QOS. 129 06:44.680 --> 06:48.870 For a lot of our organizational deployments, the default settings are going to 130 06:48.870 --> 06:49.320 be good 131 06:49.320 --> 06:50.320 enough. 132 06:50.320 --> 06:54.610 But in some cases, we might need to expand and move these boundaries around, 133 06:54.610 --> 06:55.360 increasing 134 06:55.360 --> 06:59.810 the amount of routing space, for example, which would decrease the amount of 135 06:59.810 --> 07:01.520 ACL and QOS space, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 135 06:59.810 --> 07:01.520 ACL and QOS space, 136 07:01.520 --> 07:04.040 or vice versa if we need to. 137 07:04.040 --> 07:07.560 This especially gets to be a concern when we have IPv6 on the table. 138 07:07.560 --> 07:11.670 If we have large IPv6 routing domains, then our T-cam space is going to get a 139 07:11.670 --> 07:12.280 little more 140 07:12.280 --> 07:14.400 difficult to manage. 141 07:14.400 --> 07:21.610 And that's a lot to do with the fact that IPv6 routes consume two different T- 142 07:21.610 --> 07:22.760 cam slots, 143 07:22.760 --> 07:28.440 or twice what a normal routing or ACL or QOS entry would require. 144 07:28.440 --> 07:33.300 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 144 07:28.440 --> 07:33.300 And so that's just simply because IPv6 addresses are so large that we're going 145 07:33.300 --> 07:34.800 to require additional 146 07:34.800 --> 07:39.040 space based on how T-cam space was originally carved up. 147 07:39.040 --> 07:42.860 So something to keep in mind, different platforms will have different ways of 148 07:42.860 --> 07:43.600 managing these 149 07:43.600 --> 07:44.600 regions. 150 07:44.600 --> 07:47.080 Some of them have templates that we can select. 151 07:47.080 --> 07:53.420 Some of them require these templates for IPv6 because IPv4 and IPv6 are going 152 07:53.420 --> 07:53.960 to be two 153 07:53.960 --> 07:55.640 separate spaces. 154 07:55.640 --> 07:59.740 So if we're going to enable IPv6, we might actually have to dedicate that space 155 07:59.740 --> 08:00.240 to T-cam WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 155 07:59.740 --> 08:00.240 to T-cam 156 08:00.240 --> 08:01.920 before we can even enable it. 157 08:01.920 --> 08:04.400 Again, totally depending on the platform. 158 08:04.400 --> 08:08.560 But let's keep in mind what ternary-cam is, where it's used, and how exactly we 159 08:08.560 --> 08:08.880 can 160 08:08.880 --> 08:10.640 manage it on our Cisco devices.