WEBVTT

0:00:05.260000 --> 0:00:10.620000
 In the last video, I talked about how a
 router can learn of a remote network.

0:00:10.620000 --> 0:00:14.580000
 We talked about connected routes, static
 routes, and dynamically learned

0:00:14.580000 --> 0:00:19.480000
 routes. So now we're going to look
 at now that we assume it's learned

0:00:19.480000 --> 0:00:23.200000
 of a route in one of those three
 ways, where does it store it?

0:00:23.200000 --> 0:00:26.480000
 Where does it put that information for
 retrieval for actual look up when

0:00:26.480000 --> 0:00:31.780000
 a packet comes in?

0:00:31.780000 --> 0:00:35.140000
 So what we're referring to here is something
 called the switching process

0:00:35.140000 --> 0:00:37.320000
 in a router. Now you might say, wait
 a second, I thought we were talking

0:00:37.320000 --> 0:00:39.480000
 about routing, not switching.

0:00:39.480000 --> 0:00:46.860000
 In this context, what switching simply
 means is a packet comes in an ingress

0:00:46.860000 --> 0:00:52.280000
 interface. It is received on interface,
 and we switch it out an egress

0:00:52.280000 --> 0:00:56.760000
 interface. The process of taking something
 in and switching it or moving

0:00:56.760000 --> 0:01:01.120000
 it to an egress or outbound interface
 and then transmitting it out, that's

0:01:01.120000 --> 0:01:05.280000
 what we mean by the switching process,
 switching from one to the other.

0:01:05.280000 --> 0:01:11.280000
 Now there are, and this will ultimately
 answer the question of where a

0:01:11.280000 --> 0:01:15.860000
 route stored. So originally, the old
 way of doing it was something called

0:01:15.860000 --> 0:01:18.240000
 processed based switching.

0:01:18.240000 --> 0:01:20.760000
 So a process based
 switching was this.

0:01:20.760000 --> 0:01:25.780000
 The router would say, okay, as I learn
 of routes, I've got this memory

0:01:25.780000 --> 0:01:30.100000
 over here, this memory that has a whole
 bunch of stuff and it has my arp

0:01:30.100000 --> 0:01:32.160000
 table for when I arp for things.

0:01:32.160000 --> 0:01:36.860000
 It has my running configuration that
 I'm currently working with right

0:01:36.860000 --> 0:01:40.960000
 now. It's got all sorts
 of stuff in there.

0:01:40.960000 --> 0:01:45.000000
 I'm going to take that memory and carve
 out of it a space to store my

0:01:45.000000 --> 0:01:48.320000
 routes, and I'm going to call
 that my routing table.

0:01:48.320000 --> 0:01:52.380000
 Now in that routing table, I'm going
 to put everything I've learned about

0:01:52.380000 --> 0:01:57.920000
 the route, basically the route itself,
 the subnet mask, how I learned

0:01:57.920000 --> 0:02:00.320000
 it, was it, am I connected to it?

0:02:00.320000 --> 0:02:02.420000
 Did somebody statically
 configure it?

0:02:02.420000 --> 0:02:03.740000
 Is it dynamically learned?

0:02:03.740000 --> 0:02:05.260000
 I'll put that in there.

0:02:05.260000 --> 0:02:08.940000
 If it was dynamically learned, I'll
 put in there an indicator about how

0:02:08.940000 --> 0:02:10.200000
 it was dynamically learned.

0:02:10.200000 --> 0:02:12.660000
 Was it via RIP or
 EIGR or PIR OSPF?

0:02:12.660000 --> 0:02:14.700000
 I'll put that information
 in there.

0:02:14.700000 --> 0:02:19.320000
 I'll put how long it's been since I've
 learned it, so there's a timer

0:02:19.320000 --> 0:02:24.160000
 in there. I'll put in the next hop
 address, the egress interface, all

0:02:24.160000 --> 0:02:28.880000
 of that, all that stuff relayed to the
 route will be put into the section

0:02:28.880000 --> 0:02:31.920000
 of memory called the
 IP routing table.

0:02:31.920000 --> 0:02:34.460000
 And then when we're doing process-based
 switching, what that means is

