cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1533
Views
19
Helpful
12
Replies

Uplinkfast question

visitor68
Level 4
Level 4

Uplinkfast allows for fast failover to a redundant and blocked path in the event that the active and forwarding uplink fails. Simple.

But how does uplinkfast effect failover if he active and forwarding uplink is really a port channel with 4 uplinks? Lets say one of the 4 links fails, uplinkfast wont do anything, right? I never really thought about it....

Thanks

12 Replies 12

Jon Marshall
Hall of Fame
Hall of Fame

ex-engineer wrote:

Uplinkfast allows for fast failover to a redundant and blocked path in the event that the active and forwarding uplink fails. Simple.

But how does uplinkfast effect failover if he active and forwarding uplink is really a port channel with 4 uplinks? Lets say one of the 4 links fails, uplinkfast wont do anything, right? I never really thought about it....

Thanks

Joe

No it won't. Uplinkfast will kick in if the active path has failed and the redundant path needs activating. But if a single physical link with an etherchannel on the active link fails then it will not take that link down.

Jon

So configurung uplinkfast and backbonefast when youre using etherchannels is pointless then, right? Its funny, with all the reading Ive done with regard to uplinkfast and STP in general, this point has never ever been mentioned in any book. Maybe its always considered intuitive....

On the other hand, using loop guard and udld on the trunk ports, and of course portfast and bpduguard on the access ports, is still applicable, correct?

Joe

So configurung uplinkfast and backbonefast when youre using etherchannels is pointless then, right?

Not at all because each etherchannel is treated as one link by STP. So if you have an access-layer switch connected via etherchannels to 2 distro switches and one of the distro switches dies uplinkfast would still help in it failing over to the other distro switch.

Jon

True, but I guess its fair enough to say that it is less imperative when youre running ether channels.

How about the rest of my question....?

Thanks

Joe

On the other hand, using loop guard and udld on the trunk ports, and of course portfast and bpduguard on the access ports, is still applicable, correct?

Sorry should have answered that. You should deploy all of the above in the correct place and i'm not clear on how this relates to etherchannel directly. They are all applicable. Basically because STP sees etherchannel as a single link then there is no reason not to use all of the STP additional features where they are needed including on etherchannels if applicable.

Jon

Jon, I totally agree. I've never had a situation in which deploying uplinkfast or backbonefast was an issue.

I'm basically asking these questions because I just started a new engagement with a client whose architecture group prohibits the deployment of rapid STP...why, I have no idea. The switches in question are run of the mill, server farm access layer L2 switches that are trunked/dual-uplinked to 2 distro switches.....

What do you think could possibly be their reasoning for not using rapid STP?

ex-engineer wrote:

Jon, I totally agree. I've never had a situation in which deploying uplinkfast or backbonefast was an issue.

I'm basically asking these questions because I just started a new engagement with a client whose architecture group prohibits the deployment of rapid STP...why, I have no idea. The switches in question are run of the mill, server farm access layer L2 switches that are trunked/dual-uplinked to 2 distro switches.....

What do you think could possibly be their reasoning for not using rapid STP?

Joe

No idea. RSTP still supports per vlan STP and is a whole lot faster than standard 802.1d STP. If they are talking about running PVST+ rather than RSTP then it makes no sense to me honestly. You may have switches that don't support  RSTP but you can still run it on those switches that do and it is backwards compatible anyway.

If they are running MST then MST uses RSTP anyway.

I'd be interested to hear what their reasoning is for not deploying it as it is not exactly a "new", unstable feature.

Jon

Jon....

If I have a VTP domain configured at two different data centers - in other words, the switches at both sites belong to the same VTP domain, is there a problem with configuring rstp at one data center, but not the other?

The two data centers have the same VTP domain configured, but there is no L2 adjacency between the 2 sites. No vlan is spanned from one site to another.

So, it seems to me that configuring rstp at one site should have nothing to do with leaving the other site set for stp.

What do you think?

ex-engineer wrote:

Jon....

If I have a VTP domain configured at two different data centers - in other words, the switches at both sites belong to the same VTP domain, is there a problem with configuring rstp at one data center, but not the other?

The two data centers have the same VTP domain configured, but there is no L2 adjacency between the 2 sites. No vlan is spanned from one site to another.

So, it seems to me that configuring rstp at one site should have nothing to do with leaving the other site set for stp.

What do you think?

Joe

If there is no L2 adjacency between the 2 sites then they are completely separate in terms of VTP/STP etc. So yes using RSTP at one site will have absolutely no effect on the other site.

Jon

What if there IS L2 adjacency and there are vlans that are spanning across the 2 data centers? Wont rstp fall back to stp anyway

if it encounters a switch that is not using rstp?

ex-engineer wrote:

What is there IS L2 adjacency and there are vlans that are spanning across the 2 data centers? Wont rstp fall back to stp anyway

if it encounters a switch that is not using rstp?

If there is L2 adjacency but no vlans spanning the 2 data centres then rstp is used in site 1 and PVST+ is used in site 2. But if there is L2 adjacency then at least one vlan must span the 2 sites.

RSTP will only fall back to PVST+ timers if there is the same vlan(s) running on a switch enabled with RSTP and a switch with PVST+ enabled. That's why if you have a mixed network of RSTP/PVST+ it's very important if you want to get the full benefit of RSTP you only allow the vlans that have to be on the PVST+ enabled switch ie.

you have 10 vlans and 6 switches. All switches are connected via L2 trunks. 5 of the switches run RSTP and one (sw6)  runs PVST+. If you allow all 10 vlans on all 6 switches then all 6 vlans default to PVST+ timers. If however sw6 only needs one of the vlans eg. vlan 6 then you should limit the vlans allowed on the trunk link(s) to sw6 to be only vlan 6. Then vlans 1-5, 7 - 10 will use RSTP and only vlan 6 will fall back to PVST+.

Jon

yeah, all that makes sense.

And thats what my take is, too.

I finally got a chance to talk to the arch for hthis company...she is one of them, actually. She is a CCIE, but I think she is a little rusty. lol  Either that, or she doesnt know her own environment. As it turns out, the 2 sites are completely isolated. No L2 adj and no spanning vlans. L3 isolation all the way. Yet she says they are on the "same domain."

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: