ICND2 200-105

ICND2 200-105

Issues in Redundant Topologies

Redundancy is great. What does it provide us? It provides us with alternative paths when our primary path fails. But in our layer 2 topology, we need an outside protocol to allow us to have this redundant topology. There is no mechanism built into the layer 2 frame that will ensure that a loop doesn't occur. What do we mean by a loop? Focus on the topology here.

Redundant Network with Loop

Notice, how if a frame enters the topology, it could propagate to the switches, the other switches. But if it is a broadcast frame, when it gets propagated, what will happen with the broadcast frame when the other switches receive it? It will come in on one port and go out the rest. And we taught you this earlier with a phrase that stated, switches flood frames to all ports except the port that they received that frame on. If we don't know where the Media Access Control, or MAC, address is for the destination, and since the destination of the broadcast is always going to be unknown, well, it is going to flood. So a port comes in or a frame comes into a port and it fans out to all of the other ports that are members of that virtual LAN, or VLAN, okay, which would also be trunk links, which are members of all VLANs by default.

So as I mentioned, there is no mechanism in a layer 2 frame to stop this. So the flooding just continues on and on and on, and this results in problems such as a broadcast storm. What's a broadcast storm? It is when we have injected broadcasts, which never die into a layer 2 space. Those broadcasts don't die, and therefore they flow endlessly around to all of the space in which that VLAN lives. And so, we've just jam-packed those links with a broadcast that doesn't die and, you know, the broadcasts overwhelm us.

So while these broadcasts are storming around our topology, there are going to be multiple copies of the exact same frame. And devices on the network that are receiving these frames are going to have to process them. And that could be a problem, because not every application has the ability to handle the same frame twice. Intrusion prevention systems might classify that as malicious traffic when it's not. We have a different problem on our hand here. So multiple frame copy is bad and then this broadcast storm, which keeps propagating all these frames will keep changing the MAC address table. Now why would that happen? How does a switch learn about MAC addresses?

The switch will learn about MAC addresses by pairing up the source MAC address with the interface that the switch received it on. But the challenge is when a broadcast goes into one of these switches, it fans out. Now we have two copies that are going, kind of, in concentric switching loops. They have the same source, right? So at certain points, comes in on one port, goes in on another port, it's the same source so we wind up having this CAM table instability. CAM table or MAC address table, whatever you want to call it, CAM for content addressable memory. It's because we're constantly reassociating that MAC address with different ports. This can easily crash a switch.

Let's stop this mess and let's implement Spanning-Tree Protocol. Well wait a second, do we have to implement Spanning-Tree Protocol or is it running by default?

Spanning-Tree Protocol

It's running by default and, you know, I've seen a lot of discussions about Spanning-Tree Protocol, some people have said to turn it off. It's not the current mindset of most in the industry. We would want to run at least a version of Spanning-Tree Protocol and optimize Spanning-Tree Protocol. But on our Catalyst switches, we run the least optimized version of this technology. It's the Institute of Electrical and Electronics Engineers', or IEEE's, first attempt at spanning tree, which is 802.1D, and this is classic. It tends to adjust to changes in the topology very slowly, and so we're going to see that there are some other versions that are far superior. But nevertheless, this is what runs by default and it gets the job done.

So the overall goal as we see here is to place certain ports in a blocking state. Spanning tree needs a language to communicate. This language is known as BPDUs, Bridge Protocol Data Units. They are exchanged between our layer 2 switches every two seconds, and we use these BPDUs to determine the spanning-tree topology as well as the state. And if something goes wrong, then we can reconverge, we can find a new path. So if all of a sudden the link between our switch on the left and the top fails, that link goes away. Well we will no longer be blocking the bottom link and we can take that path instead. So Spanning-Tree Protocol, allowing us to have redundancy within our topology while avoiding the switching loops.