Perform Switch Administration

0:00So very quickly, we are going to review how exactly MAC addresses are learned on a network. So if we have a couple of switches here, we know that we're not running any kind of layer two routing protocol or anything along these lines where I'm proactively advertising MAC addresses. Instead, as I keep track of my MAC addresses in my MAC address table, I'm going to populate this table as traffic comes into the switch. This is a mechanism that we refer to as flood-and-learn. And even though this might feel just a little bit basic for a CCIE type of conversation, this mechanism becomes a big deal when we move on to technologies like VXLAN and LISP.

0:42And so we need to actually just think about this and dwell on this just for a few moments, long enough to make sure that we understand how exactly this flood-and-learn concept works. And so it's maybe something we haven't visited in a while. The idea here is that if I were to connect a host, a PC, a router, something like this, and we generate traffic, we're going to include our source MAC address, and our source address, let's say in this case is 1.2.3. We'll just use the decimal format here. Well, when this layer two frame comes into the switch on the left, it's going to add 1.2.3 into its MAC address table.

1:21And it's going to look at the port. Let's say this is port usually 0/1, something like that, maybe gig 0/1. And so we'll point this to gig 0/1. Now this table is going to be referred to as the content-addressable memory, or the CAM. and we're going to talk about what exactly this means here coming up, but this is actually a big deal as far as where we store our layer two addressing.

1:52It is always stored inside of the CAM, and we're going to wanna differentiate that from the TCAM here coming up here shortly as well. Now the other big caveat in all of this is that this CAM table, the MAC address table, however we wanna refer to it, either way is fine. This is on a per-VLAN basis, meaning that we need to keep a cam table for every single VLAN. Now, if I were to issue a command on the layer two device or multi-layer switch either way, but I'm on the switch, and I say show MAC address-table, this is the command that we're going to want to get used to.

2:32Way back in the day we actually had this fully hyphenated, but either way, now it's separate, show MAC address table, this is going to show all of the entries over here, and it'll specify which VLAN each entry belongs to. And so, if we wanna think of it as saying that I've got a Mac address and that's bound to a port, and that's going to get mapped to a VLAN, that's perfectly fine. But again, technically speaking under the hood, these cams operate on a per-VLAN basis.

3:04Now the other thing that we're tracking in all of this is whether or not this is a dynamic MAC address or if it's a static MAC address. A dynamic MAC address simply means that it was learned via that flood-and-learn type of mechanism. Static means that it is configured in some way. I can statically map MAC addresses to ports, but I can also statically create new interfaces. For example, on a switch, if I create a VLAN 100 interface and well, it's gonna have an IP address, but even if I don't configure a MAC address, it's going to have one.

3:43And so this VLAN 100 MAC address actually gets mapped into the table as well since it's a layer three interface, on that particular switch. So let's get back to the flood-and-learn concept. We know that if I've got a port, or I'm sorry, a frame coming into, let's say the switch on the right, let's call this switch two. Switch two is going to look at the destination address. In this case, it's destined for 1.2.3, and then it's going to check the CAM. And if it doesn't show up in the CAM, let's say that this CAM is actually empty at this point, we don't have any dynamically learned addresses in there.

4:20Maybe the switch just came online. Either way, if we're talking about layer three unknown addresses, we're probably gonna just drop those. I mean, it's very different behavior here. In a layer two world, especially with ethernet, we are going to flood this out. This is flood-and-learn. I'm going to send this out every port, every interface, that I have attached to this particular device. And that does ensure that one of these forwards is going to land on the destination if that destination is reachable at least.

4:53And so we're going to send that out. It's actually going to arrive at the destination. And the theory is that the destination will send traffic back at some point, at which point we will actually be able to learn where that MAC address is. So now I just learned where 1.2.3 lifts. I can add that into my CAM table, and I don't need to flood it next time I get a frame in that has a destination address. So that is the nature of flood-and-learn technology and how we keep track of our MAC addresses in VLAN-specific CAM tables.

0:01We live in a dynamic world. A lot of times we're gonna find that a MAC address might be learned on one interface, like gig 0/1 here, but then this MAC address moves over to another interface. Maybe it migrates to a completely different switch. And so now this MAC address, let's keep using 1.2.3 as an example, it was learned on gig 0/1 here. So 1.2.3 points to gig 0/1. But now it lives out gig 0/2.

