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.
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.
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.
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 .
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts The ProblemOn traditional
switches whenever we have a trunk interface we use the VLAN tag to
demultiplex the VLANs. The switch needs to determine which MAC ...
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts Introduction: Netdr is a tool
available on a RSP720, Sup720 or Sup32 that allows one to capture
packets on the RP or SP inband. The netdr command can be use...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...