Re: Networking/Switching Configuration Lab

MyNetworkingJourney · ‎10-06-2025

Hello everyone,

I wanted to share a lab I started working on.

As you can see above I have one Core Switch, with two Distribution Switches and 3 Access Switches. The steps I've taken at this point are below:

1. Entered the CLI of DSW2(Top right switch) and then I input the following commands

- In Global config mode vtp domain CCNA then I followed that up with vtp password CCNA | This created the VTP domain of CCNA with password CCNA which will allow our VLAN's to be populated/received by our Client switches for easier VLAN distribution.

2. Again in Global config mode, I then entered vlan 8 > int vlan 8 , vlan 12 > int vlan 12, vlan 24 > int vlan 24 \ Each of these allow the creation/up status of each VLAN on the switch.

3. I then entered the following spanning-tree vlan 1,8,12,24 root | This designated Switch 2 as the root bridge for the needed VLANs

4. Once that was complete I began connecting all the switches together, see below for interface setup

DSW2(Distribution Switch 2) "Root"

-DSW2 G0/1 -> CoreSW G0/2

-DSW2 FA0/1, G0/2 -> DSW1 FA0/1, G0/2

-DSW2 FA0/2 -> ASW1 G0/2

-DSW2 FA0/3 -> AW2 G0/2

-DSW2 FA0/4 -> ASW3 G0/2

DSW1(Distribution Switch 1)

-DSW1 G0/1 -> CoreSW G0/1

-DSW1 FA0/1, G0/2 -> DSW2 FA0/1, G0/2

DSW1 FA0/2 -> ASW1 G0/1

DSW1 FA0/3 -> ASW2 G0/1

DSW1 FA0/4 -> ASW3 G0/1

5. I used the command switchport mode trunk for all ports, to allow the inter-VLAN communications to occur. The trunk also permits the VLAN's to be spread through each switch. Without it they would not receive the Root VLAN setup.

6. I configured each switch to join the CCNA domain, and also set their passwords to CCNA as well, and I set them to vtp mode client as the final step for VLAN propagation.

7 I entered global config mode for CoreSW and created all VLAN's for this device. As a L3 switch, I also entered the following command within each respective VLAN

int vlan 1 > ip address 192.168.1.1 255.255.255.0 | int vlan 8 > ip address 192.168.8.1 255.255.255.0 | int vlan 12 > ip address 192.168.12.1 255.255.255.0 | int vlan 24 > ip address 192.168.24.1 255.255.255.0

These commands set the IP address along with the mask for the respective VLAN.

8. Once this was completed I entered switchport trunk allowed vlan 1,8,12,24 | To set those specific VLAN's to travel over the trunk links.

9 After this was finished, I decided to set an Etherchannel link between both DSW's int range fa0/1, g0/2 > channel-group 1 mode desirable on both ends. | Etherchannel is for link redundancy, extra bandwidth, and load-balancing between switches and also routers

10. I used int po1 > switchport mode trunk > switchport trunk allowed vlan 1,8,12,24 | To make sure communication can be made between those port channel's

11. I began adding endpoints PC0 for VLAN 12 and PC1 for VLAN 24 and PC2 for VLAN 8

12 I then began to successfully send pings to the L3 router via the SVI configurations we made in each VLAN

PC0

PC1

PC2

I attempted to ping the other computers but had no luck, the fix for this was because I forgot to add ip routing in the CoreSW global config mode | Enables inter-vlan routing to occur, allowing you to reach other switches with separate VLAN's via the dot1q tag over our L3 switch

This is the successful ping!

I had fun working on this lab, and wanted to share with the Cisco community. Any feedback would be appreciated, if maybe you would advise setting up the network in a separate way and/or if you have any tips they would all be great to hear.

Final Network topology

I didn't add any normal router for WAN simulation in this lab, but I may add to this specific topology to implement/use as a major "super" lab in the future.

Thank you for taking the time to view the thread!

Joseph W. Doherty · ‎10-06-2025