0:33Now, there's a lot of ways that the MAC addresses might migrate in our campus environments. This could be a wireless roam, for example. But this actually happens a lot in our data center environments as well. We might see virtual machines move around inside the virtual hypervisor space. And so this type of migration, whether it's in the data center, whether it's in wireless, either way, it happens a lot, and it creates a, potentially, a really big problem.

1:03And that is that now as a packet comes in that's destined for 1.2.3, if this switch doesn't realize that the MAC address moved, it's going to forward it out the wrong port and that's going to black hole traffic. And so this is a situation that we need to be able to resolve very quickly. And so how exactly do we go about solving this? Well, some amount of responsibility is going to be placed onto the host itself that ended up migrating. Specifically, this host needs to generate traffic.

1:36We're not going to be able to put this on the switching environment itself. Again, we don't have a control plane. If we had a control plane, then the switch on the right would see the MAC address and say, "Oh, the MAC address moved. Hey, you might want to update your CAM table." But unfortunately, we don't have it working that way. Now again, we mentioned VXLAN already once. This is going to come back into the conversation later on, which is one of the reasons why we're having the conversation upfront. In this situation, we do not have a control plane, and therefore the host ideally is going to have to generate some amount of traffic, because we are still relying on flood and learn.

2:14I learn where this new interface is here for this specific MAC address only when a frame shows up. So how do I get a frame to show up sourced from 1.2.3? Well, again, we can generate traffic, and if the host recognizes that it moved, then it can do what we call especially... Well, especially being the way we typically do it. It is a gratuitous ARP. Gratu...

2:45Gratu, there it is. Gratuitous ARP, which is often abbreviated as a GARP, which is kind of a funny sounding word. So what happens is the host, now, let's say it lives out this interface, it's going to send that gratuitous ARP. Now, we call it a gratuitous ARP. The word gratuitous simply means that, "Hey, nobody asked for this, but I'm gonna send it out anyways." And an ARP is going to be a broadcast type of frame.

3:16Because it's a broadcast, it's going to get sent out everywhere. So let's just show here. So we're sending it out all of the ports and all of the interfaces, including this trunk between the switches. So at this point, the frame now arrives on the switch. It sees that I've got a source of 1.2.3, and it recognizes it already has an entry. So what's it going to do here? Well in a stable environment, assuming this doesn't happen too often, it's simply going to update this. It's going to say, "Okay, you're no longer living out gig 0/1.

3:48You must be living out gig 0/2 now." And life is good. We're not gonna black hole traffic anymore when this destination frame comes in. As long as we have gone through this process and updated the CAM table, it's going to send it out the appropriate interface and life will be good. Now, this does create an interesting scenario as well, which is that we can find that we have a situation known as flapping. Flapping means that the same MAC address just continues to change ports.

4:21So if this is happening constantly or rapidly, then we realize that we've probably got a problem in the layer two environment. At a minimum, it's not stable. You know, these mechanisms that would normally create a single layer two type of movement, this isn't something that happens very often. So if a packet shows up on... Drawing another switch down here. If it shows up on this interface and then this interface, and then back on this interface, and then back on this interface, maybe we have a loop in the environment. Maybe we, you know, have something else happening.

4:53But either way, this represents an instable or an unstable... Represents instability and an unstable environment. There we go. So what ends up happening here is that these ports might be placed into a disabled state, and specifically we'd call this air disabled. And we'll be exploring air disabling here coming up later on in this course. But either way, we're gonna find that the ports end up getting disabled if flapping occurs. Now, one migration is not flapping.

5:23But if it does go back and forth, then it will end up getting disabled. Now we have one other problem we have to recognize, which is what happens if this doesn't actually happen? What happens if we don't send a gratuitous ARP? What if we just move and... So we move and we generate no traffic. Well at this point, we are in trouble because this is pretty much our entire mechanism for achieving stability again. So if that's our entire mechanism for it, then what are we going to do in this scenario?

5:58Because we're going to come back to this situation where we continue to send traffic out the wrong interface. Well, this is why we end up having an aging component to our MAC addresses. So when I learn an address, I'm going to set a timer on that address. So in this CAM entry right in here, we originally said that... Let's just go back to it being out gig 0/1. We did not learn that it's at a new interface. It thinks it's going out this bad interface now, but it sets a timer.