0:02:34.460000 --> 0:02:39.860000
 that when a packet comes in, the ingress
 interface that received it sends

0:02:39.860000 --> 0:02:42.000000
 an interrupt to the CPU.

0:02:42.000000 --> 0:02:45.560000
 It says, hey CPU, I know you're busy
 doing a lot of stuff, but I got a

0:02:45.560000 --> 0:02:48.160000
 packet here. I need
 you to look this up.

0:02:48.160000 --> 0:02:52.260000
 So the CPU is running lots
 of different tasks.

0:02:52.260000 --> 0:02:55.760000
 One of these processes, one of these
 services the CPU is running as called

0:02:55.760000 --> 0:02:59.040000
 as you can see here,
 the IP input process.

0:02:59.040000 --> 0:03:03.120000
 The IP input process, when that comes
 around, says, okay, time for me

0:03:03.120000 --> 0:03:06.540000
 to look at all these packets that came
 in and figure out what to do with

0:03:06.540000 --> 0:03:10.520000
 them. So when you're doing process-based
 switching, the CPU says, okay,

0:03:10.520000 --> 0:03:15.340000
 let's invoke IP input let's look at these
 packets, extract their destination

0:03:15.340000 --> 0:03:20.220000
 address, go into my routing table, and
 see if I can find something that

0:03:20.220000 --> 0:03:24.340000
 matches this. Maybe it doesn't match
 the entire thing, but matches some

0:03:24.340000 --> 0:03:28.340000
 portion of the address,
 and then I can route it.

0:03:28.340000 --> 0:03:32.480000
 So that was process
-based switching.

0:03:32.480000 --> 0:03:37.920000
 But long ago, some people thought, you
 know what, it works, but it's kind

0:03:37.920000 --> 0:03:42.960000
 of slow, and maybe we can make
 it a little bit quicker.

0:03:42.960000 --> 0:03:46.060000
 And so they came up with this idea
 of, well, why don't we do this?

0:03:46.060000 --> 0:03:52.080000
 Why don't we create another table in
 memory that can be looked up much,

0:03:52.080000 --> 0:03:56.420000
 much more quickly, that can be accessed
 much more quickly, maybe even

0:03:56.420000 --> 0:03:57.860000
 accessed in hardware.

0:03:57.860000 --> 0:04:01.660000
 In other words, maybe we can create
 a table that when a packet comes in,

0:04:01.660000 --> 0:04:06.320000
 some piece of hardware, some chip or
 something sitting on the interface

0:04:06.320000 --> 0:04:12.500000
 can actually access this table directly,
 look up the packet, forward it,

0:04:12.500000 --> 0:04:14.900000
 and we don't even need
 to bother the CPU.

0:04:14.900000 --> 0:04:18.280000
 He can keep shogging away doing whatever
 he's doing, but we'll have this

0:04:18.280000 --> 0:04:23.480000
 separate hardware with a separate
 table do everything for us.

0:04:23.480000 --> 0:04:25.720000
 And so that was fast switching.

0:04:25.720000 --> 0:04:30.360000
 Now the way fast switching worked was
 that initially, this separate memory

0:04:30.360000 --> 0:04:33.020000
 was carved out, but it was empty.

0:04:33.020000 --> 0:04:34.560000
 There were no routes in there.

0:04:34.560000 --> 0:04:38.980000
 A packet would come in because
 there were no routes in there.

0:04:38.980000 --> 0:04:43.400000
 That fast switching cache, that fast
 switching table would say, okay,

0:04:43.400000 --> 0:04:47.020000
 punt that packet to the CPU
 and do process switching.

0:04:47.020000 --> 0:04:52.120000
 Now the CPU would discover the route,
 forward the packet, and then the

0:04:52.120000 --> 0:04:55.980000
 route would be downloaded into
 the fast switching cache.

0:04:55.980000 --> 0:04:59.840000
 So the next packet that came in for
 that exact same destination would

0:04:59.840000 --> 0:05:02.820000
 not have to go to the CPU, would
 not have to be punted.

0:05:02.820000 --> 0:05:06.020000
 It could be found right there
 in the fast switching cache.

0:05:06.020000 --> 0:05:10.160000
 We could rewrite the layer two
 headers, set it on its way.

0:05:10.160000 --> 0:05:15.060000
 So fast switching was what was
 called demand-based switching.

0:05:15.060000 --> 0:05:18.400000
 In other words, the fast switching
 cache did not have a route until a

0:05:18.400000 --> 0:05:20.360000
 packet came in that needed it.

0:05:20.360000 --> 0:05:23.840000
 And then that first packet would cause
 the route to be put from the routing

0:05:23.840000 --> 0:05:28.220000
 table into the fast switching cache
 and so now subsequent packets going

0:05:28.220000 --> 0:05:31.920000
 to that same destination could make
 use of that and could be switched

0:05:31.920000 --> 0:05:36.480000
 or routed much, much more quickly and
 we wouldn't have to bother the router.

0:05:36.480000 --> 0:05:45.680000
 Now some people said that's better, but
 the downside to that is that route

0:05:45.680000 --> 0:05:51.280000
 always existed. The CPU and the router
 learned about that route instantly

0:05:51.280000 --> 0:05:55.920000
 via a static route or maybe he was
 running RIP or OSPF or EIGRP.

0:05:55.920000 --> 0:06:00.520000
 But the moment he put it in his routing
 table, why did this other table

0:06:00.520000 --> 0:06:05.620000
 stay empty? It would probably be better
 if we could take whatever was

0:06:05.620000 --> 0:06:09.360000
 in the routing table and just
 pre-populate a table with it.

0:06:09.360000 --> 0:06:11.560000
 Even if nobody needs
 the routes right now.

0:06:11.560000 --> 0:06:13.400000
 Even if there's no
 packets coming in.

0:06:13.400000 --> 0:06:17.420000
 Let's pre-populate this table so they're
 ready and waiting to be used

0:06:17.420000 --> 0:06:21.240000
 when a packet does have to come in
 so that no packets have to hit the

0:06:21.240000 --> 0:06:26.680000
 CPU at all. And that's where Cisco came
 up with Cisco Express forwarding

0:06:26.680000 --> 0:06:31.560000
 or CFS. So CFS basically does
 the same type of thing.

0:06:31.560000 --> 0:06:35.920000
 CFS says, okay, now I've got this separate
 section of memory that's going

0:06:35.920000 --> 0:06:39.720000
 to store my routing information, but
 I'm not going to wait for any packets

0:06:39.720000 --> 0:06:45.640000
 to populate it. CFS was what's called
 topology-based switching, meaning

0:06:45.640000 --> 0:06:49.920000
 as the router learns of the topology, because
 you've either directly connected

0:06:49.920000 --> 0:06:54.040000
 to things, you statically typed it
 in a static route, or he learned of

0:06:54.040000 --> 0:06:55.280000
 something via dynamic routes.

0:06:55.280000 --> 0:07:00.360000
 As his routing table gets populated,
 that stuff gets downloaded into these

0:07:00.360000 --> 0:07:03.320000
 additional tables that CFS uses.

0:07:03.320000 --> 0:07:07.460000
 Now you might be thinking, well,
 what makes that any faster?

0:07:07.460000 --> 0:07:14.900000
 Couple things. Number one, the fast
 switching cache and the CFS tables

0:07:14.900000 --> 0:07:19.740000
 only contain the stuff that we need
 to actually forward packets.

0:07:19.740000 --> 0:07:21.680000
 So let's think about
 this for a second.

0:07:21.680000 --> 0:07:26.420000
 If a packet comes into a router going
 to some destination, in order to

0:07:26.420000 --> 0:07:32.280000
 actually route that packet, in order to
 forward it out some egress interface,

0:07:32.280000 --> 0:07:37.240000
 when the router finds a route that
 matches, does it really matter how

0:07:37.240000 --> 0:07:38.840000
 that route was learned?

0:07:38.840000 --> 0:07:43.080000
 In other words, when he goes into some
 table and that table has a matching

0:07:43.080000 --> 0:07:48.040000
 route, does he care if it was connected
 or static or learn via OSPF?

0:07:48.040000 --> 0:07:49.640000
 No, he doesn't care.

0:07:49.640000 --> 0:07:52.940000
 He says, look, as long as it's in
 there, that's all I care about.

0:07:52.940000 --> 0:07:57.760000
 All I care about is the route, the mask,
 the next hop, and the outbound

0:07:57.760000 --> 0:08:00.200000
 interface. That's pretty much it.

0:08:00.200000 --> 0:08:02.180000
 I don't care how it was learned.

0:08:02.180000 --> 0:08:05.740000
 I don't care about a timer,
 how long ago it was learned.

0:08:05.740000 --> 0:08:09.420000
 You know, a bunch of extra stuff that's
 in the routing table, I don't

0:08:09.420000 --> 0:08:12.520000
 need to actually forward
 the packet.

0:08:12.520000 --> 0:08:17.720000
 So the CFS table and the fast switching
 cache leave out all that extra

0:08:17.720000 --> 0:08:22.560000
 stuff and only have the key ingredients
 that a router needs to actually

0:08:22.560000 --> 0:08:25.020000
 route a packet to its destination.


0:08:25.020000 --> 0:08:27.160000
 So that's one thing that makes
 it a little bit faster.

0:08:27.160000 --> 0:08:30.000000
 The lookup process can be done much
 more quickly, so we don't have to

0:08:30.000000 --> 0:08:33.220000
 scan through all this other junk
 that's in there as well.

0:08:33.220000 --> 0:08:39.660000
 Now, fast switching just had one data
 structure called the fast switching

0:08:39.660000 --> 0:08:43.460000
 cache. And remember, what do we
 need to actually route a packet?

0:08:43.460000 --> 0:08:47.880000
 We need all that layer three stuff,
 the destination network, the mask.

0:08:47.880000 --> 0:08:50.800000
 We need a destination IP
 address of a next hop.

0:08:50.800000 --> 0:08:54.520000
 And then we need some
 non IP stuff, right?

0:08:54.520000 --> 0:09:00.760000
 We need the egress interface, fast
 ethernet 00, serial 11, and we need

0:09:00.760000 --> 0:09:03.680000
 the layer two rewrite information.


0:09:03.680000 --> 0:09:07.180000
 For example, if we see at the fast that
 the egress interface is fast ethernet

0:09:07.180000 --> 0:09:12.920000
 00 and the next hop is 1111, what layer
 two, we need to know what the

0:09:12.920000 --> 0:09:18.100000
 destination MAC address is for 1111
 so we can send the packet to him.

0:09:18.100000 --> 0:09:20.680000
 So we need layer two
 stuff as well.

0:09:20.680000 --> 0:09:24.820000
 In the case of fast switching, all of
 that stuff was in the fast switching

0:09:24.820000 --> 0:09:28.180000
 cache. Everything you needed
 to route a packet was there.

0:09:28.180000 --> 0:09:31.400000
 All the layer three stuff and the layer
 two rewrite stuff was in there

0:09:31.400000 --> 0:09:36.880000
 as well. In the case of Ceph, they actually
 divided that into two separate

0:09:36.880000 --> 0:09:43.900000
 tables. So Ceph, all of the layer three
 information as well as the next

0:09:43.900000 --> 0:09:48.760000
 hop and the egress interface is stored
 in a table, a memory structure

0:09:48.760000 --> 0:09:51.700000
 called the forwarding
 information base.

0:09:51.700000 --> 0:09:55.720000
 So this is basically all the stuff you
 would find, all the relevant pertinent

0:09:55.720000 --> 0:09:58.660000
 stuff you would find that's
 in the routing table.

0:09:58.660000 --> 0:10:03.940000
 So for example, the route, the next
 hop, the egress interface, but all

0:10:03.940000 --> 0:10:08.640000
 the timers, how the route was learned,
 that stuff's not there.

0:10:08.640000 --> 0:10:12.640000
 All the stuff we actually
 need is in the fib.

0:10:12.640000 --> 0:10:19.360000
 So for example, if I go over here to
 one of our routers, let's just take