I would suggest also attaching your final PT file as a zipped attachment.

Why did you select the switch you did for root switch? What about secondary root?

Is there really much benefit to the Etherchannel you configured? Did you adjust its LB selection?

Did you modify the STP being used?

What feature do some of real Cisco switches offer, but PT doesn't provide, might be very useful? (Hint: 3750 and later switches.)

MyNetworkingJourney · ‎10-07-2025

Hi Joseph,

Thank you for replying.

I didn't have a specific reason for choosing that switch as the root, more so due to the logical layout, that I wanted it as a distribution switch linked directly to the L3 Core. I could've set the CoreSW as the root, but I am unsure if that is a common practice. I also didn't set a secondary root, not for any specified reason, I understand it would improve the topology in relation to extra redundancy, however I wound up sticking to the setup I implemented.

In regard to the Etherchannel, I suppose with the links connecting from each ASW to the distribution switches, I suppose there wouldn't really be a need to configure it. I suppose it would make more sense to remove those extra links and instead use the port channel as the links between DSW's. I'll also be honest I'm unfamiliar with the term LB selection.

In regard to the STP being use, I assume you're referring to the version. I'm using standard STP no RSTP or any other variation. From what I have seen PT doesn't offer to many other options such as MSTP.

I've had a lot more experience using PT as opposed to real world devices. In this case I don't think I have the experience to offer any true answer on that, besides what I stated above in relation to the STP options. Fortunately, for I do have access to equipment I can, and have used. I was able to setup an RoAS configuration on a 2911 and two 3750's (the same ones you stated). I also setup VTP's on these topologies as well. I need to dive deeper and become more comfortable using the real devices for my own practice, which I plan on doing.

Some other things I didn't mention is setting of VLAN's on the access ports for the appropriate interfaces. I also will add I did configure Portfast on some of the interfaces as well, to allow the links to go passed the LST and LRN phases.

I appreciate the questions Joseph, and hope to hear from you again.

Joseph W. Doherty · ‎10-07-2025

@MyNetworkingJourney thank you for your reply to my reply. Which, BTW, purpose was to stimulate you're thinking about your lab.

Often common practice for root switch selection, if possible, is its placement on the gateway switch for the VLAN, as it's often the core of the L2 VLAN topology, which, generally, you want the root switch to be.

Losing a root switch is a big deal, and as we generally want to place a root switch as the root of the L2 topology, if the root fails, having preassigned a secondary root avoids just any switch "randomly" becoming the new root. Assuming you have multiple L2 paths, STP will "automatically" provide "redundancy", but the primary and secondary root assignments allow an optimal/best L2 topology.

The reason I questioned the Etherchannel setup, you have alternate paths via the core and edge switches, and by making the one distro switch the root, normally the only traffic between the two distro switches would be only from edge ports on the non root distro switch. All the other switches have a direct root link to the root distro switch. So, yes, Etherchannel provides redundancy and additional (aggregate) bandwidth, but, in your case, neither really leveraging the Etherchannel link between the two distro switches.

Regarding "LB" (my bad), it's load balancing. I.e. what load balancing algorithm is being used on the Etherchannel? Defaults vary by platform. Earlier Cisco switches had fewer options, and the usual default often only used just one of the Etherchannel links, at least in one of the two directions. I.e. if you don't use the "best" LB for your traffic, you'll have redundancy, but you'll not benefit from the additional aggregate Etherchannel bandwidth.

Yes, rapid-STP is what I had in mind as I believe PT provides it. It's much, much better than the non-rapid variant. It also has a couple of Cisco PVST features that are included in the rapid-STP standard. I.e. the typical Cisco default PVST should be reconfigured, if possible, to be at least rapid-PVST.

Wonderful you have real 3750s. A feature of them, that often had a huge impact on classical L2 topologies like your lab, is their stacking capability. If you were able to stack your two distro switches, each edge switch's dual uplinks, might be an Etherchannel uplink to a distro stack.

