WEBVTT 1 00:00.000 --> 00:04.720 Well, we still have a couple of problems to address that fast switching didn't 2 00:04.720 --> 00:05.120 quite 3 00:05.120 --> 00:06.480 solve for us. 4 00:06.480 --> 00:08.520 The first of which is the cache itself. 5 00:08.520 --> 00:13.070 As great as the cache is, and speeding things up, and avoiding the use of the 6 00:13.070 --> 00:13.800 CPU, it still 7 00:13.800 --> 00:18.220 relies on process switching, and it still has to be repopulated pretty 8 00:18.220 --> 00:19.200 regularly. 9 00:19.200 --> 00:22.800 The other problem is we still have to perform Layer 2 Lookups. 10 00:22.800 --> 00:26.360 Once I know where I'm sending the packet, I still have to perform an ARP lookup 11 00:26.360 --> 00:26.760 , and 12 00:26.760 --> 00:30.080 that just adds to the slowness of the whole thing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 12 00:26.760 --> 00:30.080 that just adds to the slowness of the whole thing. 13 00:30.080 --> 00:33.560 And so what we really want to do is we want to create a solution that is 14 00:33.560 --> 00:34.440 proactive. 15 00:34.440 --> 00:39.350 It doesn't rely on reactively performing process switching that doesn't react 16 00:39.350 --> 00:39.800 ively 17 00:39.800 --> 00:46.280 rely on performing Layer 2 Lookups, and this is going to lead us to Cisco's 18 00:46.280 --> 00:47.040 famous solution 19 00:47.040 --> 00:49.720 known as Cef. 20 00:49.720 --> 00:55.880 So what exactly is Cisco Express forwarding? 21 00:55.880 --> 01:03.320 We talk about it a lot, especially just talking about Cef as a concept when we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 21 00:55.880 --> 01:03.320 We talk about it a lot, especially just talking about Cef as a concept when we 22 01:03.320 --> 01:04.120 're studying 23 01:04.120 --> 01:09.260 Cisco architecture and Cisco devices, and when we first start studying for the 24 01:09.260 --> 01:09.880 CCNA. 25 01:09.880 --> 01:11.280 But what exactly is it? 26 01:11.280 --> 01:17.110 Well, again, it is meant to be that proactive element that allows us to achieve 27 01:17.110 --> 01:18.120 an ultimate 28 01:18.120 --> 01:19.280 form of speed. 29 01:19.280 --> 01:26.080 It's going to be as fast as possible when we perform our switching. 30 01:26.080 --> 01:27.920 Now again, it is its own process. 31 01:27.920 --> 01:29.000 It's not fast switching. 32 01:29.000 --> 01:32.120 It's just going to perform switching very, very fast. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 32 01:29.000 --> 01:32.120 It's just going to perform switching very, very fast. 33 01:32.120 --> 01:37.280 There are two key components to Cef. 34 01:37.280 --> 01:46.160 The first component is known as the forwarding information base or the FIB. 35 01:46.160 --> 01:49.010 This should sound a little bit familiar, sort of sounds a little bit like the 36 01:49.010 --> 01:50.120 routing information 37 01:50.120 --> 01:56.320 base or the rib, but now we're talking about the FIB for Cef. 38 01:56.320 --> 02:02.320 And the second component is going to be known as the adjacency table. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 38 01:56.320 --> 02:02.320 And the second component is going to be known as the adjacency table. 39 02:02.320 --> 02:04.360 And we don't really have an abbreviation for this. 40 02:04.360 --> 02:08.400 It's kind of nice as much as we love our three letter acronyms. 41 02:08.400 --> 02:11.880 We do just have to refer to this as the adjacency table. 42 02:11.880 --> 02:14.240 So what are these two tables? 43 02:14.240 --> 02:20.000 Well, the forwarding information base or again, the FIB, this is going to be a 44 02:20.000 --> 02:20.720 copy of the 45 02:20.720 --> 02:26.560 rib, but it's going to be highly optimized. 46 02:26.560 --> 02:30.720 It's going to be, first of all, stored in T-cam. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 46 02:26.560 --> 02:30.720 It's going to be, first of all, stored in T-cam. 47 02:30.720 --> 02:36.160 And secondly, it's going to use a completely different architecture for our 48 02:36.160 --> 02:37.080 lookups. 49 02:37.080 --> 02:39.880 So remember, T-cam allows for parallel lookups. 50 02:39.880 --> 02:42.040 It allows for very fast lookups. 51 02:42.040 --> 02:45.400 But also architecturally, we're not going to look at every single entry and 52 02:45.400 --> 02:46.080 sequence like 53 02:46.080 --> 02:47.720 we do with the rib. 54 02:47.720 --> 02:52.120 We're instead going to perform much faster lookups using different methods. 55 02:52.120 --> 02:55.440 So we can think of it as just a faster rib if we want to. 56 02:55.440 --> 02:59.040 And that's pretty good understanding of the FIB. 57 02:59.040 --> 03:04.510 But to delve into a little bit more details, we do see why this actually is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 57 02:59.040 --> 03:04.510 But to delve into a little bit more details, we do see why this actually is 58 03:04.510 --> 03:05.400 faster. 59 03:05.400 --> 03:09.490 Now with the adjacency table, we're going to use this to solve this other 60 03:09.490 --> 03:10.400 problem with 61 03:10.400 --> 03:12.080 layer two lookups. 62 03:12.080 --> 03:18.320 And so we're going to store layer two addressing information right here as part 63 03:18.320 --> 03:20.120 of the Cef process. 64 03:20.120 --> 03:24.390 This allows me to be proactive on the layer two front and even to have the 65 03:24.390 --> 03:25.120 concept of 66 03:25.120 --> 03:30.960 these prepackaged headers that we're going to use. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 66 03:25.120 --> 03:30.960 these prepackaged headers that we're going to use. 67 03:30.960 --> 03:34.700 Now again, we're talking about layer two headers in here, not prepackaged layer 68 03:34.700 --> 03:35.080 three 69 03:35.080 --> 03:40.020 headers, because again, if I'm sending a, I could have a bunch of different 70 03:40.020 --> 03:40.840 packets going 71 03:40.840 --> 03:45.450 a bunch of different directions, if they all go through the same next hop over 72 03:45.450 --> 03:47.240 here, 73 03:47.240 --> 03:51.090 every single one of these layer two headers is going to be identical because I 74 03:51.090 --> 03:51.600 have the 75 03:51.600 --> 03:55.440 same source MAC address, I have the same destination MAC address. 76 03:55.440 --> 03:56.800 And for the most part, that's it. 77 03:56.800 --> 03:59.770 When it comes to my ethernet headers, we have to worry about the ether type and 78 03:59.770 --> 04:00.200 maybe a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 78 03:59.770 --> 04:00.200 maybe a 79 04:00.200 --> 04:02.040 VLAN tag if we're trunking. 80 04:02.040 --> 04:04.240 But again, all of that will be the same. 81 04:04.240 --> 04:10.440 So I can use the same prepackaged header as long as I'm going to the same next 82 04:10.440 --> 04:11.080 hop. 83 04:11.080 --> 04:16.520 So now when a packet comes in, I don't even have to check the rib. 84 04:16.520 --> 04:18.960 The rib is completely out of the picture. 85 04:18.960 --> 04:25.060 Instead, I'm simply going to go through the Cef process, which involves the fib 86 04:25.060 --> 04:25.200 , and I'll 87 04:25.200 --> 04:29.460 go and abbreviate this as the AT for adjacency table here, just for the sake of 88 04:29.460 --> 04:30.520 fitting it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 88 04:29.460 --> 04:30.520 fitting it. 89 04:30.520 --> 04:34.100 But we're going to go through the Cef process, which again, this has already 90 04:34.100 --> 04:35.080 been populated. 91 04:35.080 --> 04:39.910 I don't have to wait for the first packet to get processed switched, and then I 92 04:39.910 --> 04:40.760 can populate 93 04:40.760 --> 04:41.760 the fib. 94 04:41.760 --> 04:42.760 That's not how it works. 95 04:42.760 --> 04:48.750 This is preemptively populated based on what's currently in the rib and what's 96 04:48.750 --> 04:49.680 currently 97 04:49.680 --> 04:50.840 in the arpe tables. 98 04:50.840 --> 04:56.600 And if there's changes, we get preemptively updated here in the Cef process. 99 04:56.600 --> 05:02.600 And so this is as fast as it can possibly get switched over to the outgoing WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 99 04:56.600 --> 05:02.600 And so this is as fast as it can possibly get switched over to the outgoing 100 05:02.600 --> 05:03.840 interface, 101 05:03.840 --> 05:08.160 and we have our new layer two header as well. 102 05:08.160 --> 05:12.110 So when we think about things from a diagram, before we're to diagram this out, 103 05:12.110 --> 05:12.320 keep in 104 05:12.320 --> 05:17.280 mind, we've said that we've got these routing protocol tables up here. 105 05:17.280 --> 05:24.800 So this would be our OSPF database and our ERGRP topology table. 106 05:24.800 --> 05:30.600 And then these are going to be feeding the rib, routing information base. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 106 05:24.800 --> 05:30.600 And then these are going to be feeding the rib, routing information base. 107 05:30.600 --> 05:34.950 And then we also, by the way, are going to have our cam tables and our ARP 108 05:34.950 --> 05:35.800 tables over 109 05:35.800 --> 05:36.880 here. 110 05:36.880 --> 05:40.560 And as I've said, by the way, this is also neighbor discovery for IPv6. 111 05:40.560 --> 05:42.400 We don't use ARP with IPv6. 112 05:42.400 --> 05:45.880 We instead use ND, neighbor discovery. 113 05:45.880 --> 05:48.240 But either way, we've got these separate tables. 114 05:48.240 --> 05:54.580 And so now we have the Cef process where again, I'm going to use the rib to 115 05:54.580 --> 05:56.760 create the fib 116 05:56.760 --> 05:58.400 proactively. 117 05:58.400 --> 06:03.170 And I'm going to bring in my layer two information in here for the adjacency WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 117 05:58.400 --> 06:03.170 And I'm going to bring in my layer two information in here for the adjacency 118 06:03.170 --> 06:03.920 table. 119 06:03.920 --> 06:09.380 And so now my packet is again going through this process down here, referencing 120 06:09.380 --> 06:09.880 these 121 06:09.880 --> 06:11.320 tables in hardware. 122 06:11.320 --> 06:13.880 The CPU is not involved. 123 06:13.880 --> 06:15.960 The rib is not directly involved. 124 06:15.960 --> 06:20.010 None of these tables are directly involved because all of the information is 125 06:20.010 --> 06:20.560 here in a 126 06:20.560 --> 06:25.040 very fast process and a very fast method for performing lookups.