Hello! And welcome to Enterprise LAN Design.
This post in the series will cover the technologies used in a single LAN and some physical media characteristics. This includes spanning tree, switch virtualization technologies, and first hop redundancy protocols.
We’ll be covering a lot of technical detail here so I recommend you take notes and certainly watch the video a few times if you need. This one is going to be big, just bare with me and perhaps pause the video as needed to copy down some of the information in the tables. So without further ado, let’s dive right in.
I know a lot of network engineers that have either rarely or never worked out in the field. Because of this, they never give the physical cabling and media used a second thought. It’s just an item on the CLI that shows it’s connected or not. So if you’re one of those people, there’s a couple items you’ll want to take note of here.
I’ve only shown gigabit standards here. That’s the 1000BASE standard, here we have 2 copper cables and 2 fiber optic. If you’ve been around fiber optic cables at all, you may have heard talk of single mode and multi-mode fiber. What this really means is what wavelengths of light the fiber optic cable supports. Mind this table is not nearly complete with all technical information on the media standards; this isn’t included in the exam topics for the 200-310 exam, but I wanted to go over it briefly anyway as I feel it’s important to be aware of some of the basics.
Your standard unshielded twisted pair ethernet cable is over here and has a maximum run length of 100 meters. After 100 meters you might get speed and duplex negotiation problems, packet drops and collisions, or a total lack of connectivity depending how long you go. So when you’re creating your LAN design, if you think a cable run might be coming up close to that 100 meter mark, do your homework and check. You can put a switch in the middle to repeat the signal, or you can do a fiber run to the wiring closet to make sure your connection works as expected. Coaxial isn’t really used much except in industrial environments where you need shielding and fiber isn’t an option. As you can see though, fiber cables can stretch an incredible distance without the need to boost or amplify the signal, so that’s why you see ISPs using fiber, not just for their speed capabilities but also for the distances they can run.
So, within your LAN, regardless if you have Layer 3 down to the access or not, you should have spanning tree enabled to prevent any possible layer 2 loops in your network anyway. Most people don’t have layer 3 to the access and will run spanning tree between their access and distribution layers as well. At that point, there’s a big difference in features and convergence time depending on the flavor of spanning tree protocol you’re running.
First was the original spanning tree protocol, good ol’
802.1D. So this is an industry standard protocol, and mind you it was originally published back in 1990, a time when a 30-50sec outage in the event of a reconvergence was acceptable. So you should all have your CCNA already and be quite familiar with spanning tree, but just in case you’re not, let’s do a very brief overview. So the purpose of spanning tree protocol is to prevent layer 2 loops from forming. We need to do this because of a switch’s very handy feature that it will forward a broadcast frame out every interface except the one it came in on. In the topology we have here, if a broadcast came in, it would be forwarded out both links, then the next switch receives and forwards out all links and then the next, so on and so forth, hundreds of thousands times per second, bringing each device in your network to its knees.
So how do we prevent this? We block one of the links in the loop to break the loop. Spanning tree does this with a mechanism a bit like sonar. It sends BPDUs, bridge protocol data units, our all of its interfaces participating in spanning tree and also listens for them. It listens for a BPDU from a switch with the most superior bridge ID and then declares that switch to be the root bridge of the network. Then any redundant pathways it has to the root bridge will be blocked, leaving only the lowest cost path to forward traffic and prevent loops. I mean you can sortof feel that this is made for a hierarchical network design. When a link goes down or it stops receiving BPDUs then there’s a reconvergence to either elect a new root or find a new best path to the root. The only problem is, it’s slow, at least nowadays, but back then in 1990 this new feature absolutely saved your bacon.
At the time this was released, Cisco realized that incorporating spanning tree protocol was a good idea and so they did but they tweaked it a bit. They decided that they would run a separate spanning tree instance for each VLAN on the switch, in per-vlan spanning tree. This would selectively block a particular VLAN from sending traffic over a trunk link and allowed for a certain form of load balancing, right? I mean having an entire redundant link blocked is a bit wasteful since
it’ll never be used unless the primary goes down. So you could set this switch to be the root for VLAN 1 and this switch the root for VLAN 2 and get a bit of load balancing going on there so you can actually use all of your links.
In 2001 IEEE released 802.1w, rapid spanning tree protocol. This lowered the convergence time from 30-50 sec to 6-10 sec. big improvement, right? Still not exactly the ninja fast reflex of a routing protocol but still much more palatable. Of course Cisco also updated their own standard to be rapid per-vlan spanning tree. Same deal here, it’s just rapid spanning tree but runs a separate instance per vlan.
The industry’s response to Cisco’s idea is multiple spanning tree, 802.1s. This works a bit different than per-vlan spanning tree. You create a group and assign vlans to it so you have a separate spanning tree instance only for each group rather than each vlan. This can be helpful if you have a ton, and I mean a really huge number here like 1000+, vlans, to where running a separate spanning tree instance for each vlan isn’t feasible due to the CPU resources it would take, but the setup is pretty complicated and prone to configuration errors. In fact, it’s so much so, that Cisco does recommend that as long as you’re able to, you should run RPVST to avoid the complexity and prevent configuration errors.
So, before I go to this next slide, I want to warn you it’s a little bit of a busy slide, but if you hang with me we’ll get through it together 😊
Cisco references these features as the spanning tree toolkit. They are features that in some way augment the functionality of spanning tree protocol to either enhance its performance under certain circumstances or to enhance its stability. As CCDA you don’t need to be intimately familiar with the operation of these features, but you should at least know where to use them, as directed by the diagram on the right. We’re just going to do a super brief flyby of these.