6:32And the default timer on Cisco iOS devices is 300 seconds, which is five minutes. So it starts to decrement this timer from the moment that it learns it. You know, 299, 298, and so on and so forth. Well, fortunately, eventually, this is going to get down to zero. And once it gets down to zero, those addresses get removed. As traffic continues to come in from, let's say that this MAC still does live out that interface, it'll re-up the timer.

7:04It'll go back up to 300 seconds from the last time I saw a packet come in that had that source address. But once it gets down to zero, it will remove it. And so even though we have a bad situation with a black hole-ing type of, you know, scenario here, what's going to end up happening is the timer will expire, then we go back to flooding. And so once we go back to flooding, in theory, that traffic will get to the destination, and hopefully that destination replies in some way.

7:35And so we learn where it actually is. But after that timer expires, because of the flooding mechanism, at least we no longer have a black hole-ing type of scenario. And we can actually tune the aging timer if we want to. But again, by default on iOS devices, that's going to be 300 seconds.

0:01All right, let's jump into the lab and just see a quick demonstration of looking at the Mac address table. This is probably something we've done at some point during troubleshooting sessions, but we wanna do a "show mac", and then it's "address-table". We can add enter, we can filter by VLANs and buy specific addresses. We might take a look at that later. But ultimately, what we find is a few things with this, first of all, the two important factors are always going to be the Mac addresses themselves, as well as the interfaces that they connect with. Now another critical component is certainly going to be the VLAN.

0:33So we see the VLAN ID over here on the left. So on this switch, we've got a lot of VLAN one devices, but also a few in 10 and 24, 34 and 23. Now the other big component is dynamic versus static. Now dynamic addresses are the ones that are learned. So these are truly devices that are out there, some of these are routers in this lab environment that have set traffic, and so we learn a lot of different Mac addresses that way. But we do see these static addresses, And specifically we're going to see static addresses, a long list of them up here at the top, a lot of devices have these static mappings that they're reserved for various purposes and used for internal traffic.

1:16So depending on the platform, maybe you'll see these, maybe you'll not see them, maybe there'll be a lot of 'em, maybe there'll be a few of them. But, and that's why it says "Vlan ALL" here is because it applies to all of them. So these are reserved values is really what it comes down to. But once you get past this all section, you really look down in here. What you end up finding is that when you see a static address, it's usually one of two things, first and foremost, it might be a VLAN interface. We're looking at a switch, we created that layer three interface. If I do a "sh int" on VLAN one, we should expect to see it end with 8ac7.

1:51So when I look at the Mac address here, 8ac7 right there. So this is the MAC address that's being used by that VLAN interface. So let's go back to the Mac address table. And so we'll find that we've got specific ranges of Mac addresses that'll be used by the device when those VLAN interfaces are made. Now we also see 8ac6 down here, that was mapped to a different VAN interface, a VLAN 10. So that's the first usual suspect with where these static addresses came from.

2:24The other possibility is that I can get onto an interface and I can hard configure some of these Mac addresses, and so those might show up here as well. But for the most part, it's going to be lots of dynamic interfaces that are learned, and then the static addresses that are either reserved by the system or are deployed onto some layer three interface also on that system. Now one other thing, let's go ahead and see what happens when we clear the Mac address table. So I can say "clear" and then "mac address-table".

2:54If I run a question mark here, I do have to specify what exactly I'm clearing, I want to clear the dynamic addresses. Now if I clear the Mac address table, on the one hand, it's going to be empty pretty quickly, but we're gonna find that all of the static addresses are still there, including VLAN one and VLAN 10. Now I did that as fast as I could, (speaker laughing) we have already learned some dynamic addresses. So we did see up here, we had a lot more dynamic addresses than we have now. But as I continue to look at the Mac address table, we're gonna find that more and more addresses are learned because these devices continue to send their traffic.

3:31And yeah, in the first frame it gets flooded out, but we very quickly learn where all of these devices are and the flooding is reduced. So clearing the Mac address table fortunately isn't disruptive because the flood and learn mechanism, I'm gonna continue to flood traffic so it does get to the destination. So clearing the Mac address table will result in a lot of flooding, but it also very quickly shrinks back down because we have traffic flowing, and we're going to be very quick to learn where those addresses are again.

