Ticket#18 – Spanning Tree Topology Change Flood: Root Guard Protects Core Switch [CCNP Enterprise]

Problem Summary

A large enterprise network started experiencing random connectivity drops across departments. Printers became unreachable, VoIP calls dropped, and some switches rebooted due to CPU spikes. On closer inspection, the Spanning Tree topology kept changing every few seconds.

Logs across core switches showed constant TCN (Topology Change Notification) floods. This was causing MAC address table flushes across the network, leading to erratic behavior.

---

Symptoms Observed

• Intermittent packet loss across VLANs
• VoIP phones re-registering frequently
• MAC flaps in logs (%SW_MATM-4-MACFLAP_NOTIF)
• show spanning-tree showed frequent role changes on uplink ports
• vMotion and network storage latency spiked
• show spanning-tree detail showed repeated topology changes originating from access ports

---

Root Cause Analysis

An access-layer switch was incorrectly connected to the network using an uplink configured as an access port. This rogue switch had:

• Lower Bridge Priority than the Core (0 by default)
• No Root Guard or BPDU filtering on the uplink port
• As a result, it started advertising itself as the Root Bridge
• Core switches lost Root status, triggering network-wide STP recalculation
• Every recalculation = topology change + MAC flush = chaos

---

The Fix

1. Enabled Root Guard on all user-facing and distribution-facing uplinks: interface Gig1/0/2 spanning-tree guard root
2. Detected the offending switch using: show spanning-tree root show cdp neighbors
3. Physically removed the unauthorized switch from the network
4. Configured correct Bridge Priority for Core to ensure it always remains Root: spanning-tree vlan 1 priority 4096
5. Enabled BPDU Guard on access/user ports: interface range fa0/1 – 24 spanning-tree bpduguard enable

---

EVE-NG Lab Topology

• SW1 was the original Root.
• Rogue Switch sent BPDUs with lower bridge ID → network re-elected it as Root.
• Root Guard on Access2‘s uplink later blocked the rogue BPDUs.

---

Verification

Command	Purpose
show spanning-tree	Check Root Bridge and port roles
show spanning-tree detail	See source of topology changes
show cdp neighbors	Identify rogue switch or device
show errdisable recovery	Confirm if port was disabled due to Root Guard
`show logging	i STP`
show mac address-table	Track MAC flaps or missing entries

---

Key Takeaways

• STP is sensitive to new Root Bridge announcements
• Unauthorized Root = frequent topology recalculations = network-wide MAC table flushes
• Root Guard protects infrastructure by blocking root role on undesired ports
• Always set custom bridge priorities; never leave core as default 32768
• User/access ports should have BPDU Guard to prevent accidental loops

---

Best Practices / Design Tips

• Set Root Bridge priority on Core and secondary Root on Distribution
• Use Root Guard on all access & distribution uplinks
• Apply BPDU Guard on all host-facing ports
• Configure Loop Guard on non-designated STP ports
• Document physical uplinks to avoid rogue plug-ins
• Monitor MAC address table flaps for signs of loops or STP instability
• Audit all ports regularly—disable unused ports

---

FAQs

1. What causes frequent STP topology change notifications (TCNs)?

Answer: TCNs can be triggered by port flaps, misconfigured switches, or unauthorized devices becoming the STP root bridge. These changes flood the network, resetting MAC address tables and causing intermittent connectivity.

---

2. What is the impact of constant STP topology changes?

Answer: It can cause:

• Frequent MAC address flushes on switches
• Temporary communication loss for end hosts
• Unstable network performance (especially for voice and video)

---

3. What is the function of Root Guard in STP?

Answer: Root Guard prevents an interface from becoming the root port if it receives a superior BPDU. It protects the intended root bridge by blocking misbehaving or rogue switches from taking over.

---

4. How does Root Guard respond to a superior BPDU?

Answer: The interface is placed into a “root-inconsistent” state, effectively blocking it until superior BPDUs stop arriving. It then resumes forwarding once the threat is gone.

---

5. How do I enable Root Guard on an interface?

Answer: Use the following command:

interface GigabitEthernet1/0/2  
 spanning-tree guard root  

---

6. How do I verify that Root Guard has been triggered?

Answer: Use:

show spanning-tree inconsistentports  

This will list ports in root-inconsistent state due to Root Guard.

---

7. Where should Root Guard be applied?

Answer: On access or distribution layer ports that should never receive superior BPDUs — especially toward downstream access switches.

---

8. What is the difference between BPDU Guard and Root Guard?

Answer:

• BPDU Guard shuts down a port if any BPDU is received (used on edge/user ports).
• Root Guard blocks the port if it receives superior BPDUs (used on ports connecting to switches).

---

9. Can Root Guard prevent a STP loop?

Answer: Not directly. It prevents topology instability by keeping rogue switches from becoming root, but loops are typically handled by STP port roles and states.

---

10. What are superior BPDUs in STP?

Answer: BPDUs from another switch that advertises lower bridge ID than the current root. Receiving these may trigger a new root election unless blocked by Root Guard.

---

11. What is the “root-inconsistent” state?

Answer: A temporary blocking state enforced by Root Guard. The interface does not forward traffic until superior BPDUs stop arriving.

---

12. Can Root Guard be used in Rapid-PVST or MST?

Answer: Yes, Root Guard works with PVST+, Rapid-PVST, and MST. It operates similarly in all modes by monitoring BPDUs.

---

13. Does Root Guard require global configuration?

Answer: No. It’s a per-interface feature. No global command is needed — you just apply it to the relevant switchport.

---

14. What if a legitimate new core switch sends superior BPDUs?

Answer: If a new root bridge is expected, remove Root Guard on the interface first. Otherwise, the port will block traffic and create connectivity issues.

---

15. How to permanently prevent unauthorized STP role changes in access layer?

Answer:

• Use Root Guard on uplinks
• Use BPDU Guard on edge ports
• Set bridge priority manually on root and secondary root
• Disable STP where not needed (e.g., on routed ports)

---

YouTube Video

Watch the Complete CCNP Enterprise: Spanning Tree Topology Change Flood: Root Guard Protects Core Switch Lab Demo & Explanation on our channel:

---

Final Note

Understanding how to differentiate and implement Spanning Tree Topology Change Flood: Root Guard Protects Core Switch is critical for anyone pursuing CCNP Enterprise (ENCOR) certification or working in enterprise network roles. Use this guide in your practice labs, real-world projects, and interviews to show a solid grasp of architectural planning and CLI-level configuration skills.

If you found this article helpful and want to take your skills to the next level, I invite you to join my Instructor-Led Weekend Batch for:

CCNP Enterprise to CCIE Enterprise – Covering ENCOR, ENARSI, SD-WAN, and more!

Get hands-on labs, real-world projects, and industry-grade training that strengthens your Routing & Switching foundations while preparing you for advanced certifications and job roles.

Email: info@networkjourney.com
WhatsApp / Call: +91 97395 21088

Upskill now and future-proof your networking career

---