0:10:19.360000 --> 0:10:27.120000
 router three as an example.

0:10:27.120000 --> 0:10:33.120000
 And I type showipcef,
 this shows me the fib.

0:10:33.120000 --> 0:10:38.000000
 So you can see it's a very stripped
 down version of the routing table.

0:10:38.000000 --> 0:10:43.880000
 Here we have the route two three
 two zero slash twenty four.

0:10:43.880000 --> 0:10:49.460000
 And it says I'm attached to it
 via fast ethernet zero one.

0:10:49.460000 --> 0:10:53.200000
 Let's actually take a
 route that he learns.

0:10:53.200000 --> 0:10:58.800000
 Let's go to R two showipcef.

0:10:58.800000 --> 0:11:03.700000
 Okay, so take a look at this one.

0:11:03.700000 --> 0:11:09.940000
 So if I do showiproute, I want to
 look at the 11 11 11 network.

0:11:09.940000 --> 0:11:15.320000
 Actually, let's go even deeper
 showip route 11 11 11 dot zero.

0:11:15.320000 --> 0:11:20.200000
 So in the routing table, this is all
 the stuff he knows about the 11 11

0:11:20.200000 --> 0:11:25.560000
 11 0 network. He says, I'll
 how I learned it via BGP.

0:11:25.560000 --> 0:11:31.700000
 Okay, up here in the seftable, no indications
 as to how we learned it.

0:11:31.700000 --> 0:11:34.160000
 Because we don't need that to
 actually fall with the packet.

0:11:34.160000 --> 0:11:40.840000
 Down here, he says, I learned it
 two hours and 42 minutes ago.

0:11:40.840000 --> 0:11:44.860000
 Once again up here, that timer is not
 relevant for actually routing a

0:11:44.860000 --> 0:11:54.200000
 packet. Here the routing metric route
 tag and the type of route external,

0:11:54.200000 --> 0:11:58.860000
 the distance, all of the stuff is in
 the routing table, but we don't need

0:11:58.860000 --> 0:12:02.000000
 it to actually route the packet.

0:12:02.000000 --> 0:12:06.700000
 All we need is what's in the seft forwarding
 information base, the fib

0:12:06.700000 --> 0:12:13.880000
 table, the prefix or the route, the
 subnet mask, the IP address of the

0:12:13.880000 --> 0:12:18.240000
 next top neighbor we're going to send
 it to and the egress interface.

0:12:18.240000 --> 0:12:23.760000
 Now, notice there's one thing that's
 missing here that's critical, the

0:12:23.760000 --> 0:12:25.480000
 layer two information.

0:12:25.480000 --> 0:12:30.480000
 If I'm going to forward a packet going
 to 11 11 11, if I'm going to forward

0:12:30.480000 --> 0:12:34.880000
 that packet to my neighbor who's one
 two one one, then my neighbor's on

0:12:34.880000 --> 0:12:36.020000
 fast ethernet zero zero.

0:12:36.020000 --> 0:12:39.160000
 I need to know what the MAC
 address is of this guy.

0:12:39.160000 --> 0:12:43.060000
 Well, if we were doing process based
 switching, we would have just looked

0:12:43.060000 --> 0:12:44.940000
 that up on the ARP table.

0:12:44.940000 --> 0:12:48.140000
 Show show IP ARP.

0:12:48.140000 --> 0:12:50.000000
 And we'd see right here.

0:12:50.000000 --> 0:12:52.180000
 Okay, here he is one two one one.

0:12:52.180000 --> 0:12:54.780000
 Here's his MAC address.

0:12:54.780000 --> 0:12:58.080000
 But seft says we don't
 want to bother the CPU.

0:12:58.080000 --> 0:13:02.200000
 We don't want to have to look tell the
 CPU, hey, look in the ARP table.

0:13:02.200000 --> 0:13:05.620000
 So seft says I'm going to take that
 layer two information and store that

0:13:05.620000 --> 0:13:09.380000
 in a different table called
 the adjacency table.

0:13:09.380000 --> 0:13:15.720000
 So just like we took the relevant information
 from the routing table,