0:01Anytime we talk about our MAC address tables, we are really referring to this as CAM a CAM table instead. And technically speaking we should probably refer to them as CAM tables, but what exactly is CAM? I mean, what is this concept and why is it so important? Why is it brought up so often? Well, in order to understand CAM, we need to understand at least a basic concept around standard memory use what we might call addressable memory so without the C, you know, basically what happens is when our CPU needs information, it goes to our memory allocation.

0:37And our memory allocation is, we could think of it like a spreadsheet or a database type of situation where we've got columns and information. And typically what we have is we have an index and we have a value that's stored there. And so in index zero, one, two, three, and four, in this situation I might say, "Hey, guess what? I need the information that's stored at index two." So maybe there's a binary 1010 stored there. So the CPU says, "Hey, give me what is at index two."

1:09And the memory controller returns 1010. Basically what we're doing is we're providing the index and we're getting the content back in this fashion. So that's great and all, but this is not how we are going to do things with our Mac addresses. And the reason for that is because I don't actually have an index value when it comes to Mac addresses. I actually have a Mac address and I need a port.

1:40Just kind of interesting 'cause basically I have two different values. I have a value here and I have a value here. So what exactly am I going to do here? Well, I build out a content addressable memory type of allocation. And what this looks like is basically what we have is we're going to build the same concept, except now I have my content here, and so this would be the MAC address. And then I have another value over here, which would be the port.

2:12So when the CPU now needs to get a port, I'm no longer providing an index, I'm providing a Mac address, and this Mac address could be stored here, MAC1, MAC2, MAC3, it could be anywhere in this table. And we could have thousands of Mac addresses in this table. So we see the problem here is I can't just say, "Hey, give me whatever is in index three or what have you." I'm saying, "Hey, first of all, you have to find this Mac and then you have to return the value."

2:42And so this is gonna be a little bit different. If this was addressable memory, standard addressable memory, what we would do is we would just cycle through this over and over again. You know, Hey, is this Mac address, let's say this is Mac address four in this case. So is it in this location? No. Is it in this location? No. Is it in this location? No. Is it in this location? Ah, finally we found it and we could return the port. So this could actually take thousands of attempts to return the port back to the CPU.

3:14So instead, what we want to do, is I wanna say that's a really bad mechanism. What we're going to do is we're going to actually use content addressable memory content. Addressable memory runs a single cycle. So it's one cycle on this and it's going to find an exact match. So if we were to just reduce our Mac address down to maybe saying that it's a few bits here. Let's say we're looking for 1010. Naturally we have 48 of these bits for a Mac address.

3:45But let's say I'm looking for this, what's going to happen is it's going to run through this entire memory bank basically, and it's going to look for that exact match, whatever that Mac address is. So in our case, it's going to find that the MAC address that we were had submitted is right here. And so now I can, in a single cycle, get the port and return that port back to the CPU cycle. So that is exactly what CAM is and why we use it here.

4:16Now a couple key points here. So first of all, as far as CAM is concerned, we are looking for an exact match, right? We're not able to submit masks for the Mac address world. And that's fine because when it comes to layer two, we have an exact Mac that we're looking for and we just need the port back. That's basically what we're trying to do here. So an exact match works great. The other issue is that CAM is expensive because we deploy a high performance level of memory into hardware.

4:51So another reason why it's so difficult to virtualize switches is because of this hardware based component that has been so important in the switching world for so long. And so obviously if we don't have the hardware, we're just virtualizing things, we have to do this in software. And so the emulated platforms make that happen. But ultimately CAM is a finite resource, and that's really what it comes down to. This is why when we look at spec sheets, we can only support so many Mac addresses.

5:24This is a big deal in the data center space because we could have thousands of virtual machines that, we've gotta learn thousands and thousands of Mac addresses. But this is a big deal in the campus environment as well, because we have to keep track of how many Mac addresses maybe exist in a layer two domain. It's another reason for us to shrink our layer two domains from a design perspective. And so this is all coming back to the idea that you know how Mac address tables run. We use CAM tables as a result. And what we're gonna find is that this is not a sufficient way for us to perform other lookups, that it do involve masks if we don't have an exact match.

6:04And so that's where TCAM is going to come into play.

0:01We just got done saying that content addressable memory in this CAM space is perfect for Mac lookups because our Mac addresses, when we're looking them up, we need to find an exact match. We're not submitting any kind of mask along with this, or we're not storing the Mac addresses along with a mask. We are storing exact Mac addresses and so we can't use masks with CAM. And if we want to use masks and we have a lot of use cases for masks in the networking world, we're going to have to store the mask in the table.

