Options
RSTP vs Backbonefast vs 'tuned' Spanning Tree
What are your thoughts on using RSTP versus Backbonefast versus shortening the forward-time and max-age spanning tree times in order to speed up convergence? When I originally designed our MetroEthernet implementation I had only recently passed my CCNA and so did not know anything about the advanced features of other types of spanning-tree implementations. Now I am trying to decide if I need to change the design.
Apologizies for the long post, but I'm writing this out as much too make sure I understand what I am trying to do by explaining it to you folks as I am looking for your input. I don't have anyone to bounce these kinds of ideas off at work, so I'm turning to y'all.
After almost a year of delays, our providers are going to start testing our first MetroEthernet connection between our main location and our DR site next week. Once this link is up and running we will add another MetroE connection from a different carrier. These links are to replace the OC/3 we have now, both for cost savings and better redundancy - right now our backup plan is to use a site-to-site VPN connection over some bundled T1s (our VOIP traffic would love that, I'm sure). However, I want to load balance the traffic as well as have redundancy in the links. Here is the equipment:
Office:
5 4507 switches. It's a collapsed design with all switches having hosts connected to them, but two switches are the 'main' switches. These have primary and secondary server links and will be the two switches that have a connection to the MetroE. 6 vlans (data and voice are the big ones), but the MetroE vlans will be pruned from the trunks connecting to switches 3,4, and 5. Data and Voice vlan networks have HSRP default gateways hosted by switches 1 and 2. EIGRP is the routing protocol.
DR:
2 4948 switches (enterprise software image). These will each connect to a MetroE connection as well as servers and 2 ASAs for internet connectivity - our DMZ will reside on separate unmanaged switches. Separate VTP domain and the MetroE vlans will be the only allowed Vlans on the MetroE connections. EIGRP is the routing protocol, HSRP gateways for the MetroE vlans hosted by both switches.
Since we're paying for both connections, I want to actually use both connections without introducing a single point of failure. Due to cross-connect issues we cannot connect a single MetroE feed to two switches, therefore I am using two vlans trunked over each provider connection. The main switches will see two equal-cost routes, so they should load balance the traffic through both routes (right?). I want to make sure that each route takes a different physical path so I need to control the root and blocking ports so that each vlan's traffic takes a different path. Adjusting the priority values to control which switch is the root, and thus which ports are blocking, should take care of this.
If I am using layer-3 for load balancing, I need to rely on layer-2 for redundancy. The MetroE path has all manner of devices and links between my sites, and unless the carrier gear directly connected to my switches fails, the only way I will see the failure is through Unidirectional Link Detection. If I enable aggressive mode UDLD on the MetroE ports, they should err-disable the port if I lose a connection and initiate a topology change.
Now how do we handle that topology change? Currently we run PVST+ so I can tune the forward-time to 2 sec and the max age to 5 sec in order to improve the convergence time, but we still have to transition through all the port states. I'm not worried about the additional traffic because I am pruning the MetroE vlans from my other trunks. Backbonefast would immediately enable forwarding on the 'backup' port as soon as it receives an inferior BPDU, by sending out root queries and setting the max-age timer to 0. The only problem is that Backbonefast must be enabled on all switches and I don't know how it will affect my other switches and vlans. If I move to RSTP, the network converges very quickly, but there is a lot of traffic during that stage, so I need to be careful about the network initiating a convergence unecessarily.
For any of you who have used these different Spanning-Tree configurations, what are your thoughts? If I have made any incorrect assumptions or descriptions please let me know - don't worry about hurting my feelings.
Apologizies for the long post, but I'm writing this out as much too make sure I understand what I am trying to do by explaining it to you folks as I am looking for your input. I don't have anyone to bounce these kinds of ideas off at work, so I'm turning to y'all.
After almost a year of delays, our providers are going to start testing our first MetroEthernet connection between our main location and our DR site next week. Once this link is up and running we will add another MetroE connection from a different carrier. These links are to replace the OC/3 we have now, both for cost savings and better redundancy - right now our backup plan is to use a site-to-site VPN connection over some bundled T1s (our VOIP traffic would love that, I'm sure). However, I want to load balance the traffic as well as have redundancy in the links. Here is the equipment:
Office:
5 4507 switches. It's a collapsed design with all switches having hosts connected to them, but two switches are the 'main' switches. These have primary and secondary server links and will be the two switches that have a connection to the MetroE. 6 vlans (data and voice are the big ones), but the MetroE vlans will be pruned from the trunks connecting to switches 3,4, and 5. Data and Voice vlan networks have HSRP default gateways hosted by switches 1 and 2. EIGRP is the routing protocol.
DR:
2 4948 switches (enterprise software image). These will each connect to a MetroE connection as well as servers and 2 ASAs for internet connectivity - our DMZ will reside on separate unmanaged switches. Separate VTP domain and the MetroE vlans will be the only allowed Vlans on the MetroE connections. EIGRP is the routing protocol, HSRP gateways for the MetroE vlans hosted by both switches.
Since we're paying for both connections, I want to actually use both connections without introducing a single point of failure. Due to cross-connect issues we cannot connect a single MetroE feed to two switches, therefore I am using two vlans trunked over each provider connection. The main switches will see two equal-cost routes, so they should load balance the traffic through both routes (right?). I want to make sure that each route takes a different physical path so I need to control the root and blocking ports so that each vlan's traffic takes a different path. Adjusting the priority values to control which switch is the root, and thus which ports are blocking, should take care of this.
If I am using layer-3 for load balancing, I need to rely on layer-2 for redundancy. The MetroE path has all manner of devices and links between my sites, and unless the carrier gear directly connected to my switches fails, the only way I will see the failure is through Unidirectional Link Detection. If I enable aggressive mode UDLD on the MetroE ports, they should err-disable the port if I lose a connection and initiate a topology change.
Now how do we handle that topology change? Currently we run PVST+ so I can tune the forward-time to 2 sec and the max age to 5 sec in order to improve the convergence time, but we still have to transition through all the port states. I'm not worried about the additional traffic because I am pruning the MetroE vlans from my other trunks. Backbonefast would immediately enable forwarding on the 'backup' port as soon as it receives an inferior BPDU, by sending out root queries and setting the max-age timer to 0. The only problem is that Backbonefast must be enabled on all switches and I don't know how it will affect my other switches and vlans. If I move to RSTP, the network converges very quickly, but there is a lot of traffic during that stage, so I need to be careful about the network initiating a convergence unecessarily.
For any of you who have used these different Spanning-Tree configurations, what are your thoughts? If I have made any incorrect assumptions or descriptions please let me know - don't worry about hurting my feelings.
Comments
-
Options
darkuser
Member Posts: 620 ■■■□□□□□□□
rstp is actually the official incorporation of portfast, uplinkfast , and backbonefast
into one protocol.
it actually divides and logically seperates access ports and and transit links.
trunks are treated as point to point links.
and portfast is required to be configured on a access ports for it to work correctly.
so you can either run old stp and apply all the enhavcements
or properly configure rstp.
it is supposed to converge in miliseconds if properly configured.
I'm runnin rtsp on all switches that support it.
and i actually have some cat5000"s that still
http://www.cisco.com/warp/public/473/146.htmlrm -rf /