1. 7.0 Using Ethernet Switches
I’ve got a question for you. Do you know what’s at the other end of the Ethernet cable plugged into the back of your computer right now, assuming you have a wired connection and not a wireless connection? The other end of that cable is probably plugged into an Ethernet switch. and that’s going to be the focus of this module. Specifically, you’re going to learn how an Ethernet switch makes intelligent framing decisions and how we can logically group different switchports into different VLANs. And from a design perspective, we’re going to dive deep into the world of spanning tree protocol, which lets us have redundant connections in a switched network while avoiding some of the unsavoury side effects of having a layer-two topological loop. And we’re going to get started with all that in the next video, where we’re going to be examining a key piece of information that’s used by the switch to make that intelligent forwarding decision. It’s called a Mac address.
2. 7.1 MAC Addresses
In an Ethernet network, every device is uniquely identified with a Misaddress, a media access control address. And that’s what we’re going to be focusing on in this video. We want to take a look at the structure and purpose of Mac addresses. The first thing I want you to understand about a Mac address is its length. It’s 48 bits in length. That’s as compared to an IP version 4 address that has 32 bits or an IP version 6 address that has 128 bits.
And these 48 bits are written in hexadecimal notation. With hexadecimal, we don’t just count from zero to nine. When we get to ten, we say A, and eleven equals a B. So we have the digits 012-345-6789, ABCDEF. There are 16 possible values that we could have represented with a single hexadecimal character. So let’s think about this in binary. If I have 16 possible values, how many binary bits does it take to give me 16 possible values? Four. We can have four bits represent any of 16 different values, which means each hexadecimal digit is made up of four bits. Well, if we have a 48-bit Mac address and we’re writing this in hexadecimal notation, that means we’re going to have twelve hexadecimal digits. And these twelve hexadecimal digits are broken into two different parts. The first half of the Mac address, the first 24 bits, or the first six hexadecimal digits, is called the “Oui,” the organizationally unique identifier.
This portion of the Mac address is given to the vendor when they create network interface cards, or as some people prefer to call them, network interface controllers. But these little nicks burn a 48-bit Mac address. And the first 24 bits are their vendor code. And some manufacturers are large enough that they have multiple vendor codes. Then for the last half of the Mac address, they can pretty much use whatever number they want. These are the Nic-specific digits. So this is the format of a Mac address. We have an organizational unique identifier, the vendor code, and then the vendor assigns the last 24 bits. As an example, I took a look at the Mac address on my Apple Mac computer, and it has this as the vendor code or the organizational unique identifier. And then the last 24 bits in hex looked like this. In fact, you can conduct a search on the Internet to determine which vendor code is associated with which manufacturer. So this is the structure of a Mac address.
Now let’s ask, why do we need these? Why are they so important to our network? Let me give you a couple of examples. First of all, let’s say that I’m on a PC and I want to get out to the Internet or get out to the rest of the world. It’s not enough for me to know the destination IP address that I want to get to. I’ve got to know, how do I get there? What is my default router’s IP address? That’s my default gateway. And I was probably given that information automatically via DHCP, or maybe it was manually configured, but somehow I know the IP address of my default gateway. That’s my next hop. That’s where I go to reach out to the rest of the world. However, it’s not enough for me to just know the IP address of my default gateway. To properly form a frame, I’ve got to also specify the Mac address of that default gateway. and I don’t know what that is when I first boot up. So I’m going to send out an address resolution protocol and broadcast an ARP broadcast saying, “Hey, does anybody know the Mac address corresponding to my default gateway’s?” Ten one one IP address and the gateway sees that. It responds and says, “Yep, that’s me, and here is my Mac address.”
Now I can properly form a frame to send to my default gateway, which is then going to send it out to its final destination. Another use of a Mac address has to do with Ethernet switches. When we have all these different network interface cards connecting into the different ports on our Ethernet switch, the switch is going to build an internal Mac address table. It’s going to learn what Mac addresses live off of which ports. So when it learns that the Mac address is living off of different ports, when a frame comes in destined for a Mac address that it has learned off of one of the ports, the switch is only going to forward that traffic out of the port that it knows is connected to that destination Mac address. So that’s a look at the structure and a couple of uses of Mac addresses.
3. 7.2 Ethernet Switch Frame Forwarding
In this video, we want to do a quick review of how an Ethernet switch does its job of forwarding Ethernet frames. And then we’ll take a look at the Ethernet frame format. But to begin with, a switch is going to make intelligent forwarding decisions based on Mac addresses. Those are the 48 bits burned into the addresses of each of our Ethernet clients’ network interface cards.
And when the switch sees frames come in, it’s going to take a look at where the frame came from and start constructing a Mac address table. For example, a laptop user wants to talk to the printer, and the switch, let’s pretend, has just booted up. It has not learned any Mac addresses. When this laptop sends a frame into the switch with the allc’s Mac address as the destination, the switch will do a couple of things. It will be noted that the old A’s Mac address just arrived on gig one. It’s going to make a note of that in the Mac address table. However, it will then duplicate that frame and send it out all ports other than the one it came in on. So it sends a copy to gig two, gig three, and gig four. That process is called flooding. The switch is desperately trying to make sure that the frame does make it to its intended destination. And the good news is that it did. It got to the printer.
The printer says, “Yep, I’m the OLC’s Mac address,” and it responds to the laptop. And when it responds, notice that the switch does not flood that frame because it has learned that the destination Mac address is all AS, and it lives off of gig one. And when it sees that frame come in for the printer, it adds that OC’s Mac address to its Mac address table. So now, when the laptop wants to talk to the printer, it’s going to go directly to the printer. It’s not going to be flooded anymore. Let’s take a look at another example. Let’s say that laptop two with the old B’s Mac address wants to talk with the server with the old D’s Mac address. Well, when the frame goes into the switch, the switch has not yet learned that the old DSMac address lives off of gig four. So what’s it going to do? Yeah, it’s going to flood it out of gigs one, three, and four to make sure it gets to its intended destination. But the switch is going to make a note that the all-bees Mac address lives off of gig two.
And then, when the server responds to the laptop too, when it comes into the switch on gig four, the switch makes a note of that. It now understands that the old D’s Mac address is based on gigabyte four. At this point, this switch has learned which Mac addresses live off of which ports. When a frame arrives destined for any of these four destinations, the switch will only allow it out of the appropriate port. And here’s an example of what an atypical Ethernet switch might look like: This is a Cisco catalyst switch, and it’s got 48 ports that we can use to connect out to end stations. It’s got a couple of uplinks that can connect us to another switch. Notice the uplink speeds can be up to 40 gigabits per second. We’re trying to prevent any sort of bottleneck as we’re interconnecting our switches. And we said that the switch was going to be forwarding Ethernet frames. But what does an Ethernet frame look like? Let’s take a look at the structure. I’ve also included some layer one information here, including the preamble and the SFD. One of the things I want you to know about an Ethernet frame—in fact, you might want to put this in your notes—is that an Ethernet frame has an 18-bit header. We’re going to add 18 bites to the layer three packet. But, before we get to those 18 bytes at layer 1, there is a seven-byte preamble. And these bytes are analogous to blowing a trumpet and proclaiming “dump, dum, dum,” here comes an Ethernet frame.
And then that’s followed by an SFD. And that is a delimiter for the first frame. only one bite, but it says, and the frame starts now. So these eight bites are essentially preceding the frame to say, “Here comes an Ethernet frame; it’s starting now.” At this point, we get into those 18 bites. Six of those 18 bites are made up of the destination Mac address. We know that a Mac address is 48 bits long, so that would be six bytes. That’s where this frame is headed. We also need to know where it is coming from. What is the source Mac address? That’s another six bites. Next, we say what kind of data is contained in this frame. And when we’re told which type of data that’s probably going to be IP version four or IP version six, that’s going to be told to us in the two-bit type field. and that makes up 14 of our 18 bites. We’ll get to the other four bytes in a moment. But next up, we have the data. What is contained in this layer-three packet? And this is referred to as the data in the pad. because this chunk of data must be at least 46 bytes in length.
And if it’s not, we’ll put some padding there to make it that big. There’s also a maximum size for this combined data and pad, and that’s 1500 bytes. We call that the MTU for the packet size. That’s the maximum transmission unit of the layer 3 packet. Let’s now add the last four bytes of that 18-byte header, which are made up of a frame checksequence or an FCS that performs error checking to ensure that the header is not corrupted. So if you add up six bytes for the destination mac, six bytes for the source mac, two bytes for the type field, and four bytes for the FCS, that’s a grand total of 18 bytes. So if we add on those 18 bits to the maximum transmission unit size of the packet, which was 1500 bytes, that gives us a layer-two MTU of 1518 bytes. When we talk about a maximum transmission unit, we need to specify: is this a layer-two MTU or a layer-three MTU? Because here we’re seeing that a layer 2 maximum transmission unit could be 1500 plus 18, but at layer 3, the packet size maxes out at 1500 bytes.
Now, this is a standard Ethernet frame, but would you agree that we could be a bit more efficient in our transmission if we could send more data inside of one frame? That would cut down on a lot of header information that we wouldn’t have to send otherwise. And what some equipment supports is something called a “jumbo frame.” A jumbo frame is going to allow the maximum packet size to be a whopping 90 bytes. That’s six times as many bites as the 1500 that we have by default, and that’s going to allow us to send more data in a single frame, thereby reducing the amount of header information that we have to send. But in order for this to work, both ends need to agree that we are supporting jumbo frames. Otherwise, we might get some sort of error saying that this is a giant frame; it’s too big. But if we set both sides to support jumboframes, yeah, that’s a 9018-byte layer-2 MTU, and that’s a review of Ethernet switch operation and a dive into the Ethernet frame format. You.
4. 7.3 VLAN Theory
In this video, we want to consider “virtual LANs,” or VLANs for short. Consider this layer to be switched on screen.Those 48 ports on the front are, by default, all part of the same broadcast domain. A broadcast sent to one port is going to show up on all the other ports because they belong to the same subnet or broadcast domain. Or we could say the same VLAN.
Many of our layer 2 switches will have all of their ports assigned to VLAN 1 by default. However, we might have different departments connecting to the very same switch. We might want them to belong to different subnets, or, in other words, different broadcast domains. Maybe we have a sales department and an engineering department. We don’t want them to see each other’s printers by sending broadcasts. So what we might do is carve out maybe twelve ports and dedicate those for sales. We’ll say that the sales VLAN is going to be numbered VLAN 10, and it represents the subnets of 170, 216, and 100:24. Maybe we have another twelve ports dedicated for engineering users, and we’ll say it’s numbered VLAN 20, and the subnet for VLAN 20 is 192, 168. Let’s say we have a couple of computers. The computer on the bottom left belongs to sales, and the other computer on the right belongs to engineering. and they’re going to connect into their respective VLAN ports. And at this point, these two computers are isolated from one another. They cannot communicate with one another because, even though they’re plugged into the same switch, they belong to different VLANs and different broadcast domains.
In other words, different subnets. How do you get from one subnet to another subnet? You have to route. So if I want to go from one laptop to another, I’ve got to add a router into the mix. And I can connect the router to that switch using a special connection called a trunk connection. and a trunk, and this is good for your notes. A trunk has the unique ability to carry traffic for multiple VLANs. As a result, that switch’s trunk port can send traffic to the router for VLANs 10 and 20. And the default VLAN and any additional VLANs we add can all flow over that trunk and router port into which we’re connecting. You might wonder to what subnet it belongs. It could belong to all the subnets. Here’s the deal: We take that physical interface, and we can configure a bunch of sub interfaces on that physical interface.
We can have one sub interface using the IP address space of VLAN 10, and another sub interface using the IP address space of VLAN 20. So if I wanted to go from the computer on the bottom left to the computer on the right, here’s what would happen: That packet would flow into the switch, down to the router, back to the switch, and out a VLAN 20 port to our other computer, all while being routed through a layer to the switch. However, there are some switches out there called multilayer switches, or sometimes they’re called layer three switches. Those types of switches have routing capabilities built in. They can do routing without having to go out over a trunk connection and connect to an external router. They can do routing internally. But I want you to understand from this video that we can take the ports showing up on our switch and carve them into different subnets, different VLANs, which are different broadcast domains.
5. 7.4 Trunking Theory
Let’s say that we have a couple of Ethernet switches, each of which has two VLANs created. We’ve got a VLAN for sales, we’ve got a VLAN for engineering, and maybe on the top switch we have a sales PC connected to the sales VLAN indicated with the blue highlight. And we’ve got an engineering PC connected to the engineering VLAN indicated by the yellow highlight. And the sales PC, you guessed it, wants to go to the sales server, and the engineering PC wants to go to the engineering server. And we want to do this without routing. We want to be in the same broadcast domain. And let’s assume that these are layer-two switches.
They’re not going to be doing routing. How can we interconnect the Sales VLANs on these two switches and the Engineering VLANs such that the Sales PC gets to the Sales Server and the Engineering PC gets to the Engineering Server? Well, one option is to have a connection from the Sales VLAN on the top switch down to a vacant port in the Sales VLAN on the bottom switch. And for Engineering, we’ll take one of their vacant ports and connect to one of the vacant ports on the bottom switch that belongs to the Engineering VLAN. But can you see that it doesn’t scale well? If I had ten VLANs, we would be occupying ten switch ports just to interconnect the switches. What’s much more efficient is to have a single connection called a trunk. And the most popular type of Ethernet trunk out there is a standards-based trunk. It’s an IEEE 802.1Q trunk connection. And a trunk has the very unique ability to carry traffic from multiple VLANs. So if the Sales PC wants to talk to the Sales Server, it’s going to flow between the switches over that trunk and then go out to the Sales Server.
And then the engineering PC can flow over that very same trunk to get to the engineering server. Which begs the question: how do I distinguish between a frame belonging to the Sales VLAN and a frame belonging to the Engineering VLAN? Well, with 802 and 1 Q, we add four bites to a frame. And these four bites are called tag bytes. Do you remember the maximum transmission unit size for an Ethernet frame? Assuming we’re not doing jumbo frames, the maximum transmission unit size for a regular Ethernet frame is 1518 bytes. 1500 bytes for the packet, 18 bytes for the Ethernet header. And now I’m saying we’re adding on four more bytes. Does that mean that we can have a frame size of 1522 bytes? Yes, it does. Is that a problem?
Doesn’t the switch look at a frame size greater than 1018 and say, “That’s a giant; we’re going to drop that”? Well, not in this case. If the switch supports one Q trunk, as they’re called, then it’s going to view that 1522-byte frame as a baby giant. I’m not making that term up. That’s actually what it’s called? It’s called a baby giant. It’s an acceptable giant because we know those extra four bites are from those tag bites. And inside those tag bites, we’ve got some different information. We can have a quality-of-service setting. But what I want you to focus on right now is that we have VLAN information inside of those tag bites. Let’s say the sales VLAN is VLAN 10, and the engineering VLAN is VLAN 20. Well, inside those tag bites, we’re going to identify which VLAN this belongs to. But there’s one exception, and the exception is the native VLAN.
The native VLAN is the only VLAN travelling over an Ethernet trunk that is not frequently tagged. It’s going to be VLAN 1 as a switch default, but you could set it to a different VLAN to be your native VLAN, your untagged VLAN. The big thing you have to watch out for are the switches at each end of this trunk. They need to agree on what VLAN is the native VLAN. If the top switch thought the native VLAN was two and the bottom switch thought the native VLAN was three, that wouldn’t work. The top switch would send an untagged frame, intending it to go to VLAN 2. But the bottom switch would see it, and they would say, “Oh, here’s an untagged frame that goes to my native VLAN of three.” That is why we must configure matching native VLANs in these switches. And again, they may default to a VLAN of one. But that’s a look at how we can have a single connection interconnecting our switches that can carry traffic for multiple VLANs. And we called it an Ethernet trunk.
6. 7.5 Voice VLANs
When you hear the term “unified communications,” we’re oftentimes talking about consolidating voice, data, and video on the same network. And if we put IP-based phones on the network, like we see here, those are Ethernet devices. They’re connecting into an Ethernet switch, and they’re competing for bandwidth with our other applications. So, for performance or security reasons, we may want to separate voice traffic into its own VLAN. That’s the topic of this video: creating voice VLANs. And we have three basic approaches. We could go into that switch port into which our phone is connected, and we could set that up as a single VLAN access port, a multiVLAN access port, or a trunk port. Here’s why we have those options: Notice that I have a laptop, or that could be a PC, that’s plugged into the back of this IP phone. It’s like a daisy-chain connection. Many IP phones, such as the Cisco IP phone we see here, have an extra port in the back into which you can plug a PC.
So, if you’re installing a slew of IP phones in an existing office, each cubicle and office may only have a single Ethernet jack. Do you have to run extra cabling or put a switch in each of those offices? Well, maybe not. What you can do is simply daisy chain the PC into the phone, and then the phone goes into the Ethernet port and back to the Ethernet switch in the wiring closet. And we may want that PC to be sending data on one VLAN and the IP phone to be sending data on a different VLAN, the voice VLAN. Now, let’s take a look at these three different options. The first option is that single VLAN-access port that we mentioned here. We do not separate the voice from the data VLANs. So that port into which we’re connecting the phone, even though we’re doing this daisy chain connection, is in a single VLAN, and that is an access port as opposed to a trunk port.
Recalling that a trunk port has the ability to carry traffic for multiple VLANs, we’ve only got one VLAN. Why would we want to use this when we have the option of separating the data and the voice into separate VLANs? In other words, into separate broadcast domains and separate subnets. Well, it might be useful if we have a third-party phone that doesn’t support voice VLANs explicitly. Or maybe we have some sort of software-based phone like Cisco Jabber installed on that PC. And you might wonder, Do we get any benefit at all from doing this? It seems like we’re all on the same VLAN, and we are. However, we can still identify the voice traffic as having a higher priority than the data traffic by using quality of service marking. It’s known as 802-1 P marketing. And when we talk about quality of service in this course, we talk about a layer-two marking called COS, or class of service.
That’s where, within an 82-one Q trunk frame, we’ve added four extra bytes, and we use three bits in those bytes to indicate the priority of a frame. That is how one Q trunking works. You’ve got these four extra bites on every VLAN that’s not the native VLAN. And in those four extra bites, we’re identifying the VLAN to which this frame belongs. And we could optionally set those COS bits. However, here with one P, we’re not really identifying the VLAN, but we are identifying what is essentially a clash in service marketing. So the question is, where do those three bits come from for one P mark? Well, this looks very similar to a one-q frame because we’re adding on four extra bites, just like a one-q trunk would do. And we’re using the same three cos bits to indicate the priority of a frame. And we’ll probably set the voice VLAN to a C OS value of five. A C OS value of zero may be assigned to the data VLAN. That’s what we commonly do. So how is this different than a dot-one trunk?
Well, there’s no VLAN identification in those four extra bits that we add. We’re adding on those four extra bites, those tag bytes, not to identify the VLAN but to identify priority. However, if we’ve got the option, yes, we would prefer to separate the voice and the data of VLANs, and there is one option for doing that. And this might vary from vendor to vendor, but on some Cisco switches, we can have what’s called a multivlan access port. Now, that’s almost a paradoxical statement, isn’t it? We said that a trunk port has the ability to carry more than one VLAN. And here I’m saying we’re carrying two VLANs on an access port. Well, here’s the way that those multi-VLAN access ports work: Specifically, on Cisco catalyst switches, you may want to check your vendors’ documentation, but Cisco says we will allow you to bend the rules a little bit. We will allow you to have a maximum of two VLANs on a port, and it’s still an access port if you promise that one of those two VLANs is going to be carrying voice traffic.
So we’re going to have a data VLAN, and we’re going to have a voice VLAN. And you might wonder, how does that phone know which VLAN it belongs to as opposed to the PC? Well, the switch port is going to recognise that we have a Cisco IP phone attached, and using the Cisco Discovery Protocol, or CDP, it’s going to inform the phone, “Hey, you belong to VLAN 400,” as an example. Now, CDP is a Cisco-proprietary layer 2 discovery protocol. It shows us our two adjacencies. There’s an industry standard, and that industry standard is LDP, or a variant of that is LDP-Med. This is not going to work with LLDP Med. It’s only going to work with CDP. So if you have a non-Cisco switch, or if you have a Cisco switch that’s not running CDP on that port, then you’re probably not going to use a multivlan access port. And I mentioned that with the single VLAN axisport, the frames looked a lot like dot-oneQ frames, except there was no VLAN identification. Well, here it looks kind of identical to adopting one Qframe, because we do have VLAN identification specifically in the voice VLAN. Now, remember the concept of a native VLAN. We said that a native VLAN does not have any tag bits added. It’s an untagged frame. Well, if we’re doing a multi-VLAN access port, the data VLAN is untagged. That’s essentially a native VLAN coming into this multivlan access port. But we do add those four extra bits to the voiceVLAN, and we’re identifying it as belonging to VLAN 400. But we’ve got that native VLAN on that switch port set to 300. That’s where the data frames are going to flow. And the third and final option that we have is a trunk port. After all, trunks have the built-in ability to carry traffic for multiple VLANs. And that’s what we can do.
We can have this trunk port that’s carrying traffic for both the voice and the data VLAN. In fact, it might be carrying traffic for other VLANs as well. We’ll talk about that in just a moment. But remember how I mentioned that the multivlan access port was incompatible with LDP or the variant LLDP Med LDP? By the way, that stands for link. Layer. Discovery.Protocol. CDP. That stands for the Cisco Discovery Protocol. Well, this is going to be compatible with either one. So if you’re using a third-party switch or a switch that does not support CDP, this might be the way you want to go. And the frames here don’t just look like dot-one-Q frames; they actually are dot-one-Q frames. And just like with the multi-VLAN axis port, the data VLAN is untagged. That’s the native VLAN on this trunk connection going into that switchboard. The voice VLAN will have tags that say, “In this case, this voice frame belongs to VLAN 400.” But for security reasons, we may want to go in and prune things off. In other words, deny access to the trunk for any unnecessary VLANs. We don’t want to take up extra bandwidth going over this trunk for traffic that has no need to be on this link. And we don’t want that PC on the data VLAN to go into promiscuous mode, where it can sniff the packets coming in from all VLANs. That could be a security issue.
So it’s a best practise to prune them off for performance and security. To get rid of any unneeded VLANs, we only want to have the voice and data VLANs on that trunk port. And that’s a look at three different ways that we could add an IP phone to our Ethernet network while trying to make some distinction between the data traffic coming from a PC plugged into that phone and the voice traffic itself. One option was to use OneP and have both the PC and the phone in the same VLAN. That might be necessary. If we have a third-party phone, we’re using a software-based IP phone, and one P is going to give us some QoS benefits, but we don’t get that VLAN separation. We do get VLAN separation with the multi-VLAN axisport, but it’s not going to be compatible with LDP. You’ve got to be using CDP. You get more flexibility with what we just talked about with the trunk port. Or you can use CDP or LDP for the switch to educate the IP phone as to its VLAN membership. But for security, as we just said, let’s get rid of any unneeded VLANs on that trunk by doing a VLAN. Pruning. Bye.
7. 7.6 Ethernet Port Flow Control
If we have a really, really busy network, it’s possible that one of our Ethernet switches might become congested with the flood of traffic coming in. If that happens, the switch can tell the sender to please stop for a moment and let me catch my breath. Switch. SW two. Can tell. Wait for SW one. It does. That is done by sending a pause frame. Now, this pause frame is going to tell the sender to stop, or, in other words, to pause transmission for a certain period of time due to congestion. This pause frame is also sent using a reserved special multicast address.
And this multicast address is not going to be forwarded by a switch. So when switch SW Two sends that pause frame over to switch SW One, SW One is not going to pass that onto any other switches, slowing down other links. It’s just between those two switches. When it says please pause for a certain amount of time, the unit of measurement for the time that SW One will pause is called a quantum, and it equals 512 bit times. Which begs the question: What is a bit of time? Well, we can calculate a bit of time by dividing one by the speed of the network interface card. So let’s say we’ve got a 1-gigabit per second network interface card. If we divide one by one million, we will get a bit time of one. Quantum has 512 of those bit times. If I tell SW One to pause for one, I’m saying pause for 512 nanoseconds, and we can tell it to pause a lot longer than that. We can tell it to pause over 600 bits if we want to. And this pause mechanism is referred to as “flow control.” It’s a way to control the flow of traffic.
And this was part of the 802-3 X standard published back in 1997, not to be confused with the 802-1 X standard used for security. This is something else. There is a caveat here, though, and the caveat is that we’re not paying attention to COS markings. Recall that a COS, or class of service marking, is a layer-two priority marking used for quality of service where we can give preferential treatment to different traffic types. For example, voice is often marked with a cosine value of five. Maybe we don’t want to pause traffic for five as long as we pause for one, which has a lower priority. However, under the original 802 three-fold standard, each coefficient is paused for the same amount of time. The good news is there is an update, and it’s called Priority Based Flow Control, or PFC for short. That’s part of the III 802-1 QB standard that was published back in 2010. And with priority-based flow control, you guessed it, every code value from zero to seven Each of those values gets assigned a different time to pause and a different amount of quanta that they’re going to wait before they begin transmitting again.
8. 7.7 Power over Ethernet (PoE)
In this video, we want to discuss power over Ethernet. And the Ethernet switch I have on my screen is labelled a POE, or a Power Over Ethernet switch. So let’s begin by giving power to this switch. Hopefully we have some sort of backup power for this switch. Assume it is linked to an uninterruptible power supply and is connected to the building’s electricity. But the switch can actually be manufactured with a larger power supply than would be required just to power all of those Ethernet connections. We could provide power to devices connecting to that switch. Think about a wireless access point as an example. You may want to install a wireless access point in the ceiling somewhere in your building. Well, there’s probably no electrical outlet nearby in that ceiling. So, how do you get power to this wireless access point? Well, a really elegant way of doing that is to do POE power over Ethernet. That means the power can flow over the Ethernet cable.
So it’s sending you data, and it’s sending you power. Another example of a device that could be powered by that protocol: perhaps we have IP phones. It’s common for them to use POE. It’s better than trying to have an external power supply plugged into that phone and having it plugged into the already overcrowded power strip underneath your desk. Let’s just power it using the Ethernet cable that it’s going to be connected to anyway. Video surveillance. That’s another option where we see it used quite a bit. And these are just a few examples. This is not comprehensive. The point I want you to understand is that we can have network devices that get their power from the Ethernet switch, which is going to make the installation of those devices a lot more flexible and a lot cleaner. And when you’re talking about POE, there are some terms I want you to know. A Power over Ethernet solution is made up of three basic components. The first one is called a PSE. That’s power source equipment. That’s the device that’s providing the power. In our example, it’s an Ethernet switch. The next component is a PD. That’s a powered device that would be something like an access point, an IP phone, or a video camera.
And then there is the connective tissue between the PSE and the PD. That’s the third component. That’s an Ethernet cable. And there are different PWE standards out there, and I’d like you to know the standards and the maximum amount of power each standard provides. When I first began working with Power over Ethernet, there was no standard. It was maybe in late 2000 or early 2001. And Cisco had its own proprietary power over Ethernet solution. And it was simply called “Cisco inline power.” And it provided 7.7 watts of power, which was enough to power the Cisco IP phones of the day. Later on, the IEEE standards body came out with some PoE standards. The first was 802 3 AF. And that provided exactly double the amount of power that Cisco inline power provided, seven watts, and I don’t think this is a coincidence. And the first IEEE standard was exactly double that at 15 watts. And over time, there was a need to provide more and more power. IEEE became yet another standard. 802.3 can deliver a maximum of 30 watts of power. At the time of this recording, the eight, two, three-phase batteries could provide up to 100 watts of power. And that’s a look at how we can have something like an Ethernet switch power some of the devices out there with which it connects.
9. 7.8 Introducing Spanning Tree Protocol (STP)
If you look at a tree in nature, you’ll notice that, on most trees anyway, the branches just go out and out and out. You don’t have one branch looping back into another branch.
And the structure of a tree is really what we want for our layer-two networks. Loops are undesirable in layer-two networks. The reason is that in a routed network where a router is forwarding packets, there is a time value inside the header of those IP packets. And every time it goes through a router, that router is going to decrement the time to live value by one. So if we get stuck in an infinite loop, it will go to zero and time out. However, Ethernet switches do not have the luxury of time to fill, so we do not want a layer in a topological loop. However, for redundancy, loops are great. That way, if one link breaks, we can have another link take over, so what we can do is use the spanning tree protocol, just like a tree. We want to have a logical topology for our layer-2 network.
That is just going to go out and out, and it’s never going to loop back on itself. And that’s going to give us the advantage of not having broadcast storms. As an example, when I used to work at Walt Disney World, you might remember if you’ve been there a long time ago that we had these little Key to the World cards, and this is how you got into the park. Well, we got a call that some of the people trying to get into the resorts were at the yard and beach club.
They weren’t able to check in. They couldn’t make these Key to the World cards. because there was a problem with the network. And this card—that’s how you got into your room. It’s how you paid for merchandise. It’s how you got into the park in the first place. So what was happening? Well, when we started to investigate, we found out that around the Epcot area, there was a loop in our spanning tree protocol. The spanning tree protocol had failed, and as a result, we had this big network outage. So I can attest to the fact that if you have a layer-two topological loop, it can bring your network down. So let’s talk about how the spanning tree protocol can help prevent those logical topological loops.
10. 7.9 STP Port States
In this video, we want to go through the different spanning-tree protocol port states. But before we do that, let’s understand what exactly is going on here. Let’s take a look at the backstory of the spanning tree protocol. It started back in the 1980s, before we even had Ethernet switches. Instead, we had what were known as “Ethernet bridges.” It’s an older device; we don’t see them in networks today, and they act logically like a switch. They learn which Mac addresses live off of which ports, and they make forwarding decisions based on those Mac addresses. However, they make those decisions in software rather than the dedicated hardware—the Asics, the application-specific integrated circuits—we have in today’s Ethernet switches. The bottom line is that they had much less port capacity and were a lot slower than today’s switches. However, they both have the same characteristic of needing redundancy but not tolerating aloof topology like we see on screen.
Well, coming to the rescue was Radio Perlman, who was working with Digital Equipment Corporation, or Deck, at the time. And she developed the spanning tree protocol. And for a while, the spanning tree flavour that she developed was actually referred to as the deck standard. And in 1990, the IEEE came out with its own standard. And the code was IE 802 1D. But I wanted to bring up the concept of a bridge because we still use that term. Now, today, we’re not going to have bridges in our network. We’ll have Ethernet switches that all operate logically the same way. They will make forwarding decisions based on Mac addresses, but they will do so in hardware. It’s going to be a lot more efficient. But we still refer to a lot of these port states as bridges. And the reason we say that switches are intolerant of loops comes down to the TTL, the time to live. Inside an IP packet there is a time to live field, and every time a packet goes through a router, that TTL value is decremented by one, and when it reaches zero, the packet times out.
So if we find ourselves in some sort of infinite loop, that packet is eventually going to time out. That is not the case. When it comes to Ethernet switching, however, there is no time to live value if you look at an Ethernet frame. So, if we have a loop like this, those packets will just circulate indefinitely, causing a broadcast storm and Macaddress Table corruption, where the same packet is seen on multiple ports of the same switch. It’s a bad thing. So we want to have a logically sound loop-free topology that looks like a tree, but basically we want to have redundant links. The only way to accomplish this is to block traffic on specific ports. And that’s really the purpose of this video—to define how those ports are determined. And we probably don’t want to let spanning trees just happen in our network. We probably want to influence which ports are going to be blocked and which switch is going to be acting as what’s called the root bridge, the central switch that everybody is pointing back to. As a real-life example, one time I interconnected three switches. One of them was a very high-end Cisco Catalyst 6500 Series switch. It was like the top switch of the day. And then it was sort of a mid-tier switch. and a really, really old 10-megabit per second switch. and the really, really old 10-megabit per second switch. It became the root bridge simply because of the way a spanning tree determines who is the root and who is blocking.
We want to go through in this video four questions and how to answer those questions when we’re analysing a spanning tree. So we can better make our selection as to who we want to be the root bridge. So the first question is, “Who is the root bridge?” And the root bridge is that switch that every other switch is pointing back to. Just like in nature, everything stems from the root. And we also want to determine who the root users are. Now, a root port is the port on a non-routebridge that is closest to the route in terms of cost. And we’ll see that the cost varies with link speed. We also want to identify the designated ports. And every single link has a designated port, even if we’re not carrying traffic over the link. To prevent that loop, one end is still active; it’s still designated, while the other end is blocking the blocking ports. Or sometimes we call those the “nondesignated ports.” Those are the ports that are left after we determine the route ports and the designated ports, assuming the port is administratively up and running. So let’s answer these questions one at a time. First up, who is the rootbridge? Well, the root bridge is the switch that has the lowest bid, the lowest bridge ID. And the bridge ID is made up of two parts: the bridge priority and the bridge ID.
And you’ll frequently see that set to 32 768, which is then followed by the Mac address. In this example, we have switches SW1, SW2, and SW3. They all have a priority of 32 768 by default. So we have to look at the Mac address as the tiebreaker to determine who has the lowest Mac address and therefore the lowest bridge ID. It looks like it switched to the SW one. In this very simple topology, it is our route bridge. Next up, we want to ask, “Who are the root ports?” And a root port is the one and only port on a non-route bridge that’s closest to the route in terms of cost. And for decades, costs have been calculated using a table like this. If we had a 10-meg link length, the cost would be $100. A 100-meg link cost 19 gigabytes for the price of four. A 10-gig link had a cost of $2. And in this case, we have giggles all over. And while this has worked fine for decades, today we’re starting to get into even higher link speeds. 40-gig links, even 400-gig links. How do we distinguish between those links? Well, instead of using this traditional method, we just use the “short path” cost method. Neural networks are going to start using the longpath cost method, and I actually think it’s a lot easier to determine the port cost with this method. All you do is take 20 terabytes per second and divide by the port speed.
So if you have a ten-gigabit port, you say, what is 20 terabytes divided by ten gigabits? and the answer is 20. But in this example, we’ll use the traditional short path cost method, and if we take a look at the link costs for switch two on gig zero one, it’s a cost of four to get up to switch one. And getting up to switch one on gigabit zero one costs $4 on switch three. However, there are other paths. What if switch two went to switch three and then up to switch one? It costs four dollars just to get to switch three. Then it’s another cost of four to go from a switch three up to a switch one, for a total cost of eight. Same thing for switch three; it could go to switch two for a cost of four and then up to switch one for another cost of four. And that’s going to give us a total of eight. So it’s very clear in this simple example that for switches SW 2 and SW 3, the root port is going to be that port that has a cost of 4 Gig 0/1 on each of these switches. Those ports are closest to the route in terms of cost. Now remember, a root port only exists on a non-route bridge. So the root bridge does not have any root ports. But we said that every segment—and we have three segments here—has a designated port, and the designated port is the port on the segment that’s closest to the route bridge in terms of cost. And something to notice is that on a link, you don’t get any closer to the route than being on the route. That means for the links connecting to the root bridge, the route bridge ports, those are the designated ports for those links.
So the only other link we have in this example is the link between SW 2 and SW 3. Who’s the reporter there? Well, to determine that, we put ourselves on each end of the link, and we say which end has the lowest cost to get up to the route. If I put myself on the SWT side of that link, it’s a cost of four to get to the root. If I put myself on the SW3 side of the link, it’s still a cost of four. It’s a tie. So what do we do? Well, we take a look at the end of the link that has the lowest bid. So, who is the first to have the lowest bridge ID between SW 2 and SW 3? We think about the priorities. These are a tie, so we have to go with the lowest Mac address, and that’s going to be SW, too. So the designated port on that bottom link is going to be the port on switch SW 2. Everything else is a blocked or non-designated port. And that’s a look at the four questions we want to ask as we’re analysing a spanning tree topology. And when we’re designing a network, we might not want to leave it at this default setting. Based on our traffic patterns, we may want to influence a specific switch to become the route bridge.
11. 7.10 STP Example
In this video, we want to get some practise analysing a spanning tree topology and determining who is the route bridge, what are the root ports, what are the designated ports, and which ports are blocking. And I wish I had been exposed to this. Prior to my interview at Walt Disney World, they asked me a very similar question that we’re going to be answering here, and they asked me which ports are blocking in this topology. Now, at the time, I thought I knew about spanning trees. I knew that it would prevent a layer-two topological loop by not sending traffic over certain links. But what I did not understand is that on those links that are not carrying traffic, both ends are not blocking. Only one end is blocked. The other end is still a designated port because every single link has a designated port. So I missed the question in the interview. Fortunately, I still got the job.
But I wish I had known what we’re about to go over right now. Question number one is: who is the root bridge? And we know it’s the switch with the lowest bid, the lowest bridge ID; that’s the priority first, followed by the Mac address as a tiebreaker. And it looks like switches A and B have lower priorities than switches C and D. A and B have 16 384 c priorities, while D has 32 768 priorities. So it’s going to be either switch A or switch B for the route. And since the priorities are tied, we look at the Mac address. Who has the lowest Mac address? Well, if we take a look at the first three hexadecimal digits of the Mac address, it looks like switcha’s zero is less than switchb’s one. And from that, we can conclude that switch A is the root bridge. Now we ask, “Who are the root ports?” And remember, there are no routeports on the route bridge. A route port is the one and only port on an off-route bridge that’s closest to the route in terms of cost. And we’re going to use the traditional short path cost method, where a ten-gig link has a cost of two and a gig link has a cost of four. Now switch B is connected to switch A over a 10-gigabit link. That’s what the tea refers to. It is port number ten. That’s a $2 link for a 10-gigabit connection. Is that the root port? Well, let’s figure out the cost of the other paths along the route, and we’ll pick the lowest one.
If I left gig 10 seven, it would cost four dollars to get to see, and another four dollars to get from C up to A via gig link. That’s a total cost of $8. Same thing if I go down to D; that will cost me four to go down to D, and then another four to go up to A, for a total of eight. Yes, it looks like tea. 10 for the price of 2. That’s the lowest cost to get back to the root bridge; switch A. So that will be our route port. What about switch D? It could go up to B, which is a cost of four over that gig link, and then over to A, which is a cost of two to go over the ten gig length. That’s four plus two for a total of six. Or, for $4, switchd can take a direct path right up to switcha via that gig link. Well, four is less than six. So we’ll say that the root port for switch D is gigabit port 10. What about Switch C? Well, it’s got three different ways that it might potentially get back to switch A. It could go to switch B for a cost of four and then over to switch A for another cost of two. Four plus two is going to be a total cost of six. Alternatively, we have gig 1010 and 10 one. They each connect directly to switch A. They each have a cost of four. So we’ve got a tie. What do we do in a case like this? Well, if we have a tie where we have two ports with equal costs to get back to the root bridge, ask who is at the other end of this link. And we’re going to use the link with the lowest bid. But in this case, both links go to switch A. It’s the same price on the far end of each link.
So we have another tie. What’s the tiebreaker now? And the reason I crossed the connections between the switches A and C and the topology is that I’ve had many students who have heard the rule that we select the lowest port ID as the tie, which is true, but many students misinterpret that and think it’s the lowest port ID on our local switch. Instead, we take a look at the other end of each link and say, “Which far-end port ID is the lowest?” If we look at the other end of the link coming out of gig 1010 on switchc, that goes into gig 10 four.Looking at the other end of the link coming out of switch CS, we can see gig one slash zero one port. That’s gig 10slash three, whose far end port ID is less 10 three, which comes out of gig 10 one on switch C.
So it’s a double tie breaker.On switch C, however, gig 10 becomes our root port. The next question is, who are the designated ports? And we have a designated port on every single segment, and it’s the end of that segment that’s closest to the route in terms of cost, and we don’t get closer to the route than being on the route. So we know that every segment connecting to the route has its own designated port on the route bridge itself. So all of the ports on the route bridge are designated ports for their segments. And we’ve only got a couple of segments left. We’ve got the segment between switches C and B and the segment between switches D and B. Now let’s take a look, first of all, at that segment between switches C and B. If I’m on the switch C side of that segment, my cost is $4 to go up to switch A over that gig link. If I’m on the switch B side of that, my cost is only two.
So which end of this link is closest to the root? That’s the switchboard side. So we’re going to say for that segment, the designated port is SwitchBig 10 seven.Let’s take a look at the link between switches B and D. If I’m on the switch B side of that link, it only costs two dollars to hop over that ten-gig link to switch A. However, if I’m on the switch D side, it costs four dollars to take that gig link up to switch A. So which end of this link has the lowest cost? The switch is located at the B end. So we’re going to say that for that link between switches B and D, the gigabit five-port on switch B is our designated port. And assuming the ports are all administratively up, all of the remaining ports are going to be blocked, or sometimes we might refer to those as “nondesignated ports.” This is going to give us the loop freetopology that we see highlighted here in blue. That is the job of the spanning tree protocol, which creates this loop-free topology while still allowing for some backup links. So if any of these links that we see in blue were to fail, we’ve got a backup path.
12. 7.11 STP Convergence Times
We know that the spanning tree protocol allows us to have physically redundant links while logically having a loop-free topology. And that’s what we have here. That is evident on Switchboard 3. Interface Gig 2 is currently blocked. We do not have user traffic over that bottom link. And switch three and switch two are both pointing up to switch one. Because switch one is our route bridge, switch three connects to it via interface gig zero one. However, let’s imagine that there was a failure on that link between switch one and switch three.
After all, that’s what the spanning tree is built for—to help us recover from something like that. The question we’re going to answer in this video is: how long does it take to recover? Do we immediately start forwarding traffic out of gigabit-zero-two? Actually, no. We’re going to remain in that blocking state for 20 seconds. Switchboard three is waiting for bridge protocol data units (Bpdus) to be received from switch one. If it does not see any Bpdus within 20 seconds, it realises something must have happened to the topology, and it’s going to start transitioning its blocking port into a forwarding state. But it does not do it immediately. It next transitions from blocking to listening in the listening state. It is listening for Bpdus on any other interfaces it may have. Right now it only has one other interface, but it’s taking a look at the Bpdus being advertised around the network and trying to determine which of its ports will become its new route port. And who knows, maybe it’s now the root bridge, if the root bridge has been destroyed.
So it examines those BPDs for 15 seconds, but we’re still not forwarding user traffic. We then transition from the listening state into the learning state, where we stay for 15 seconds. We are learning Mac addresses. We’re starting to populate our Mac address table with traffic seen on our different interfaces. However, we are still unable to forward traffic on gigabit zero two. We haven’t transitioned to the forwarding state yet. But after a total of 50 seconds—20 seconds spent blocking, 15 seconds spent listening, and an additional 15 seconds spent learning—we finally transition to the forwarding state, and the previously blocked port becomes our new route port. And the previous route port is going to be blocked again; that was a total of 50 seconds of delay. And this is using the standard Spanish tree protocol. But be aware that there is another version called the “rapid spanning tree protocol.” And depending on the situation, it may be possible to recover from a network failure in as little as one or two seconds. It’s very, very rapid. But traditionally, I want you to know the block listening states that add up to 50 seconds of delay.
13. 7.12 STP Variants
In this video, we want to consider some of the different flavours of spanning tree protocol, going all the way back to the beginning. At deck with Radio Perlman, she developed what was known as the deck standard, and that was called a CSC, a common spanning tree. In fact, when the IAAA came out outside the standards-based version of 802.1D, that was also considered to be a common spanning tree. And what that means is that even if we have multiple VLANs configured on these switches and trunks between the switches, every VLAN is still going to be using the same instance of a spanning tree. In other words, for VLAN 100, 200, and 300, all of the different VLANs are going to be looking at the same switch as the root bridge.
They’re going to have the same forwarding and blocking ports on the various switches. And later, Cisco came along and said, “Okay, let’s see if we can improve on that just a bit because we realize different VLANs by their nature have different traffic patterns.” Maybe for one VLAN, it would be better for switches to be the route. Maybe for another VLAN, SW-2 could be the route. Maybe another VLAN would benefit from having SW3 as the route. It is not always possible to have a one-size-fits-all spanning tree. So Cisco developed the PVST approach, the pervlin-spanning tree. And as the name suggests, each VLAN is going to have its own instance of a spanning tree. So for example, let’s say VLAN 100 uses switch SW1 as its root; another VLAN could use a different switch. And in the literature, you may see this written a couple of different ways.
You may see it written as PVST or PVST plus. It’s typically fine to use those terms interchangeably, but I wanted to make sure you knew the difference. If you see a plus sign after PVST, that means the trunks interconnecting these switches are using the Q trunk encapsulation type, as opposed to Cisco’s ISL, which is a link-proprietary trunk encapsulation type. But typically, we just use those terms interchangeably. Now back to another standard approach to a spanning tree protocol: MSTP, or multiple spanning tree protocol. You may also see that written as just mist for multiple spanning tree protocol, and it is a standard; it’s II 802 1S.
And what the IE did was notice what Cisco noticed, which is that not every VLAN would benefit from having the same switch as the root bridge. Perhaps, but they came up with a different approach. Instead of giving every single VLAN its own instance of a spanning tree, this “triple standard” observes that while we may have several VLANs that would benefit from the same switch being the route, for example, let’s say that in this basic topology, switch A would be the optimal route bridge for VLANs one, two, three, and four. However, switch B would be the best route bridge for VLANs 5, 6, 7, and 8. So what we can do is, instead of having eight different instances of the spanning tree running as we would with PVST and PBST, we can have just two instances.
We can define an instance where switch A is the root, and we can assign VLANs to that instance that would benefit from having switch A as the root. We set up a second instance with switch B as the route, and then we assigned those VLANs that would benefit from switch B being the root. However, so far, all of these different options we’ve talked about still have the same default convergence time. If a link fails in this redundant physical loop, it takes about 50 seconds to start using an alternate path, and that can be a long time. Fortunately, there is another standards-based approach that can speed things up, and that’s called RST, or rapid spanning tree protocol. And when I say it’s going to speed things up quicker than 50 seconds, I’m talking on the order of a few milliseconds to typically a maximum of about 6 seconds, which, by the way, is three times the default hello time of 2 seconds. That’s where we get the six and a few milliseconds. That can happen if a direct link fails because, with the rapid spanning tree protocol, all of the switches on the topology can participate in the conversions, educate one another, and detect when something goes wrong and send out a message called a TCN, or a typology change notification.
And that can really speed things up when it comes to conversions. And I mentioned that this is a standard. Specifically, it’s III 802, one W. Oh, by the way, we talked about Cisco’s approach to PVST and PBST. Plus, they also came out with a variant of the Rapid Spanish Three Protocol, which they call Rapid PVST or Rapid PBST. Plus, they’re simply using their per-VLAN spanning tree approach, but they’re overlaying that with this RSTP standard. And to better understand a rapid spanning tree protocol, we need to define some terms. First, let’s consider some different roles that our ports may have. And the good news is, once we understand the port roles of a PVST topology as an example, then we’ll understand this pretty well. We still have the concept of a root bridge, which is the switch with the lowest bridge ID, which is made up of the bridge priority followed by the Mac address. We still have the concept of root ports. Remember, we have a route port and only one route port on every non-route bridge. So the root bridge has zero route ports, and that route port on the non-route bridge is the port on that bridge or switch that’s closest to the route.
In terms of cost, we still have the concept of “designated ports.” Remember that every segment has a designated port. And you might wonder, hold on, what about that other link from switch three up to the hub, that shared media hub? That entire path from the switch up to the hub back down the other path—that’s one segment. So we do not have a designated port on that other link because it’s part of the same segment. We also have ports that are administratively shut down or disabled. Where it gets a little bit different, though, is when we have blocked ports. There are two types of blocking ports in the rapid spanning tree protocol.
One is an alternate port that we would have on a switch. We’ve got a full duplex point-to-point connection between switch two and switch three. And if we’re blocking thanks to Spanish-3 protocol decisions, then that’s going to be known as an alternate port. Another type of blocking port we might see, hopefully not, but on an Ethernet hub. Hopefully we do not have these in our network, but if we did and we had this loop up to the hub and back, obviously that’s a layer to loop. So we’re going to have one port blocked. But if we’re going through a shared media hub, instead of calling it an alternate port, we call it a backup port. Also, the different port states differ a bit with RSTP. We still have a situation where we’re throwing packets away.
And by that, I do not mean BPDUS bridge protocol data units. We’re still processing those. But we’re discarding user traffic if we’re in the discarding state, similar to the blocking state with previous versions of the spanning tree protocol. We do not have a listening state, but we do have a learning state where we’re starting to populate our Mac address table. We’re still not forwarding user data yet, but then we’ll transition to forwarding. And, once again, unless we change the default hello timer to something else, this will usually be a maximum of about 6 seconds. And I also want you to know some of the different names for link types. We have point-to-point links that go between switches because each link only has one device on each end of that link. So we call it “point to point.” And you might wonder why I did not label the laptop connection into the switch as a point-to-point connection because it is a point-to-point connection, but it’s a special type. It’s called an edge port. Now an edge port is where we’re connecting an end-user device. In other words, no switch, no device capable of sending BPDUS or bridge protocol data units in the network. It could not cause a loop, in other words. And as a result, we don’t want to have to wait through the spanning tree timers in order for that port to go active.
So we’re going to enable it as an edge port. Cisco uses the term “port-forwarding.” That’s their term for a port that’s going to go active almost immediately because we have given our solemn vow to that switchboard that we will not connect it to a switch or anything that’s going to send it a Bpdu. So, despite the fact that it is a point-to-point link, we refer to it as the link between the laptop and the switch. It’s an edge port on a point-to-point link. Now, what about that shared media hub? Again, I hope we don’t have these in our modern network, but if we did, that would be called a shared link. And you might be wondering how the switch knows we’re connected to another switch rather than a hub through this port. Well, it makes the assumption that if it’s a full-duplex port, in other words, we can transmit and receive simultaneously. It makes the assumption that it’s a point-to-point link going to another switch. Because we cannot run in full duplex with an Ethernet hub, we have to run in half duplex, where we can send or receive at any one time, but not both at the same time. And that means if the switch sees a port set to half-duplex, it’s going to make the assumption that that is a shared link connecting out to an Ethernet hub. Now, I mentioned earlier that the switches using the rapid spanning tree protocol participate in the convergence. To speed things up, let’s zoom in on just a couple of switches that might be in a much larger topology. And let me give you an idea of how that works. Let’s say that we’ve got a large topology with lots of switches, and we’re focused on just a couple of switches here. And in this topology, it’s so big that we don’t even see the root bridge.
But it was at the very bottom of your screen. But something happened, and it went down. And now the elected route bridge is at the top of the screen. Well, switching to one’s top port, which was a designated port, one realises that I just received a Bpdu, proving to me that the route bridge lives somewhere up this way. So I should not be a designated port; I should be a root port. And we make that transition in step one, from a designated port to a root port. The problem is, the bottom port on SW 1 is currently a root port, and we don’t want to cause any sort of temporary loop during this time of convergence. So we’re going to temporarily set that bottom port to blocking. Now, while we’re blocking, and remember, when I say blocking, we’re not blocking BPD, we’re blocking user data. We’re going to send a proposal down to our neighbors, which are on the south side, and that proposal says, “Hey, I propose that you come to me to get to the root bridge.”
And as proof that you should come to me, check this out. Here’s a Bpdu showing that the elected rootbridge lives at the top of the screen. You need to come through me to get there, and switch two looks at that proposal and says, “You convince me I should not be a designated port on top, I should be a root port.” So it’s going to change from a designated port into a root port. That’s step four. And then in step five, we let switchboard know that, okay, we’re convinced we have transitioned our end of the link to a root port. In other words, we send an agreement. And once the switch is flipped, one can tell that the other end of this link has changed. It knows that the coast is clear for it to transition in step six from the blocking state to being a designated port on that segment, remembering that every segment has a designated port, and it’s the port on that segment that’s closest to the route in terms of cost. And this is the way that Switch One educated Switch Two about this change. And that would happen very, very rapidly, by the way.
And then the process would continue. Switch two would take its bottom route port, go into a blocking state, send a proposal to its neighbour, and the process would happen over again. So that’s a look at some of the different variants of the spanning tree protocol. We had the original deck version pioneered by Radio Perlman back in the 1980s, and then in 1990, I tripled the standard to 802 1D. We took a look at the subtle difference between a couple of Cisco variants, PBST and PBST, plus the plus signifying that the switches are interconnected with trunk links and that the trunk encapsulation type is IEEE 802 One.We took a look at the MST, or MSTP, as some literature calls it, for multiple spanning tree protocol, where we define different instances of spanning trees, where we have a route selected for each instance, and then we just populate each instance with appropriate VLANs. And then finally, we took a look at the asynchronous spanning tree protocol that can speed up that 52nd conversion time to just a few milliseconds, with a maximum of about 6 seconds.
14. 7.13 Link Aggregation
If I want to interconnect these two Ethernet switches, like we see on screen, I could do so with a single link. However, that might be a bottleneck, so I might want to add a second link. However, with a spanning tree protocol, Spanning Tree will say, “I’m only going to allow user traffic over one of those links to prevent the formation of a loop and the resulting broadcast storm.” But wouldn’t it be great if instead of just standing by and waiting for the other link to fail, we could actively be using both links? That’s what we can do with a technology called link aggregation, or LAG. We can logically bundle together multiple physical links into a single logical link. And you often see that on a topology drawing with an oval around those links, indicating that they are logically bundled together. Sometimes that bundle is referred to as an “ether channel.”
And with this Ether Channel connection, we can simultaneously send traffic between both switches using both links. That’s going to give us more bandwidth between the switches. If I have a couple of gigabit links logically connecting my switches, I suddenly have a two gigabit link between those switches, despite the fact that I’m only showing you two links here. and this could vary based on your switch hardware. But we could have an Ether Channel bundle containing two links, four links, or a maximum of eight links. And this will provide us with load balancing across all of those links. And it also gives us redundancy. With a spanning tree, we would have one of these two links standing by, waiting for the other to fail. But this gives us some redundancy as well. If we were to have one of these two links go down, the other link would still continue to function. If I had a bundle with eight links and one or two failed, the remaining links would continue to function. So it does give us redundancy. And when we’re setting this up, we could just say, “I want to turn on link aggregation,” or we could configure just one switch to negotiate the formation of an Ethernet channel using a protocol such as PAGP.
That’s the port aggregation protocol. That’s a Cisco proprietary protocol that negotiates an Ether Channel formation. There is an industry standard called LACP, the Link Aggregation Control Protocol, and they work similarly. Let’s take a look at the logic of how they can negotiate the formation of a channel. First, with Pag P, I mentioned that we could just set both sides to “on,” where we’re not sending PAGP frames but just “on.” But if we want to use a Pag-P, we could set our mode to “auto” or “desirable with auto,” and we’re willing to become an Ether Channel port, but only if the other side invites us into an Ether Channel. I need to receive a Pag-P frame; I’m not going to initiate it myself. So think about the fact that if both sides of this Ether Channel have ports set to auto, it’s not going to work. Because even though both sides are willing to form an Ethereum channel, nobody is suggesting that they do it. So we don’t bring one up. If both sides are desirable, a channel will be brought up because a desirable side is going to initiate the formation of a channel by sending Pag-P frames. And if the other side is set to desirable, it’ll say, “Sure, let’s do it.” Let’s bring up an Ether channel.
Or if the other side is auto, or receives those PAGP frames from the desirable side, and the auto side says, “Yes, I was waiting for somebody to ask, let’s definitely form an Ether Channel.” So these are the different combinations and permutations of how PAGP can negotiate the formation of a channel. But I mentioned that there was an industry standard as well, and that was LACP, the Link Aggregation Control Protocol. Logically, it works the same, except the names are different. Instead of auto, we have passive, and instead of desirable, we have active. But as you’ll see with the checks and Xs onscreen, the logic remains the same. So is there an advantage to one lag protocol versus another? Well, there might be. And again, this can vary based on your switch model. But LACP supports having more than eight ports in a channel. You can identify eight additional ports that can fill in the gaps if we start to have individual links fail within that eight-port channel. So we can have eight backup links if we want. Suddenly, we’re dedicating a lot of switch ports to an Ether Channel. I’m not sure we always want to do that, but we do have that option with LACP.
We do. not with PAGP. And we said we’re going to load balance across this Ether Channel, and a lot of people have a false sense of security about how that works. Let me explain. And again, this is going to vary based on your switch model. But let’s say that we’ve got some servers hanging off of Switch B, and we’ve got this PC that’s going to be sending traffic over to those different servers. In fact, let’s imagine we have lots of PCs off Switch A sending traffic to the servers. And I’ve got four links in this Ether Channel bundle. And many people would guess that we’re going to load balance based on this. We’ll send the first packet over the top link, we’ll send the next packet over the next link, the next packet over the third link, and the next packet over the fourth link, and then we’ll just start over again. That’s not the way it works. There are load-balancing algorithms that you need to be aware of. Load balancing is based on the destination’s Mac address in many switches I’ve worked on.
Now, here’s what I mean. If I have four links, how many binary bits does it take to represent four different possibilities? Two bits—I could have two bits—will give us a unique identifier for one of these four links. So if I’m paying attention to destination Mac addresses, which again are the default on minis, which is what I’ve worked on, we’re going to be looking at the last two bits of the destination’s Mac address, which is 48 bits long. And we normally write a Mac address as a hexadecimal number, and I didn’t write off the full Mac address for these three servers. But I’m showing you here the last hexadecimal digit for these three different servers, and they all look different. But if we break those hex digits down into binary, remember, four binary bits go into one hex digit. That gives us 16 different combinations. If I look at 1 and 5 and D in binary, the two numbers to the right, most digits are the same. They all lead to the same place. That means instead of load balancing by taking turns on the links I use to get over to the servers, that link identified with 0/1 is going to be used for all of the traffic going to all three of those servers. As a result, we’re not performing the load balancing that we might have expected. What can you do? We’ll see what other load balancing algorithms are available on your switch platform.
Now, you can typically look at source or destination, IP addressing, or Mac addressing. What I like to do is combine both source and destination. I think that adds an element of randomness to this. So I might say something like “source,” “destination,” and “Mac.” I want that to be my load-balancing algorithm. And that’s what I’m considering in this case, not just the last two binary bits of the server’s Mac address but the last two binary bits of the PC’s Mac address. And what’s going to happen with those last two bits from the PC and the last two bits from the server? We’re going to perform an exclusive OR operation on each bit. That’s a boolean operation. An exclusiveor says if we’re comparing two digits and they’re the same, the result is zero. If we compare two digits and they differ, it means they are exclusively something else, exclusive. Or if they’re different, we get a binary one. So if the last digit in my PC’s Mac address happened to be a one and the last digit in the server’s Mac address happened to be a zero, that would give me an exclusive result of one. A one and a zero are different. If both were one, that’s a zero. If both were zero, that would also result in a zero. We get a zero when the two bits match. We only get one when they’re different. But by doing that, we’re adding some randomness to the selection of the link that we’re using. And that’s a look at link aggregation, also commonly referred to as an “ether channel.”
15. 7.14 Port Mirroring
If we want to troubleshoot a network connectivity problem, it is possible that the server is not successfully communicating with the client. A great way to approach that troubleshooting issue is to capture packets going between the client and the server so we can analyse those packets. Take a look at what’s going on in the layer two header and in the layer three header. But the challenge is that a switch has learned the ports off of which these devices live. It’s learned their Mac addresses, in other words. So when the server is sending a frame to the client, it’s only going to go through the port connected to the client. How can I connect a laptop running some sort of sniffing software and get a copy so that I can analyse that? And by the way, when I say sniffing software, there’s a great free piece of software you might want to download. It’s called Wireshark, and you can get it from Wireshark.org. It is a fantastic troubleshooting utility, and I might be running that on this sniffer laptop. But how do I get a copy? Well, some of your Ethernet switches will support a port mirroring feature.
With port mirroring, we can identify a port and say we want copies of frames coming into that port, going out of that port, or both. Or we could say all frames in a particular VLAN. We can make copies of all those and send them out the port connected to our sniffer laptop by configuring that port as the destination for our port mirroring configuration. Then, when the server is sending a frame to the client, the switch is going to make a copy and also send it down to the sniffer. But a word of caution: you don’t want to leave a port in this state because somebody may come along later and plug a PC into that empty port. They think, “Well, we need to install a new PC.” Here’s an empty port; let’s use that. And suddenly, that PC, whether the user realises it or not, is receiving copies of frames that it should not be receiving. So you want to be very diligent about unconfiguring that port for port mirroring when you’re done. Or another option is to just designate a port on your switch, such as the very first port or the very last port, and just know that that’s reserved. You’re not going to connect any end-user station, server, or other network appliance to that port. That port is going to be reserved just for sniffing applications. So that’s another approach. But it would be better for security if you simply unconfigured your port mirror configuration when you were done.
16. 7.15 Distributed Switching
If we have a network that contains multiple Ethernet switches, there are some design options that we’re going to consider in this video for how we distribute the switching across our network. What we see on screen is the very common three-tier architecture where we have our network divided into the access layer, the distribution layer, sometimes called the building distribution layer, and the core layer. Let’s talk about each one. The access layer is something that I often refer to as the “wiring closet layer,” because this is where maybe you have your Ethernet switches that connect out to your end devices. You might have switches on each floor of a building. Each of those wiring closets, those switches there, would be at the access layer. And then maybe, within a building, there’s an aggregation point for all of those access layer switches. They can all be traced back to a set of distribution layer switches. And notice it’s not just a single switch. At the building distribution layer, we’ve got a couple of switches for redundancy, and those distribution layer switches connect to each of the axis layer switches. So we could actually lose a single link or even a distribution layer switch, and everybody would still be able to get to any destination that they wanted.
And if we have a larger campus environment with multiple buildings, we need to connect those multiple buildings. and that can be done at the core layer. The core layer is concerned with speed. It wants to get traffic as quickly as possible from perhaps one building distribution layer switch to another building distribution layer switch. Maybe this is the layer that we use to get out to the Internet. Although some designs use the building distribution layer to get out to the Internet, there’s no hard and fast rule about that. But this is a very common three-tier architecture you often see for enterprise networks. And as a side note, let’s take a look at the different types of network topologies that we have here. We can see PCs staring out from access layer switches, indicating that they are in stations. This is a starred topology. But if you take a look at all of those redundant connections between the core and the distribution layers, that looks like a partial mesh topology. And what do we call a network that contains multiple topologies? We call that a hybrid topology. And here we have a hybrid of some partial meshes and some star topologies. And while this design might be great for a large campus environment with multiple buildings, sometimes we just don’t need three layers. We might only have one or two buildings.
Do we really need a core layer? Perhaps not. Maybe we could combine the core layer and the distribution layer and have those multilayer switches, as we see here, connected up to our axis layer switches. That kind of design is called a collapsed core. We’re literally collapsing our core and distribution layers into a single layer. And this might be more appropriate for a smaller installation where we don’t have lots and lots of buildings. And while the collapsed core and the three-tier design are common in enterprise networks, there’s another design that we might see in data centers. Let’s check out the spine-leaf design or some literature. We’ll call it the leaf spine design. But in a data center, we’ve got these big racks of servers, typically. And the servers—we’re going to call them nodes—are going to connect redundantly into these leaf switches, which live in a rack full of equipment. In fact, they might be located at the top of the rack. They’re also known as Tor switches or top-of-rack switches. So imagine we’ve got one rack, and we’ve got these top-of-rack switches interconnecting all the servers in that rack. We’ve got another rack with other switches interconnecting the servers in that rack. How do we get from one rack of servers to another rack of servers? Well, that connection is going to be made not through leaf switches but through spine switches. Spine switches have a full mesh of connectivity out to our leaf switches.
This is going to give us a very predictable delay. Because if I want to go from any leaf switch to any other leaf switch, I know that I have to hop through one and only one spine switch. And this two-layered design is common in data centers. And if you think about the design as a whole, where we’ve got leaf switches connecting out to our servers, and then the spine switches are interconnecting our leaf switches, this is logically sort of like a switch. I mean, think about the ports on all of those leaf switches. Those would be analogous to the ports on the really big Ethernet switch connecting it to our servers. And in an Ethernet switch, what gets us from one port to another port is the back plane of the switch. So we could think of the spine switches as acting like the backplane, and the leaf switches as acting like the ports connecting out to the servers. That’s a look at a few different approaches to switch distribution in our network. We looked at three designs in the enterprise where there could be multiple buildings. We could have a three-tiered design: the access layer in the wiring closet, the distribution layer in a building aggregating those access layer switches, and the core layer that aggregates the building distribution layer switches. And again, in a data center, we might have leaf switches connecting out to our servers, and they can be interconnected with spine switches.
