cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2621
Views
5
Helpful
6
Replies

Spanning tree and VOIP

jegan537
Level 1
Level 1

Spanning tree question:

I have heard various opinions regarding using spanning tree on a switched network where voice traffic will be utilized and wanted to get some more thoughts on the subject.

I can see certain situations in which spanning tree may not be a good fit when VOIP is involved such as constantly changing topologies and the like, but I still believe that spanning tree can be a good fit in topologies where its function would be for disaster recovery on failed links only.

What are some thoughts on the subject?

6 Replies 6

saro
Level 1
Level 1

In the last couple of years, I have made a concerted effort to avoid STP with all redundant network configurations. I've tried to move my L3 domain as close to the edge (access) as possible, that said, this is not always an option.

In cases where you cannot use routing to avoid STP, then you are relegated to having to use "something else" to provide for failover for your L2 network. If you are running VoIP, IMO, you MUST have a redundancy, therefor, you will have to have STP in this scenerio. Do a couple of things to save yourself. Identify the root bridge and configure it with a priority of 0, identify a secondary root and identify it with a priority of 4096. This will help avoid regular path recalculation and changes.

One other option, if you are really anti-STP, is to look into flex-links on your newer Cisco switches. Be very careful in how you deploy this technology and make sure you lab-test it to see how it behaves... but it is a pretty good alternative IMO, and may lead to faster convergence.

Mohamed Sobair
Level 7
Level 7

Hi,

STP prevents from L2 switching Network loops and provide Root Optimization. If you dont have redundant links on aNetwork, Then there is no possibility of a loop so u can disable STP. but as long as u have redundant links, you should run STP because there is a possibility of a loop and u are definetely want to protect ur VOIP traffic from being looped. I really dont know why people dont like STP, its very simple in terms of configuration and u can minipulate as per ur requirment (Load Balance , root ports ...etc). All u have to do is the initiall config, All of STP calculations are done for you by the Switch.

Regards,

Mohamed Sobair

Mohamed, that's a relief for me to see there are few users who actually don't hate STP! I'll rate you a grateful 5 point (if you ever care) for that;-)

Regards,

Francois

Dear Francois,

I really appreciate your rate, beleive me its an honor to be rated from people like you.

I apologize, I know you are the Switching HERO , but I have replied insted of you.

Regrds,

Mohamed Sobair

Hello:

As was srtated earlier, a high availability network topology requires that redundancy be strategically deployed. The massive outage caused by not having redundancy in the event of a link failure should make it clear that redundancy must exist.

Also, having that redundancy without a means to proactively avoid and detect layer 2 loops can lead to the shutdown of the entire switch fabric in the event of a loop.

So, yes, you need redundancy and you need STP.

Here are some thoughts and recmmendations:

Deploying STP in the switched access layer is always recommended, even if the design engineer does not deliberately install redundant trunk links between switches, for the following reasons:.

? If there is a loop, STP prevents issues that can be made worse by multicast and broadcast data. Often, mispatching, a bad cable, or another cause induces a loop.

? STP protects against an EtherChannel breakdown.

? Most networks are configured with STP, and therefore, get maximum field exposure. More exposure generally equates to a more stable code.

? STP protects against misbehavior from dual−attached NICs (or bridging enabled on servers).

Configuring STP is relatively easy and the control plane traffic overhead is very small. If STP is configured properly, network convergence times after an outage can be as low as 200 ms.

Configure STP in the following manner:

1. Use RPVST+ (802.1W) unless the BackboneFast and Uplinkfast features are not recommended in a particular topology (see 6 & 7 below).

2. Do not change the max-age or forward delay timers, as that can adversely affect stability. Network diameter should not exceed 7 hops.

3. Keep user traffic off the management vlan.

4. Do not overdesign redundancy. Too many blocked ports are a potential disaster waiting to happen.

5. Be deterministic in the deployment of STP. Rig the root bridge elections by setting the priority and then document all root ports, designated ports and blocking ports to create a baseline document for normal network conditions.

6. Do not enable Uplink Fast on access switches that have more than 2 uplinks.

7. Enable BackboneFast on all switches running STP only if they can all support BackboneFast, too.

8. Enable Loopguard and UDLD aggressive (Unidirectional Link Detection) globally if the switch allows this. Otherwise, do it on the individual interfaces, including EtherChannels.

9. Enable PortFast on access ports and, if it is a Cisco switch, issue the interface level switchport host command to optimize the auto-negotiation feature of the access port.

10. Enable BPDU Guard on all access ports that are configured for PortFast.

I agree when done correctly STP is not a problem . There should be very few topology changes if it configured correctly with root bridges and secondary roots and long with portfast on user ports will generally give you a stable environment . turning STP off is dangerous in my opinion . Even if you don't have built in redundancy all it takes is someone to plug in a patch from one switchpor to another unwittenly and you are off to the races . If you are worried about convergence time look into usinf rapid stp which will give you failover within a couple seconds usually .

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco