Uplinkfast question

Unanswered Question
Apr 29th, 2010
User Badges:

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.8 (4 ratings)
Loading.
Jon Marshall Thu, 04/29/2010 - 11:24
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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

ex-engineer Thu, 04/29/2010 - 11:33
User Badges:

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?

Jon Marshall Thu, 04/29/2010 - 11:56
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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

ex-engineer Thu, 04/29/2010 - 12:31
User Badges:

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

Jon Marshall Thu, 04/29/2010 - 13:05
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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

ex-engineer Thu, 04/29/2010 - 14:45
User Badges:

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?

Jon Marshall Thu, 04/29/2010 - 15:04
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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

ex-engineer Fri, 04/30/2010 - 11:39
User Badges:

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?

Jon Marshall Fri, 04/30/2010 - 11:46
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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

ex-engineer Fri, 04/30/2010 - 12:09
User Badges:

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?

Jon Marshall Fri, 04/30/2010 - 12:16
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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

ex-engineer Fri, 04/30/2010 - 12:50
User Badges:

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."

Actions

This Discussion