I made a change because it had an error. DSW1 and DSW2 should use a dynamic method to establish a trunk. DSW1 should do this actively, DSW2 passive. It has been fixed. Thanks!
Rene
1 Like
Thanks, I just fixed this.
Itās been a year since I posted this, but I now have two mini PCs with AMD Ryzen 9 CPUs 8c/16t and 64GB of DDR5 RAM. I have Proxmox installed on them. In Proxmox, I have three VM containers with CML 2.8 and 2.9 and GNS3 (the latest version). I havenāt had any resource issues since.
1 Like
Hello Michael
Nice to hear from you again! Thatās good news, thanks for sharing that with us. The setup of your hardware for emulation plays a major role in the performance of the topology you create. Thanks again for sharing
Laz
Hello Rene, Laz,
Dynamic method to negotiate trunks is not recommended by Cisco. Cisco suggests manually configuring trunk links to avoid potential misconfigurations and security issues that can arise from automatic negotiation. I think this point should not be proposed in a lab like this and instead use manually configured trunk links. Best regards Michael.
Furthermore I am asking myself why spanning-tree is never applied to vlan 1. Itās normal business to set the priority higher then the others to prevent VLAN 1 becoming a root bridge.
spanning-tree mode rapid-pvst
spanning-tree extend system-id
spanning-tree vlan 1 priority 61440
spanning-tree vlan 1,10,20,30 priority 4096
spanning-tree vlan 10 hello-time 3
spanning-tree vlan 10 forward-time 10Hello Michael
Indeed, Cisco recommends completely disabling the use of DTP when creating trunks. The purpose however of the lab is to allow users to experiment with the capabilities that exist, so that if they discover some strange behavior, they will be able to identify it as behavior due to the use of DTP.
Having said that, it is useful to indicate clearly that it is best practice to disable DTP. I will let Rene know to take a look and consider making any changesā¦
I hope this has been helpful!
Laz
1 Like
Hello Laz, Rene, I see that I made a mistake the priority should be lower of course 61440 is the lowest priority and 0 the highest priority but de lowest value and 61440 is the highest value. I guess I am a little confused with the labels because of the selection of a DR/BDR routers where it the other way around. VLAN 1 participates in rapid SPT, just as the other vlans but in theory VLAN 1 can become the root bridge right? To prevent this you should set it to the value of 61440 which is the highest value but lowest priority. What do you advice?
Hello Michael
I didnāt see the next section you added to your original post, Iāll address that now:
If you take a look at the 4.2.4.2 Primary and Secondary Root of the lab, youāll see that STP is applied to VLAN 1 as well, and a priority of 0 is set for DSW1 for all VLANs. In any case, priority settings can be confusing especially when OSPF DR/BDR priority settings work the opposite way!!
You can indeed configure a switch to become the root or to not become the root for any particular VLAN, including VLAN 1. Now, whether you want to do that or not depends on the topology and the specific VLANs in question. For this particular lab, the DSW1 switch is configured with a priority of 0 (highest priority) to become the root bridge for all VLANs, including VLAN 1, and thatās perfectly valid. Unless you have specific requirements, this setup is fine as it is.
I hope this has been helpful!
Laz
1 Like
Thank you Laz clear as always.
Best regards, Michael
1 Like
Hello Laz, Rootguard is even a better solution and more reliable then setting a priority of 0 or 61440 (vlan 1). Do you agree?
Best regards,
Michael
Hello Michael
You are correct, it is possible to use Rootguard to achieve something similar, but you have to keep in mind that Rootguard and the setting of the bridge priority are two different features that solve two different problems.
The priority value is the feature that you should use to deliberately set the root bridge in your topology. By configuring the priority appropriately in all switches, you can cause a specific switch to become the root.
The Rootguard feature however is used on ports where you NEVER want a superior BPDU. This should be done on access ports and edge facing ports. This protects against users plugging in ārogueā switches on ports where switches should never be plugged in, and messing up your choice of root bridge!
Rootguard should never be put on links that could legitimately become a root port, such as switch uplinks. During a failure, this can cause a potential backup link to stay down!
So Rootguard isnāt more reliable than setting the priority, but it works in a complementary manner. You should set priorities in the core while enforcing boundaries with Rootguard at the edge. Does that make sense?
I hope this has been helpful!
Laz
Thanks Laz! Really appreciate your clear explanations.
Best regards,
Michael
1 Like