From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Thu Jan 08 2004 - 15:58:45 GMT-3
At 12:58 PM -0500 1/8/04, Bob Sinclair wrote:
>Paul,
>
>I just labbed up the Uplinkfast and rapid-pvst approaches on 3 3550s to
>verify the performance we talked about earlier. I found that Uplinkfast by
>itself now gives rapid fail-back, without the need to go all the way to
>rapid-pvst mode.
>
>The rapid-pvst+ worked great in both directions - missed just a ping or two.
>But uplinkfast by itself gave about the same performance, and I believe this
>is a change. When the access switch tried to fail-back to the original root
>port, it held the original root port in blocking throughout the normal
>listening and learning phases. It then quickly shut the backup root and put
>the original root in forwarding, so I only lost a ping or two.
>
>This is not your grandfather's uplinkfast! It used to close the backup
>root and then wait for the original to go through listening and learning.
>Perhaps an enhancement that came with rapid-pvst capabilities?
>
>Bottom line - if you have the perfect access-distribution-distribution
>triangle and you can use uplinkfast on the access switch, you should get
>very fast fail-back as well as fail-over on recent Cisco switches.
Bob, do you know if the configuration you found and liked is the one
that's supposed to be fully interoperable with the IEEE Rapid
Spanning Tree, or was it still Cisco proprietary?
>
>
>Bob Sinclair
>CCIE #10427, CISSP, MCSE
>www.netmasterclass.net
>
>----- Original Message -----
>From: "paul" <paul_hwang@hanmail.net>
>To: "Bob Sinclair" <bsinclair@netmasterclass.net>
>Cc: <ccielab@groupstudy.com>
>Sent: Thursday, January 08, 2004 12:36 PM
>Subject: [RE]Re: hsrp and stp (how to avoid second outage)
>
>
>> Hi Bob,
>>
>> Thanks for clear explanation.
>>
>> Anyone deployed the rapid-PVST+ in production, how about this stability
>> compared with the PVST+. Any bad experience?
>>
>> Cheers,
>>
>> Paul.
>>
>> ---------[ 9^@: 8^@O 3;?k ]----------
>> A&8q : Re: hsrp and stp (how to avoid second outage)
>> 3/B% : Thu, 8 Jan 2004 11:51:21 -0500
>> :83=@L : "Bob Sinclair" <bsinclair@netmasterclass.net>
>> 9^4B@L : "paul" <paul_hwang@hanmail.net>, <ccielab@groupstudy.com>
>>
>> Paul,
>>
>> AFAIK, there is no comparable "preempt/no preempt" feature int STP.
>> Of
>> course, you could manally raise the priority of the old root bridge
>> before
>> restoring it if the outage scenario allows (an IOS upgrade, for
>> example).
>>
>> You are right to be concerned about the "fail-back" delay. If you run
>> Uplinkfast on your access switches, for example, then you will get
>> 1-2
>> second failover to the new root port if the root bridge fails. But
>> when the
>> root bridge comes back you will have a 30-second outage as the active
>> root
>> port immediately closes and the new root port goes through listening
>> and
>> learning.
>>
>> You could speed this up by tweaking the timers, or you could consider
>> rapid-pvst+ if all your switches support it.
>>
>> Bob Sinclair
>> CCIE #10427, CISSP, MCSE
>> www.netmasterclass.net
>>
>> ----- Original Message -----
>> From: "paul"
>> To:
>> Sent: Thursday, January 08, 2004 10:52 AM
>> Subject: hsrp and stp (how to avoid second outage)
>>
>> > HI all,
>> >
>> > Assuming that configured the HSRP and STP on the active and standby
>> > distribution switches.
>> >
>> > In case of HSRP, we can use the preemt option to return to the
>> original
>> > primary switch once the primary switch recovered. That is, without
>> the
>> > preemp option, secondary switch keeps active continually after the
>> > primary fails.
>> >
>> > Wondering how about the STP.
>> >
>> > I configured the PVST+ between Cat6500 and Cat4000 switches.
>> >
>> > If the root bridge fails, secondary root bridge will take over to
>> active.
>> >
>> > And then, what happen after the original primary swith recovered. I
>> > understand the original primary switch will regain the root bridge.
> > That
>> > is, it will bring sencond outage as the HSRP preempt option do.
>> Then how
>> > can configure the switch so the secondary root bridge keeps the
>> active
> > > though the original primary returned.
This archive was generated by hypermail 2.1.4 : Mon Feb 02 2004 - 09:07:38 GMT-3