04-29-2010 11:22 AM - edited 03-06-2019 10:52 AM
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
04-29-2010 11:24 AM
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
04-29-2010 11:33 AM
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?
04-29-2010 11:56 AM
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
04-29-2010 12:31 PM
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
04-29-2010 01:05 PM
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
04-29-2010 02:45 PM
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?
04-29-2010 03:04 PM
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
04-30-2010 11:39 AM
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?
04-30-2010 11:46 AM
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
04-30-2010 12:09 PM
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?
04-30-2010 12:16 PM
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
04-30-2010 12:50 PM
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."
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide