Attention: The Community will be in read-only mode on 12/14/2017 from 12:00 am pacific to 11:30 am.
During this time you will only be able to see content. Other interactions such as posting, replying to questions, or marking content as helpful will be disabled for few hours.
We apologize for the inconvenience while we perform important updates to the Community.
Heres the scenario:
I have 2 L2 access switches dual homed to 2 distros.
Im running pvst+, uplinkfast, and backbonefast.
Timers are: 15 FDelay and 20 MAge
For a given vlan, all trunk ports on the access and distros are forwarding except for 1 on the distro. This is normal, of course.
When I fail one of the forwarding trunk links, it takes 30 sec to for that port to start forwarding. In other word, uplinkfast isnt doing anything.
Actually my post had a typo.. i wanted to know the root switch in your network.
Do you see a ALT/BLK port hen you do a sh spanning-tree vlan
OK, here goes:
distro 1 is the secondary for vlan 127 and distro 2 is primary for vlan 127
the primary forwarding path is access 1 to distro 2 to access 2.
all ports on all switches are forwarding EXCEPT for the port on distro1 that faces access 2.
In th eevent of a failure of the primary path, THAT port on distro 1 that faces access 2 must go into a forwarding state. It is that port that is taking 30 seconds to go to forwarding, as if uplinkfast is not on.
IF I use rapid-pvst instead, that port goes to forwarding immediately after the failure of the primary path.
Draw it on a piece of paper so you can visualize what Im writing.
I removed uplinkfast from the distros and left it only on the access -- still no good. That port on the distro, which is blocked under normal conditions, is going through the listening and learning stages (when I do a sh spannibg-tree vlan 127) AND TAKING 30 SECS TO GO FORWARD.
Ideally your dist switches should be configured as primary root switch and secondary root switch respectively for your vlans.
Uplinkfast should be enabled on th eaccess switches which would make one link as the alternate link i.e block which can be seen with the show command i provided earlier.
Sounds like Access_2 may be the root bridge for vlan 127. If it is why and can you make one of those distribution switches to be the root bridge for that vlan?
No, access 2 is not the root bridge.
distro 2 is the root bridge for vlan 127. i configured it as such. I rigged the election, if you will.
Heres something interesting, though. The blocked port on distro 1 goes to forwarding immediately when I use rapid-pvst. But, if I configure pvst, plus uplinkfast and backbonefast, that same port takes 30 seconds.
Another interesting thing is the following: Isn't it true that the "alternate" port role is a rapid-pvst port role? That blocked port on distro 2 has an "ALTN" designation when I do a 'sh spanning-tree vlan 127' command, yet I dont have rapid-pvst configured. I did at one point, but I removed it using the spanning-tree mode rapid-pvst' command.
Can you create a direction connection between the two distribution switches and advise what the outcome is?
Just want to reiterate what others stated before in this thread 'uplink fast' feature helps faster STP reconvergence in case of failure of primary uplink on Access switches. The key here is ACCESS switches. If you disconnect the primary uplink to distribution_2 from any one of the access switches then, with 'uplink fast' enabled on the access switch, the access switch should convert the blocked uplink port to distribution_1 as the primary uplink or root port.
When you enable uplinkfast, you will see an ALT/BLK port. what i do not understand is if the Distro 2 is the core switch it should not have any block ports for the vlan.
All ports of the root switch are in the forwarding state.
can you post the details of sh spanning-tree vlan 127
Ok i think i figured out what is the problem here.
To utilize uplikfast, several criteria must be met.
1. uplinkfast must be enabled on the switches
2. switch must have one blocked po rt
3. failure must be on the root port.
if failure is not on the root port Uplinkfast will ignore it and normal STP functions will occur.
In your case, the blocked port is in Dist1 and i think you are simulating a failure on Dist2.
Dist2 has all the ports already in the fwd state. Dist1 is ignoring uplinkfast as the failure is not on its root port.
try to simulate a failure on dist1 and see whether uplinkfast kicks in within 5 sec
HTH, rate if it does
Ok, there is a lot of confusion here because of the naming of the switches. It's not because you call two of your switches "distro" that they are distribution switches.
For vlan 127, your distribution 1 has connectivity to the root distro2 via access 1. If access1 is on the path between two distribution switches, I would consider access1 as part of the distribution.
In fact, with you configuration, I would say that access1, access2 and distro2 are the core, and distro1 is the only access switch.
You are right when you say that the roles displayed are RSTP information. In theory, there is no role in STP but we just display them because they are convenient and make also sense in an STP environment.
Uplinkfast is only able to back up a root port with an alternate port, as Narayan mentioned. It means that if you breaking the link between your (access;-) switch distro1 and your (core) access1, the alternate port on distro1 leading to access2 should go forwarding immediately. If you break any other link connected to distro2, you are in the backbone fast scenario and you will reconverge in 30 second (it would have been 50 second without backbone fast).
RSTP and MST, with their proposal/agreement mechanism, are able to recover the situation without relying on any timer, as you have observed.
So basically, everything that you are seing seems to make sense. Let me know if you really see a failure of uplinkfast and give additional details on what you are expecting if not.
Thanks and regards,
Can you justify the following so that I can understand it?
"If access1 is on the path between two distribution switches, I would consider access1 as part of the distribution.
In fact, with you configuration, I would say that access1, access2 and distro2 are the core, and distro1 is the only access switch."
Please make it idiot-proof. :-)
Also, on which switches should uplinkfast be configured?
It's entirely a question of terminology. You have some kind of layering from access to distribution and then core. An access switch gets its connectivity from distribution switches. Similarly, distributions can be directly connected together or through core switches. As soon as an access switch is providing connectivity to a distribution switch, it's not an access switch any more. Now, to give a more practical meaning to those terms, you can think in term of capacity for instance: a distribution switch aggregates the traffic from a large number of access bridges. The distribution switch thus needs to be more powerful than an access bridge. If you have an access switch between two distributions, it must be as powerful as the distributions in order to sustain the load (i.e. it is a distribution switch).
All the big simple rules like "uplinkfast needs to be enabled on access switch only" that you will read in the documentation assume that kind of hierarchy. Now, it does not matter at all for STP. And the way STP works does not depend at all on whether you think the bridge should be called access, core or albert. That's why that I described how STP would react only based on the topology, not on the names.
Uplinkfast is generally configured on access switches. The access switch is located at the edge of the network and blocks one of its uplink. Uplinkfast is the most efficient STP convergence scenario. That's why enterprise design tend to maximize this case. Keeping your initial terminology, you would need to have a direct link between the distro switches. Don't configure the distro for uplinkfast (just backbonefast). Configure uplinkfast on the access. By default, uplinkfast tunes the root priority and the cost of the links so that you will have a blocked port on both access1 and access2. The access bridge will thus be protected against a link failure of their uplink with uplinkfast (root port backed up by alternate). Your distribution (distro1-distro2) is not redundant. You could consider putting a channel between them.
Else, you can keep your initial cabling and just run RSTP or MST. Your network is a ring, it's not the hierarchical model where you have an access a distribution and a core, that's all (and that's very fine!).
I believe it's your intention is to make the two switches named distribution to be the collapsed core/distribution switches. All access switches would have a connection each to both switches. You need to have a direct connection between both core switches.
Core_2 is the root bridge for vlan 127. All ports on both core switches would be DP (designated ports) and the access switches would have the uplink to Core_2 in forwarding (root port) state. The uplink to Core_1 would be blocking (Alternate) port. If 'uplink fast' is enabled on the access switches on failure of primary uplink/root port to Core_2 the access switch would quickly convert the uplink/ALT port to Core_1 as the root port.
As Francois explained the access switch acts as a distribution switch in your case as the root port (path to root/Dist_2) for switch named Dist_1 is through one of your access switches. The reason for that is because you don't have a direct link between the two distribution switches. From the Dist_1 switch the link to the other Access switches act as ALT port.
"I would say that access1, access2 and distro2 are the core, and distro1 is the only access switch."
Correct me if I am wrong in his existing setup dist_2 is the root and the access switches are distribution switches and dist_1 is the access (actual) switch.
"Correct me if I am wrong in his existing setup dist_2 is the root and the access switches are distribution switches and dist_1 is the access (actual) switch."
This is also fine with me. But again, this terminology does not really matter in this small network anyway. It's a little bit as if we were arguing whether this army has 3 generals and a soldier or 1 general, 2 colonels and a soldier;-)
I guess if the 2 colonels claim to be general they may get fired. just kidding :-)
Anyway the setup Victor is trying to simulate is a very common setup in so many networks excepting that if he had direct connection between the two core switches he wouldn't have run into this problem at all as I explained in my last post.
With the current cabling, there is no hierarchy between the switches. All the bridges are on an equal footing. Sure the root tends to have an arbitrary advantage in term of ranking;-), but it's entirely artificial. That's why calling any of those switches access, distribution or core is difficult to justify.
Unless I read something wrong he does seem to have hierarchy there is no direct connections between the so-called access switches and they only connect to the switches named distribution.
OK, wait a second, folks. Please, allow me to clear something up.
The switches that I refer to as "access" switches are indeed access switches that have end-devices plugged into them. They are multi-vlan, L2 switches with L2 trunks uplinked to L3 switches -- what I refer to as "distros" -- that are performing inter-vlan routing and L3 packet filtering.
So, unless all of Cisco's literature regarding their architectural/hierarchical models is wrong, I think I can safely refer to the switches the way I have.
NOW, IF you are speaking stricly from an STP perspective, then yes, I can see what you mean when you want to designate them as being different, especially for the purposes of our discussion.
Anyway, I think I understand whats going on. To test my configurations, I was failing a link that is INDIRECT to the distro switch that had the blocked ALT port. So, uplinkfast could not remedy the problem. It was more of a backbonefast/INDIRECT link failure problem.
I am wondering, though, why RSTP forced that blocked port into a forwarding state immediately.
STP can move a designated port to forwarding in 2xforward_delay (ie 30 seconds). Instead of simply waiting for the timer to expire, RSTP sends a proposal to its neighbor. If the neighbor agrees to the topology, it answers with an agreement an the designated port can go forwarding immediately. In your scenario, depending on which indirect link fails, you end up with a designated blocking port leading to the "access" bridge that has lost its connection to the root bridge. When distro1 propose to this switch (who thinks it is the root), the access switch immediately update its root information and sends an agreement.