A CCNA Lab Followed by a CCNA/CCNP Spanning Tree Challenge
Those who had an opinion last week were split evenly: CCNA labs need either 2 or 3 switches, and CCNP labs need either 3 or 4. But why? We saw a few opinions floating around the blog last week, but this week I’m going to take it a step further. Today I’ll offer a pretty comprehensive CCNA-level lab that gives us a backdrop to then discuss Spanning Tree Protocol (STP) in a 2-switch topology. STP is one of the big motivations for adding more switches to a lab, so we’ll have a specific example to discuss why the 2-switch topo would do the trick, and where we’d really want another switch or two.
Sure, we could stop right now, and just say that everyone should buy 3 switches for CCNA, and 4 for CCNP practice. But what if a 3rd switch just isn’t in the budget? Well, this thread of blog posts will hopefully reveal some ways to challenge yourself with STP practice even with that pair of switches.
So here’s the big picture. I’ll describe a topology and some design. Then, if you want the practice, you can go look at an informal lab exercise that covers only CCNA-level configuration – but configuration that uses only default Spanning Tree Protocol (STP) settings. Then, for those of you interested in STP, I’ll pose this question: how many ways can you think of to configure the two switches to achieve a particular flow of packets between two devices? And how many of those use CCNA-level commands, and how many require CCNP-level commands?
Here’s the topology for both a baseline lab and for the STP challenge. It uses 3 links between switches, with the top 2 configured into an Etherchannel. R2 trunks to SW2, using 802.1Q, so that R2 can route between all the VLANs. (No layer 3 switch needed in this case.) And to match the sample configurations I’ll add as we go along, SW1 happens to have a lower base MAC address than SW2, so that with all defaults for STP configuration, SW1 will become the STP root.
From a layer 3 perspective, R1 acts as a host in VLAN 2, subnet 10.1.2.0/25. PC1 of course acts like a host, but in VLAN 3, subnet 10.1.3.0/26. The STP discussions will focus on the packet sent from R1 to PC1 when R1 pings PC1. So, from a layer 3 perspective, the flow of an ICMP echo request from R1 to PC1 actually goes to R2, with R2 routing the packet back to PC1, as shown in this figure:
At this point in reading today’s post, you’ve got a choice:
1) Go do this CCNA-level lab – for real on your gear, on paper, or just think it through – to build everything described above.
2) Just go with the description above, and move on to start thinking about how STP works with some upcoming STP requirements.
If you choose option 1 for now, you’ll link to a PDF with more detail and some suggested steps. For those of you looking for something to do to practice for CCNA, this informal lab exercise is a pretty comprehensive lab for a lot of CCNA-level switch configuration. But you don’t have to do the lab to think about STP in the design and topology described above.
Next, let’s talk about how to use this topology and design to experiment with STP. To do so, let me suggest the following requirement related to what happens with R1 pings PC1. When R1 pings, it generates an ICMP Echo Request packet. With this topology (see 2nd figure), the ICMP Echo Request goes through subnet 10.1.2.0/25 (VLAN 2), to R2. Then, R2 forwards the packet through subnet 10.1.3.0/26, VLAN 3, to PC1. Given these facts, configure STP such that:
- The Echo Request goes from R1, over the Etherchannel, to R2
- The Echo Request goes fromR2, over the lower (Fa0/10) link, to PC1
In other words, it goes over the top link (Etherchannel) left-to-right through VLAN 2, and over the lower trunk (F0/10) in VLAN 3, right-to-left in the figure.
This may seem pretty simple, and I’m sure some of you are already thinking exactly how to change the config. But the bigger question is this:
How many unique STP configuration sets meet these goals?
To be clear, I’m not asking how many STP topologies meet this goal. I’m asking how many different ways can you change the configuration to meet these goals. If making SW2 root is part of a solution, and there’s only 1 way to make SW2 be root, fine. But if there’s 5 ways to make SW2 be root, that’s 5. The goal is to exercise your memory recall with the filter of “what impacts frame flow in a VLAN”. Then, you can write sample configs, or do it on your lab, or offer your suggested configs here.
So, let me get out of the way, and you folks can post your thoughts. Feel free to post about the baseline CCNA lab, and/or the STP options to cause the desired flow of the ping. Enjoy!