Further, although later Cisco L2 switches also might be stackable, switches like the 3750 are L3 switches, so your core and two distro switches might be replaced by a dual 3750 stack, supporting L2 to the edge switches, and providing routing between VLANs.

STP would only be a safety measure to preclude accidental L2 loop creation, and often, the stacking cables provide increased bandwidth between stack members. (Original 3750 StackWise bandwidth is described as 32 Gbps, which is [if a "full" duplex ring] two 8 Gbps duplex links, shared by the whole stack.)

The point being, your setup, is somewhat "classical" usage of standalone L2 and L3 switches, but with stackable L2 and L3 switches, hopefully no one would build a new network like your lab's. (That's not to knock the value of your lab as a learning exercise.)

Again, my prior reply, and this reply, are intended just for additional thought about a real world small network, not limited by PT features.

MyNetworkingJourney · ‎10-07-2025

When you refer to the Gateway switch for the VLAN. Are you referring to the gateway between L2 and L3 communication?

I see so you would want to have a secondary, Distribution Switch as your Secondary backup to maintain the STP topology?

I think I understand, so the two distro switches should only be receiving traffic from each other? At the same time the other switches (access) would be linked directly to the root distro switch, leaving a total of three distro switches, in this example?

I understand, so there are other load-balancing algorithms used for Etherchannel. This is referring to the desirable and active options right? Like PaGP and LACP?

Understood, so you would always advise to configure Rapid Spanning-tree instead of the standard version.

I found our infrastructure does have stacked switches, linking them together. I may go for a lab to configure that on those test machines. Wow I didn't even know the 3750's had L3 capabilities. I will look into that as well!

I appreciate your feedback and insight on this Joseph. Looking forward to hearing from you again!

Joseph W. Doherty · ‎10-08-2025

When you refer to the Gateway switch for the VLAN. Are you referring to the gateway between L2 and L3 communication?

Correct.

I see so you would want to have a secondary, Distribution Switch as your Secondary backup to maintain the STP topology?

You don't have to, but, again, if primary root fails, some other switch will become new root, and it might be a less than ideal in a root role.

I think I understand, so the two distro switches should only be receiving traffic from each other? At the same time the other switches (access) would be linked directly to the root distro switch, leaving a total of three distro switches, in this example?

No.

Basically, and usually, you want L2 traffic to take the least number of hops from source to destination.

I understand, so there are other load-balancing algorithms used for Etherchannel. This is referring to the desirable and active options right? Like PaGP and LACP?

No.

https://study-ccnp.com/etherchannel-load-balancing-explanation-configuration/

Again, options vary by platform.

Understood, so you would always advise to configure Rapid Spanning-tree instead of the standard version.

I would so advise. Cannot think of a reason to use non-rapid, if it's available, although there may be one. (Heck, rapid-STP is supposed to even work with a switch running non rapid-STP.)

I found our infrastructure does have stacked switches, linking them together. I may go for a lab to configure that on those test machines. Wow I didn't even know the 3750's had L3 capabilities. I will look into that as well!

They do have L3 although what's supported might be dependent on IOS installed (which may not support L3). Also, if IOS supports, you need to insure routing is enabled.

MyNetworkingJourney · ‎10-08-2025

This excellent information, I appreciate it Joseph, this will definitely assist in my studies.

I hope you have a great day.

Martin L · ‎10-08-2025

Alternative solution of Root switch at Core level (Core Switch) is Root at Distribution layer. Since u have 2 Distribution switches, u could make left switch0 as Root for all even number vlans (2,4,6,etc) and right switch as Root for all odd vlans. Furthermore, make left switch as Secondary Root sw for all odd vlans; and right one as secondary for even vlans. This would let u do load balance traffic a bit.

Core layer should be L3 routing /gateway as u have right now; it also could be a Router. In this case of critical /heavy volume traffic, for redundancy purpose, u could add 2nd Core switch/router.

Etherchannel links between Core and Distr. layers is a must !

Regards, ML
**Have fun labbing!!!***
***Please Rate All Helpful Responses ***

