Hello Heng
When a port goes into root inconsistent state, it is essentially the same as the listening state. According to Cisco:
This root-inconsistent state is effectively equal to a listening state. No traffic is forwarded across this port. In this way, the root guard enforces the position of the root bridge.
I hope this has been helpful!
Laz
Hi,
" Let me show you the configuration by using SW2 and SW3, first I will make sure that SW3 is NOT the root bridge:"
Why ?
Thanks
Hello Sims
For the purpose of the example, the initial situation had to be such that SW2 is the root bridge and not SW3. By making the priority of SW2 a lower value (meaning higher priority), the initial topology would make SW2 be the root. The next steps in the procedure of the lesson made SW3 have a lower priority value, essentially making it send a superior BPDU. In this way, we are able to observe what happens to SW2 when rootguard is enabled.
I hope this has been helpful!
Laz
So letâs say a new distrobution switch becomes the root bridge and the BPDU is stooped at the core switch⌠doesnât this mean everything from the distribution layer down would still use the distro switch as the root? If so, who cares if the core still thinks itâs the root? Doesnât this make it a moot point? Or am I missing something?
Hello Jonatgan
On any network, if you have two switches that believe they are the root bridge for the same VLAN, you have the potential for a Layer 2 loop. Remember that root bridges donât have any blocked ports. If the topology is just right (or just wrong, depending on how you look at it), then such a situation would indeed occur.
Iâm not sure if I have successfully answered your question, but if not, can you clarify with an example?
I hope this has been helpful!
Laz
I think I didnât ask my question very well. In the lesson it was mentioned that you could use root guard on the core switch so it would block any BPDUâs that are superior. Letâs say I want to intercept traffic on a network like the one here (I canât upload yet so Iâll share the link instead) https://ibb.co/NS0RV2q. Right now letâs say the switch on top is the root bridge (it is). So currently spanning tree on each switch looks like this:
iosvl2-1 Mon Feb 24 2020 22:15:35 show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 4097
Address 5e00.0000.0000
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 4097 (priority 4096 sys-id-ext 1)
Address 5e00.0000.0000
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Desg FWD 4 128.2 P2p
Gi0/2 Desg FWD 4 128.3 P2p
iosvl2-5 Mon Feb 24 2020 22:15:35 show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 4097
Address 5e00.0000.0000
Cost 8
Port 2 (GigabitEthernet0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 5e00.0004.0000
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Root FWD 4 128.2 P2p
Gi0/2 Altn BLK 4 128.3 P2p
iosvl2-4 Mon Feb 24 2020 22:15:35 show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 4097
Address 5e00.0000.0000
Cost 8
Port 2 (GigabitEthernet0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 5e00.0003.0000
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Root FWD 4 128.2 P2p
Gi0/2 Desg FWD 4 128.3 P2p
iosvl2-2 Mon Feb 24 2020 22:15:35 show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 4097
Address 5e00.0000.0000
Cost 4
Port 2 (GigabitEthernet0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 5e00.0001.0000
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Root FWD 4 128.2 P2p
Gi0/2 Desg FWD 4 128.3 P2p
Gi0/3 Desg FWD 4 128.4 P2p
iosvl2-3 Mon Feb 24 2020 22:15:35 show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 4097
Address 5e00.0000.0000
Cost 4
Port 2 (GigabitEthernet0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 5e00.0002.0000
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Root FWD 4 128.2 P2p
Gi0/2 Altn BLK 4 128.3 P2p
Gi0/3 Desg FWD 4 128.4 P2p
Now letâs say I have root guard enabled on the top switch (current root) but then someone changes the priority of spanning tree for vlan 1 to 0 on switch iosl2-5. This will make all traffic on iosl2-4 go through iosl2-5 now instead of iosl2-2. It also causes the ports on iosl2-1 to go into BRK state. I will post the output of show spanning-tree below after the change of the root bridge.
So my question is, since this still hijacks traffic and also causes the core switch to block traffic what good did it do? We still donât actually stop the bad switch/computer/whatever from redirecting traffic and causing core switch ports to go down. Or is the point to cause an issue at the core on purpose so people would look into it and it doesnât go unnoticed? Below is the output of show spanning-tree after the root change:
iosvl2-4 Mon Feb 24 2020 22:26:5 show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 1
Address 5e00.0004.0000
Cost 4
Port 3 (GigabitEthernet0/2)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 5e00.0003.0000
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Desg FWD 4 128.2 P2p
Gi0/2 Root FWD 4 128.3 P2p
iosvl2-1 Mon Feb 24 2020 22:26:5 show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 4097
Address 5e00.0000.0000
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 4097 (priority 4096 sys-id-ext 1)
Address 5e00.0000.0000
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Desg BKN*4 128.2 P2p *ROOT_Inc
Gi0/2 Desg BKN*4 128.3 P2p *ROOT_Inc
iosvl2-3 Mon Feb 24 2020 22:26:5 show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 1
Address 5e00.0004.0000
Cost 4
Port 4 (GigabitEthernet0/3)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 5e00.0002.0000
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Desg FWD 4 128.2 P2p
Gi0/2 Desg FWD 4 128.3 P2p
Gi0/3 Root FWD 4 128.4 P2p
iosvl2-5 Mon Feb 24 2020 22:26:5 show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 1
Address 5e00.0004.0000
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 1 (priority 0 sys-id-ext 1)
Address 5e00.0004.0000
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Desg FWD 4 128.2 P2p
Gi0/2 Desg FWD 4 128.3 P2p
iosvl2-2 Mon Feb 24 2020 22:26:5 show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 1
Address 5e00.0004.0000
Cost 8
Port 3 (GigabitEthernet0/2)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 5e00.0001.0000
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Desg FWD 4 128.2 P2p
Gi0/2 Root FWD 4 128.3 P2p
Gi0/3 Altn BLK 4 128.4 P2p
Thanks!
Hello Jonatgan
You are correct that if you enable RootGuard on the top switch, it will not protect the network from such a situation. In order to see the benefits of RootGuard, it must be implemented at the appropriate locations on the network.
In basic terms, the RootGuard feature simply prevents a designated port from becoming a root port if it receives a superior BPDU. This means that you should implement RootGuard on all switch ports that are connected to other switches that should never become root bridge. For example, the port on a distribution layer switch connected to an access layer switch can be enabled with RootGuard because an access layer switch should never become root bridge.
For your specific topology, in order to see the benefits of RootGuard, you would enable it on all designated ports on all switches on the topology, and not just on the top switch.
I hope this has been helpful!
Laz
Oh I see now. I misunderstood what was being said in the lesson. Sorry about that.
Thank you for clearing it up.
Laz,
If you want to enable âSpanning-Tree RootGuardâ on a core switch, then do you enable it directly on the port-channel or you need to enable it on each interface that is configured as port-channel?
Thanks!
Hello Eyad
Whenever configuring STP related features such as BPDUGuard, RootGuard, LoopGuard, and BPDUFilter, you always apply them on the port-channel interfaces and not on the physical ports. The only exception is UDLD which is strictly a physical layer protection mechanism.
I hope this has been helpful!
Laz
Great. Thanks for your help!
Hi, My understanding is when the port receives a superior bpdu it goes into root inconsistent state.
As mentioned this can be seen with âshow spanning-tree inconsistentportsâ and can also be seen with show spanning-tree Vlan [vlan number]
But my understanding is if you look at the running config of the interface it will still show as Up and Up even though its in root inconsistent state. eg show interface Fa 0/1
Regardless of this what I am wondering is if a port goes into root inconsistent state does it drop regular traffic also ? or is it just bpduâs its dropping ?
Is all normal traffic blocked on that port until the offending device stops sending the superior bpdus or does it only block bpdus ?
Thanks.
Hello Sean
Yes, this is the case assuming that rootguard has been configured on that port.
The running config does not show the state of a port. In order to see the state of a port, you must issue the show inter status command. But even this command will show the interface up.
An inconsistent state simply means that the port operates as if it is blocked. It will remain blocked until it stops receiving superior BPDUs. As soon as that happens, after a certain timeout, it begins forwarding again.
I hope this has been helpful!
Laz
Yes sorry I ment to say the show inter status command as you mentioned.
Your answer is extremely helpful, Many thanks Lazaros.
Hi Laz,
If we we have no of switches n which one is root bridge then in this case on what switches we have to enable Root Gaurd feature?
Hello Pradyumna
In general, when designing a network and installing switches, you decided which switch should become the root bridge for each instance of STP. If you have full control of the network, and you know that no other switches will be connected to your topology, then you really donât need to enable rootguard. However, if for example, you have a network topology to which customer routers will be connected such as is the case in a metro ethernet application, or in a building network to which tenants connect their switches, then you want to ensure that those other switches (which are not under your direct control) will not become root bridges in your topology. So rootguard should be enabled on ports of your switches where you know other switches are connected (customer switches). Any superior BPDUs received will be ignored.
This is in contrast to BPDUGuard, which is enabled on access ports where you expect end devices to connect and never switches.
I hope this has been helpful!
Laz
Mean it will be configured on the ports of our switches those are managed by us but connected to other third party switches to ensure that any switch from third party will not become root bridge.
But where shall i get this case where customer switches connect to ISP or switches of different organizations n/w connected to each other? Their must be router or Layer 3 switch where routing is enabled?
Hello Pradyumna
Yes thatâs exactly it.
In many cases you are right, you will have a Layer 3 device somewhere between the networks, but that is not always the case. There are situations where you only have Layer 2 connectivity. Some examples include:
Metro Ethernet is one such case. The ISP can provide you with a Layer 2 connection between multiple sites. You will connect your switch to the fiber optic cable they terminate at your premises. That cable is connected to a switch on the ISP, and that switch has to be protected from superior BPDUs that the customer switch may send.
Another case is if you have a multi-tenant office building where you provide network services to the companies renting the office space. The companies will connect their switches to your switches in your infrastructure. Once again, you want to ignore any superior BDPUs from customer devices.
I hope this has been helpful!
Laz
ROOT Guard , BPDU Guard , BPDU Filter , LOOP Guard , UDLD
Applying all of this, is it the best design??
I think the Guard command is a good command to prevent L2 issues.
Unfortunately, however, Iâve rarely seen use of the Guard command in enterprises.
I want to know what you think
I need a contextual example.
Hello YongHun
This is a really good question of how you should correctly apply these features and under what situations. These are all valid features but should be used in particular situations as needed. For most conventional network designs, the majority of the features are not needed. Hereâs a quick review of where to use each one:
Root Guard - Prevents a port from becoming a root port. This prevents a downstream switch from becoming a root bridge. This is useful when you have a multi-tenant situation where you donât have direct control over all of the switches connecting to the network, and you want to make sure that your STP topology remains stable.
BPDU Guard - This feature shuts down a port configured with PortFast in the event that a BPDU is detected. This protects against employees bringing in their own switches, connecting them to their network jacks in their offices, possibly causing their ârogueâ switches to become a root bridge. Only hosts should be connected to PortFast ports, and this mechanism protects against such situations.
BPDU Filter - Prevents BPDUs from being sent on an interface. It will also ignore any incoming BPDUs on the interface.
This essentially disables STP on this interface. This is rarely needed so it is likely you will never see it in a production network. You can use this in situations where you want a switch to connect to that port, but you donât want it to participate in STP.
Loop Guard and UDLD - Used for situations where you may have unidirectional link failures, such as when youâre using fiber optics, or unidirectional satellite links. This too will be rarely used in general because of the rarity of these kinds of failures but should be enabled where high availability is crucial.
I hope this has been helpful!
Laz