0:13:15.720000 --> 0:13:19.680000
 extracted that and put it in the fib
 table, just the information we needed

0:13:19.680000 --> 0:13:22.180000
 to route, not all those
 timers and other stuff.

0:13:22.180000 --> 0:13:26.040000
 Now we're going to take the relevant information
 from our layer two tables,

0:13:26.040000 --> 0:13:31.480000
 such as the ARP table and put that
 in the adjacency table, which seft

0:13:31.480000 --> 0:13:34.900000
 can get a hold of and seft
 can look up super fast.

0:13:34.900000 --> 0:13:38.060000
 You can see here the seft table contains
 your layer two information about

0:13:38.060000 --> 0:13:42.420000
 ARP, your frame relay mapping
 tables, your your PPP headers.

0:13:42.420000 --> 0:13:43.620000
 That's all in there.

0:13:43.620000 --> 0:13:55.480000
 So as an example, if seft gets a packet
 going to this, seft says, okay,

0:13:55.480000 --> 0:14:02.040000
 my fib table says I need to forward
 that to one two one one and he lives

0:14:02.040000 --> 0:14:04.520000
 on fast ethe end at zero zero.

0:14:04.520000 --> 0:14:09.440000
 So now seft in just a microsecond is
 going to look at the adjacency table.

0:14:09.440000 --> 0:14:13.720000
 Show adjacency, what are all the adjacencies
 you know of on fast ethe

0:14:13.720000 --> 0:14:15.620000
 end at zero zero?

0:14:15.620000 --> 0:14:21.240000
 Actually show adjacency detail.

0:14:21.240000 --> 0:14:22.740000
 So it's right here.

0:14:22.740000 --> 0:14:27.000000
 If I need to forward something to the
 next top of one two one one, here

0:14:27.000000 --> 0:14:30.200000
 is my layer two rewrite table.

0:14:30.200000 --> 0:14:32.360000
 Remember, let's take a look
 up at the ARP table.

0:14:32.360000 --> 0:14:37.720000
 And the ARP table, his MAC address was
 C 202 blah, blah, blah, blah, blah.

0:14:37.720000 --> 0:14:42.600000
 So right down here, here is
 the destination MAC address.

0:14:42.600000 --> 0:14:46.200000
 Here is the source MAC address
 he's going to use.

0:14:46.200000 --> 0:14:50.760000
 And here's the ether type code,
 zero X 800 for IP version four.

0:14:50.760000 --> 0:14:54.520000
 So by Cisco Express forwarding by using
 the combination of the fib table

0:14:54.520000 --> 0:14:59.220000
 and this layer two information here in
 the adjacency table has everything

0:14:59.220000 --> 0:15:09.440000
 he needs to look up route and
 layer two rewrite the packet.

0:15:09.440000 --> 0:15:12.620000
 And just a little bit more information
 about those adjacency types.

0:15:12.620000 --> 0:15:19.000000
 The adjacency types also describe sort
 of what to do with a matching entry.

0:15:19.000000 --> 0:15:22.720000
 For example, an adjacency
 type of glean.

0:15:22.720000 --> 0:15:26.380000
 What is that? So let's say
 that we had a router.

0:15:26.380000 --> 0:15:37.100000
 Here he is. He's got
 two interfaces.

0:15:37.100000 --> 0:15:44.420000
 Let's say four. And here comes in a
 packet with a destination address

0:15:44.420000 --> 0:15:48.880000
 going to seven seven seven nine.

0:15:48.880000 --> 0:15:56.240000
 So his fib table would say that he is
 attached to the seven seven seven

0:15:56.240000 --> 0:15:59.040000
 network on whatever this is.

0:15:59.040000 --> 0:16:00.840000
 Fast ethernet zero zero.

0:16:00.840000 --> 0:16:09.300000
 So now he would go into his adjacency
 table to see if he had layer two

0:16:09.300000 --> 0:16:10.340000
 particular device.

0:16:10.340000 --> 0:16:14.320000
 Now let's say that he's never talked
 to seven seven seven nine before.

0:16:14.320000 --> 0:16:15.680000
 Never talked to that guy.

0:16:15.680000 --> 0:16:17.200000
 He'd say, well, I'm
 attached to him.

0:16:17.200000 --> 0:16:19.140000
 I'm directly connected to that.

0:16:19.140000 --> 0:16:21.760000
 Therefore, I need to arp it.

0:16:21.760000 --> 0:16:24.180000
 But Ceph does not have
 the ability to arp.

0:16:24.180000 --> 0:16:26.420000
 That's something the
 CPU has to do.

0:16:26.420000 --> 0:16:31.520000
 So what he would do is in his adjacency
 table, his Ceph adjacency table,

0:16:31.520000 --> 0:16:35.540000
 he would create an entry for
 seven seven seven nine.

0:16:35.540000 --> 0:16:38.380000
 And he would say glean.

0:16:38.380000 --> 0:16:42.740000
 And so now he would he would
 send this up to the CPU.

0:16:42.740000 --> 0:16:44.680000
 He'd say, hey, CPU, here's
 a packet for you.

0:16:44.680000 --> 0:16:47.080000
 And the CPU would art for it.

0:16:47.080000 --> 0:16:51.340000
 And then if seven seven seven nine actually
 existed, we would get an art

0:16:51.340000 --> 0:16:59.300000
 response back. And now this glean could
 be changed to an actual real adjacency.

0:16:59.300000 --> 0:17:01.840000
 It's not one of the ones on here on
 the list, but we'd actually have a

0:17:01.840000 --> 0:17:04.760000
 real adjacency with a real Mac.

0:17:04.760000 --> 0:17:08.200000
 So glean is it is hopefully
 a temporary condition.

0:17:08.200000 --> 0:17:10.920000
 It means, hey, look, we're
 arping for it right now.

0:17:10.920000 --> 0:17:14.820000
 And as soon as we get an art response
 back, we'll fill out this adjacency

0:17:14.820000 --> 0:17:17.400000
 with the real layer
 two information.

0:17:17.400000 --> 0:17:24.380000
 No means basically drop it,
 discard it as an example.

0:17:24.380000 --> 0:17:27.160000
 Sometimes, you know, and you'll learn
 more about this probably at the

0:17:27.160000 --> 0:17:30.240000
 CCNP level rather than
 the CCNA level.

0:17:30.240000 --> 0:17:35.180000
 But let's say I had here's something
 you can do in your CCNA labs.

0:17:35.180000 --> 0:17:40.860000
 Let's say I have router one and router
 two, and you're doing a lab on

0:17:40.860000 --> 0:17:43.520000
 something like let's say rip.

0:17:43.520000 --> 0:17:50.040000
 And you say, I want router two to send
 router one a rip route just to

0:17:50.040000 --> 0:17:55.820000
 see if he can for the
 two to two network.

0:17:55.820000 --> 0:17:57.760000
 Let's make it simpler than that.

0:17:57.760000 --> 0:18:01.060000
 Now that's fine, 222 slash 24.

0:18:01.060000 --> 0:18:02.640000
 But here's my challenge.

0:18:02.640000 --> 0:18:07.760000
 They only have one cable and that one
 cable is in the one one one network.

0:18:07.760000 --> 0:18:09.520000
 But I want him to send the
 two to two networks.

0:18:09.520000 --> 0:18:12.940000
 So basically, I have to tell router two,
 hey, I'm going to make up a route

0:18:12.940000 --> 0:18:15.700000
 out of thin air and have
 you advertise it.

0:18:15.700000 --> 0:18:25.240000
 So how would I get him to do that?


0:18:25.240000 --> 0:18:31.460000
 Well, 22220 give him
 a subnet mask.

0:18:31.460000 --> 0:18:35.640000
 But now a static route is not usable
 until you give it a next top.

0:18:35.640000 --> 0:18:37.040000
 Well, I could do this.

0:18:37.040000 --> 0:18:44.100000
 Null zero. So what this is basically
 telling router two is, hey, if you

0:18:44.100000 --> 0:18:48.360000
 ever get any packets to the 222
 network, throw them away.

0:18:48.360000 --> 0:18:50.120000
 Null zero is like a black
 hole interface.

0:18:50.120000 --> 0:18:51.760000
 It means discard it.

0:18:51.760000 --> 0:18:55.080000
 And this will create
 a null adjacency.

0:18:55.080000 --> 0:18:57.800000
 But in this case, it's okay, because
 what was my objective?

0:18:57.800000 --> 0:19:01.440000
 My objective was, this will actually
 put a route in his routing table.

0:19:01.440000 --> 0:19:08.520000
 He'll now have a static route to
 22220 slash 24 via null zero.

0:19:08.520000 --> 0:19:12.600000
 And now that he has this static route
 in his routing table, I could actually

0:19:12.600000 --> 0:19:21.600000
 use rip or EIGRP or OSPF to actually
 I just want router two to advertise

0:19:21.600000 --> 0:19:25.240000
 the 222 network to router one so I can
 see what it looks like in my rip

0:19:25.240000 --> 0:19:27.380000
 table or my EIGRP table.

0:19:27.380000 --> 0:19:31.080000
 To do that, I have to make it up out
 of thin air because it didn't exist.

0:19:31.080000 --> 0:19:32.940000
 This is one way I could do that.

0:19:32.940000 --> 0:19:36.640000
 Creating a static route that really
 doesn't go anywhere can't be used

0:19:36.640000 --> 0:19:40.280000
 by router two, but it can be used so that
 he now has a route in his routing

0:19:40.280000 --> 0:19:42.800000
 table, he can advertise
 to router one.

0:19:42.800000 --> 0:19:45.480000
 And that creates a null adjacency.


0:19:45.480000 --> 0:19:51.200000
 Another type of adjacency that we
 see here is a drop adjacency.

0:19:51.200000 --> 0:19:53.320000
 And this is kind of like
 a null adjacency.

0:19:53.320000 --> 0:19:56.260000
 It basically means once
 again, drop the packet.

0:19:56.260000 --> 0:19:59.960000
 Could be because something's wrong
 with the packet or there's there's

0:19:59.960000 --> 0:20:05.200000
 bad encapsulation, a missing
 route, something like that.

0:20:05.200000 --> 0:20:11.280000
 And discard. Discard is when you have
 to drop a packet because there is

0:20:11.280000 --> 0:20:15.380000
 some, oops, there is a
 security restriction.

0:20:15.380000 --> 0:20:19.260000
 In other words, let's say we had an
 access list and when a packet comes

0:20:19.260000 --> 0:20:22.120000
 in, it matches the access list and
 the access list says drop it.

0:20:22.120000 --> 0:20:23.020000
 We're not permitting it.

0:20:23.020000 --> 0:20:24.300000
 We're going to deny it.

0:20:24.300000 --> 0:20:27.560000
 Well, that would create
 a discard adjacency.

0:20:27.560000 --> 0:20:33.000000
 And then a punt adjacency means this
 needs to be punted to the CPU.

0:20:33.000000 --> 0:20:36.960000
 For example, the router once
 again, he's got 1111.

0:20:36.960000 --> 0:20:38.820000
 That is his IP address.

0:20:38.820000 --> 0:20:48.920000
 Well, that is a, that is a express
 forwarding in his adjacency table.

0:20:48.920000 --> 0:20:51.780000
 He will create an entry for this.

0:20:51.780000 --> 0:20:53.840000
 And he'll say punt.

0:20:53.840000 --> 0:20:58.080000
 Because after all, if something comes
 in with a destination address of

0:20:58.080000 --> 0:21:02.100000
 him 1111, we do want
 his CPU to see that.

0:21:02.100000 --> 0:21:05.320000
 We do want to punt that to the CPU
 so the CPU can process that.

0:21:05.320000 --> 0:21:06.420000
 Maybe it's a ping.

0:21:06.420000 --> 0:21:07.660000
 Maybe it's a telnet.

0:21:07.660000 --> 0:21:11.060000
 Who knows? But we want his CPU
 to have visibility to that.

0:21:11.060000 --> 0:21:17.580000
 And that concludes this section on where
 routes are stored within a routing