MyNetworkingJourney · ‎10-09-2025

Thank you for the response Martin, having one DSW as root for even and the other set for odd and having the opposite switch also be the secondary root for the opposing VLAN makes perfect sense.

I have heard that the L3 switches often have more "power" than the standard L2 switches. I see so sometimes there are two core switches used in the field for even more networking abilities.

Understood, I think I'll adjust this lab and post an updated version which hopefully ties together a better version of a network than I currently have setup. I'll probably remove the extra links from the ASW's to DSW's and add etherchannels between the DSW's and Core. Just one of the things I'll change.

Thanks again

Joseph W. Doherty · ‎10-09-2025

@MyNetworkingJourney wrote:

Thank you for the response Martin, having one DSW as root for even and the other set for odd and having the opposite switch also be the secondary root for the opposing VLAN makes perfect sense.

Actually, that was one of the huge benefits of PVST, i.e. you could have different logical L2 topologies for different VLANs.

However, that also goes back to the days when switches were 10 Mbps (for all Ethernet, and FD might only be available between switches) and they were not wire-speed capable for all ports, concurrently.

In modern networks, where usually any current Enterprise switch is wire-speed for all its ports, and 10g, or better, uplinks) isn't uncommon, going to the trouble of creating multiple distinct L2 topologies is, more-or-less, just a PIA. (Again, stackable switches, and larger chassis switches, also reduce the number of logical devices in the topology too. (For example, depending on your physical cabling needs, your whole topology might be just on one physical stack or chassis switch.)

@MyNetworkingJourney wrote:

I have heard that the L3 switches often have more "power" than the standard L2 switches. I see so sometimes there are two core switches used in the field for even more networking abilities.

Traditionally, the converse, as it's easier/cheaper to do L2 forwarding then L3 forwarding, in hardware.

As to having two core switches, well, if the core is a single point of failure for all L3 and/or connectivity between distro devices, redundancy for it, usually would be the most critical for your whole network.

Again, with current hardware, either a L2 or L3 switch might be wire-speed (i.e. max speed) for all its traffic, but the L3 switch more expensive for same overall bandwidth capacity.

Joseph W. Doherty · ‎10-09-2025

@Martin L wrote:

Core layer should be L3 routing /gateway as u have right now; it also could be a Router. In this case of critical /heavy volume traffic, for redundancy purpose, u could add 2nd Core switch/router.

As a side note, most small routers have very, very low throughput capacity compared to a like, or even lower, priced L3 switch. For example, a router with just a pair of gig ports, might not provide wire-speed between them while a L3 switch may support wire-speed for all its ports.

@Martin L wrote:

Etherchannel links between Core and Distr. layers is a must !

In the real world, possibly not.

For example, even discounting the Etherchannel between the two distro switches, you have triangle between the core and distro switches. If any one link fails, it's not a single point of failure.

If you didn't have any direct connectivity between the distro switches, even, if a single core<>distro link fails, you have connectivity via the edge switches. The latter, not "pretty", but again as most Enterprise switches are wire-speed capable, perhaps the biggest issue would be filling edge links.

Don't misunderstand, using Etherchannel for additional aggregate bandwidth and/or redundancy is very much a worthwhile thing to consider, but as whether it's actually truly worthwhile is an "it depends" answer, often unique to you.

Again, if real world, try to avoid PT limitations precluding you from possibly better solutions.

For example, if the cabling plant allowed, rather then using the 6 24 port switches you have, a dual 48 port 3750 stack, with IP Base, might actually be less expensive and provide more possible performance. For additional redundancy, using 3 3750s in stack, could allow for 75% or 100% port coverage warm standby if a stack member fails. STP topology issues, none. Etherchannel issues, none.

Lastly, Cisco was working on a new release (version?) for PT, which might be available. Don't know what new features it will have, but as great as a learning tool PT version 8 is, again, it's very limited. Great to learn basics with, but what you can do for networks for using it, might be very out of date for current real world networks.