0:35This is going to require different type of memory that we call Ternary content addressable memory, which can be abbreviated as TCAM. CAM stores two values, if we think about it, we've got the value that we're storing, which is an exact 48 bit Mac address. And then we've got the result on the other side, which in our case would be the port. So the port is the result. The exact full 48 bit Mac address is the value that we're storing there. With Ternary CAM, we get a third value or a third parameter.

1:09We store the value, some number of bits in here, but then we also store a mask along with the value. And then we've got the result. This is why we call it Ternary CAM. The word ternary is in reference to the number three. We are storing three different values here, which is going to allow us to use the concept of a mask. Now again, we've got a lot of different use cases for masks. If we think about where we use masks, probably the first thing we're gonna come up with is IP routing. I'm gonna look up a routing table entry, I know that I include masks with the entries in that table.

1:45Now, I also have to think about access control lists to think about quality of service. And by the way, IP routing can be split off between IP version four and IP version six, since both of them use masks. So here's the idea. What ends up happening is the CPU is sending, let's say something to the TCAM which says, hey, I've got to send a packet and it's destined for 10.0.0.25, something like that. Give me a result.

2:16Basically an outgoing port or a next top IP address, whatever is stored there for this address. Well, we might have 10.0.0.0 in here. We might have 10.0.0.8, something like that. And then we've got different masks in here. And so basically these are the don't care bits. And so maybe we're gonna find that this 10.0.0.0 entry, this was using a slash 24 mask.

2:49Whereas this entry down here, this is using like a a slash 29. So now we've got two different masks that imply different things. Now in this example, this address doesn't fall into the subnet, it only falls into the top one. And so we can pretty easily say, well, this is our match and we're going to provide the port, send it out gig zero zero or whatever the situation is. Naturally, if we have two of these values that fit, well, both of them would be matches and we'd have to run the longest prefix match, which is going to hopefully identify for us one or the other.

3:24So let's say we had 10.0.0.24 slash 29. Well now it actually fits into this one as well. And so we'd find matches for both of these, but we'd use longest prefix match to identify that this is the right entry and therefore we're going to return this result of gig zero slash one or whatever the situation is there. Now, that raises an interesting point 'cause the result could be many different things. We could actually have these as interfaces, we could have them as next top addresses. Access control lists are going to store, you know, their deny or allow result in here.

4:00And so we've got a lot of different options to include in the result. And so the TCAM space gets to be a little bit more complicated, especially, and we consider the fact that we're including a mask in the calculations. Now, just like with CAM, TCAM is also expensive. It is also deployed in hardware in most cases. And as a result, we have a finite amount of space for the TCAM. The difference here is that our CAM had a finite amount of space, but it's all Mac addresses.

4:31We don't need to worry about trying to fit IP addresses in there and sharing that space with the CAM. Whereas over here we've got a lot of different options and potentially even IP version four and IP version six entries that all have to cram into the same finite space. So most of our Cisco devices are going to carve this up some way from the beginning. There'll be a default setting where we've got so many IPV four routes or space for IPV four routes, so much space for access control list, quality of service entries, and so on and so forth. What we might find though is that in order to enable IPV six on a platform, we actually have to change the TCAM configuration or vice versa.

5:08Maybe we have a default of so many IPV six routes that are stored in there. And as a result, if we're not running IP version six in our environment, we actually wanna disable that and give us more CCAM space for IP version four. But this is a finite resource on every Cisco platform. And so we just in some situations have to be aware that we might have to reconfigure the TCAM depending on the scale of our environment.

0:00All right, let's jump onto the CLI and see some commands in action that relate back to everything we've been talking about. One of the biggest commands we're going to use a lot is show Mac address dash table. Now the good news is that we can actually abbreviate that down. It's interesting, because it looks like we abbreviate down to show Mac address. But that address is actually in reference to address dash table, so keep that in mind. Now, we're on this CML topology. So this is the CML topology that's available for download.

0:31You should be applying this into your CML environment and following along and then conducting the lab challenge at the end of the skill. So what we have is we have a couple of virtual switches with a couple of virtual routers attached to those, fairly basic topology. We just wanna see how these switches are logging the Mac addresses and what we can do that might be interesting from a Mac address perspective. And so one thing to keep in mind always with these virtualized switches is that emulated switches, they don't always behave fully 100% correctly.

1:03Switches are actually very difficult to emulate. It took a long time for us to have virtual switches that were useful. And so these are very useful, but as you'll notice, we don't actually see all of the static addressing that we maybe would see on a physical switch. This is one reason why I recommend having physical switches in addition to your lab. We're probably gonna need those down the road for SDA anyways, but for right now even, the virtual switches are great, but it's still not showing the full picture. For example, if I switch over to that hardware switch we were looking at earlier, I can run the show Mac address command here and we do see all of those static mappings, the dynamic mappings, that's what we'd expect to see in a real world switch.

1:48Whereas the virtual switch is only showing us addresses that it's truly learned from packets flying around. And so what we have here are a few Mac addresses, especially routers one and two because before I sat down, I generated traffic. I pinged from one router to the other to make sure that we had some Mac addresses in this table. And so I could, for example, clear the Mac address table, clear Mac address dash table. And then we do have to specify the fact that we're going to clear the dynamic entries.

2:20You may recall, by the way, that we had more options on the hardware switch. So again, just another nuance to the software switches. So after clearing it, I can look at it again. Now all of the Mac address entries are gone. So what if I come to router one and I ping? And so that address that we're looking at, router two is 28.50.1.2. So I ping across. Should find success there, very good. And now when I show Mac address, I should see all those Mac addresses populated.

2:51So two of those are gonna be our router. Another one is just one of the switches or something that is being generated in this lab environment. And so we now have two Mac addresses from our two routers in here. Now before we move on to configuration, some other show commands we might wanna be aware of, I can do show Mac address table. And then what's interesting here is I can say address again, this time for literally the word address. The full command would look like this. Address dash table, then address, and then I can specify the address that I'm looking for.

3:23So if I have thousands of entries in this Mac address table, this can be very useful for flagging down an individual port for an individual Mac address. But again, we can abbreviate it like this. Show Mac address, address. Whoops, address, table address. It looks like show Mac address, address. But that is the command that will get us there. We can also do a show Mac address table count, and this will give us a count per VLAN of how many Mac addresses there are on each cam table individually.

3:53And then we can also do show Mac address table and then aging time. So this command is going to show us the global aging time as well as on a purview end basis which we can actually change. So again, the default is 300 seconds, which is five minutes. So let's go ahead and think through what are some interesting things we could configure from a Mac address perspective? Well, one thing we can do is we can configure custom Mac addresses. So if I do a show interface gig one on this virtual router one, I see that I've got a burned in address, which is a little ironic since it's a virtual router, but we still call it a burned in address.

4:30And our current operating address is the same. It's that CC 78 that did show up. Let me go up here, right here. We do see this Mac address show up here, which is the after we generated traffic. So we've got that burned in address. What I can do is do a config T interface gig one, and we're used to, IP address for example. Instead I can do Mac dash address and then specify the Mac address. Cisco likes their... If we wanna call it dotted decibel format, we usually refer to that for IP addresses, but this is using the decimal format rather than colons for Mac addresses.

5:07So I could tell router one to use 1.1.1 as the Mac address. It's going to flap the interface down and then back up. And at that point, it will be using, we're still waiting for it to come back up here. But in the meantime, ah, there it goes. Show interface gig one shows that I still have that same burned in address, but the Mac address is now changed on the interface. So if I do a ping, let's just cycle back up here before we pinged router two, let's run that ping again. That took a moment because router two had to re-ARP for the new Mac address.

5:40And now, if I come back here and do show Mac address table, we should see that 1.1.1 is indeed in the table. Now we do still see CC 78 in here because it hasn't timed out yet. So now without any traffic coming in from the old Mac address, we'll find that this entry does indeed go away eventually. So we see router one's custom Mac address now showing up in the table. We could do that on router two as well, but it would look the same. Next, we could change the aging time itself.

6:12So this is gonna require us getting in here, configure terminal, and then we can do a Mac address table command. We're gonna do question mark. We can see some of the things we can do. I could configure an aging time. I can configure static address. So we'll look at both of these. First of all, the aging time. So if I do aging time, I'm gonna specify how long I want something to last, or the aging timer to last. So I could specify maybe 10 seconds in here. This is in seconds, by the way. It allows for a pretty wide range of configuration, 10's actually the minimum.

6:43And then I do have to specify a VLAN if I want to, or I can configure this globally. Let's just say that this is for VLAN one. So at this point, our Mac address table, if we do a show Mac address table, we should see that it's actually cleared out pretty fast there. (laughs) When we change the aging timer, it's going to clear the Mac address table. And then if we do a show Mac address table aging timer, we'll see that the global timer is still 300, whereas VLAN 1's is now configured custom to use 10 seconds.

7:18One interesting note in all of this, check this out. Enter zero to disable the aging timer. So if I wanted to outright disable aging, which is really not advisable, but if Cisco asks us to do it for some reason, this is where we would do it and we'd use zero as our parameter. So next, we want to demonstrate the concept of a static Mac address. Now, this is not particularly going to be a common configuration, but it is worth noting that if we do that Mac address table, and we did that question mark, we saw static show up.

7:51So static allows us to configure static mapping, like let's just say 4.4.4. We don't have that in our environment. And so from here I have to specify the VLAN. So we'll just say this is in VLAN 10. And then what interface? So this is truly creating a hard mapping. Let's just say this is going out gig two. Oops, we've got to specify, I guess, (laughs) a little bit more of a name. All right, fine, gigabit ethernet two. And that is not taking. Let's just say gig zero. No?

8:21You know what I just realized, we're on switch one, not on router one. (laughs) So this is actually expecting something like zero two. There we go. That would be what was holding this up. So now let's exit out and do a show Mac address table. And we see that we have a static mapping for the all fours, pointing to gig zero two. And I can try to clear this out, clear Mac address table dynamic.

8:51And it's not going to clear out because I'm only able to clear dynamic addresses, as we've shown, we can't clear static ones. Now a couple of other interesting things, and this is going to require switching over to the hardware switch because it's only supported, not that one, this one, on hardware. We've got a couple other commands to look at. So first of all, if I do a config T, I can tell a switch to always drop specific Mac addresses, which is interesting. So I can say Mac address table.

9:24And basically what I'm gonna do is I'm going to create a route to this layer to address that says that, "Hey, we're just gonna black hole the traffic." So Mac address table static, and then I specify the address 5.5.5, and then I specify which VLAN this is part of, let's say VLAN 10. And then instead of specifying the interface like I just did on the virtual switch, and we did notice, by the way, that I think I ran the question mark command up here. Yeah, the only option here was interfaces, because it's the virtual switch, it doesn't actually run a true cam table.

9:58And so they limit what we can configure. So back to the hardware option. And this hardware option, I can specify the drop. So I can say drop here. And this creates a rather interesting looking entry. Show Mac address table. And we're going to find that we've got a static option or a static Mac address entry of 5.5.5. But check out the value in there. It's not an interface anymore, it is simply saying that we're going to drop it, which is kind of interesting.

10:29The last option that we can only do on hardware switching is we can actually disable learning altogether. So this is pretty fascinating. So we can say no Mac address table learning, and then we have to specify what VLAN. So I'm gonna say VLAN 10. Let's see here. We've got 24, let's just do VLAN 24. Doesn't really matter. So I'm going to disable Mac address learning on VLAN 24. Now the switch won't allows us to do this on VLAN one, but we can do it on any of the other VLANs, I suppose.

11:02So again, this give us a very big warning. This is not advised, this is not something we should do. It's going to rely entirely on flooding at this point. So we have to be very careful about ever deploying this in a real world situation. But a lot of these commands are less about real world and more about just understanding what options are out there and making sure we understand how to go about doing something if we're given a lab task that might require it. So that's pretty much our overview on Mac addresses and all of the commands.

11:32And now it's time to jump into the lab and perform a challenge that calls a lot of these commands into us performing them.

0:00Okay, let's perform these lab tasks together. So I have a freshly started CML instance. Here we've got router one, switch one, switch two, and router two. So aligned left to right, sort of like our lab topology there I suppose, or at least, hah, from a sequential perspective. So the first thing is on switch one, we wanna validate the Mac addresses that are in here. So we're going to log in and do that. Show Mac address, table command. And we need to find out if these are actually router one and two's Mac addresses.

0:31So we're gonna be focusing in on gig one. The way we do that is do that show interface and then we can see that CC seven eight is R one and over on this side show int gig one ED five F. So we've got CC seven eight and ED five F. So we do have both of them in here. Now, if you fired up your lab environment and you let it sit for five minutes, these entries might not be there. So it did say to ensure that they show up dynamically. The best way to do that is to simply ping from one side to the other.

1:03So we should have layer three connectivity here. It's actually just a VLAN stretched across. So could even argue it's just, uh, layer two connectivity, but either way we're pinging across and we get to router two, no problem. So that would be task number one. Now, task number two, we want to change the Mac aging timers on switches one and two. So we're gonna get onto switch one and we wanna make sure that addresses age out after one minute. So we're gonna do a config T and we're going to, let's see here, we're going to use the Mac address table command.

1:37So what we wanna do is we wanna change the aging time, aging dash time and we can set this globally or we can set it on a per VLAN basis. Now we're going to set this to age out after one minute. Again, this is in seconds. So we wanna say 60 here. And then we can hit enter and this will enter it in globally on switch one. Now switch two, switch over here. We want to make sure that they never age out, which is again, not really an advisable situation, but certainly something we need to make sure we know how to do.

2:09So, um, MAC address dash table. And then we're going to specify again that aging time. And remember this is where we disable aging. We say zero here and then we can specify our VLAN. So we're gonna specify VLAN 10 in this case. So we should always try to validate things. We wanna do show Mac address aging time. And so we do see that the global remains the same on switch two, but we have no aging time on VLAN 10. And then same thing over here, show Mac address table aging time.

2:42And we do see the global has been reduced to 60 seconds. So task two should be complete with that. Next, task three. So change router one's, gig one interface to the one that we listed out. So we're gonna do config T interface gig one, and then remember it's the mac dash address command. So this case we wanna do 0, 0, 1, 1 dot 0, 0, 1, 1 dot 0, 0, 1, 1. Now we can do that, but do keep in mind that we can also say 1, 1 dot 1, 1 dot 1, 1 like this.

3:12And so it'll accomplish the same thing 'cause we can trim off the leading zero. So however you did it is fine. And we wanna do this on router two as well. So config T interface gig one and MAC address and 22 dot 22 dot 22. Now it's said to show, make sure that these Mac addresses show up in this switching table. So if I do a show Mac address table, you know 11 actually did show up, so that's kind of cool. It generated some traffic there that let us learn that.

3:42The best way to make sure both sides get added is once again to generate some traffic. So we're just gonna ping across 25 dot 50 dot 1 for VLAN one and then dot 2 for router two. So once we do all the ARP things, we've got our pings across and hopefully now we get 11 and 22 showing up in this table. So this is a good thing. We've got both 11 and 22 in the table, which means task three is done. Task four, we want to perform a couple of interesting tasks.

4:14So number one, on switch one, we're going to make sure that we can create a static entry. So this is that MAC address table. And then static command. So what we said we wanted to map is 33 dot 33 dot 33. And then we need to define, decide which VLAN to place this into. So we're going to place it into VLAN 10. And then from here we specify the interface. So we have to say interface and then gig zero slash two.

4:47So from here we wanna make sure show Mac address table. I wanna make sure that it shows up and it does. 33 is appointed to gig zero two in VLAN 10. So that is a successful, um, task. Now, task sub task two here is we want to drop all of the command or all of the traffic going to 44. Now again, this is one of these that's not supported on a virtual switch. And so we're going to fire up a physical switch at this point.

5:19Again, as we've said before, it's always recommended we have a couple hardware switches available. Naturally we couldn't provide that with the CML file. And so if you weren't able to perform this task, just make sure you have this part memorized. So the way we do this is we do the MAC address table command, and we're forming a static mapping. And so this was to 44, 44, 44, but this time we were run the question mark. Whoops, that's right, VLAN 10, that's we said. Now we have to decide are we mapping into an interface or are we just going to drop it? We can enter drop here and that will add the entry.

5:51So show Mac, address table. And we should see that this manual mapping Just we did earlier is getting dropped. But again, unfortunately the virtual switch just doesn't support that. Now lastly, task five is very similar in that we have to do this on a hardware switch, activate flood and learn behavior for all layer two traffic on switch two. And so we need to disable learning. So we're gonna do a config T, and this is the no Mac address table learning.

6:22And then we can specify a VLAN, so VLAN 10 and we can disable the learning there. So that is how we go about performing these different tasks. Hopefully by the end of this you feel like you were able to perform all of them well. If not, then just go back and do the lab again. Otherwise, I hope this has been informative for you and I'd like to thank you for viewing.