From: Rich (rmallory@xxxxxxxxxxxx)
Date: Sat Feb 23 2002 - 13:37:36 GMT-3
I agree and I believe the issue could also be caused by the time it takes to
update the CAM on the core switch. I see provisions in the uplinkfast
operation to update the neighboring switches CAM table when a link drops but
not when a link is restored. If the backup link goes back into blocking
state after the primary is restored there will be some time involved for the
core switch to update the CAM table.
I found this on CCO explaining uplinkfast:
"As soon as the switch transitions the alternate port to the forwarding
state, the switch begins transmitting dummy multicast frames on that port,
one for each entry in the local EARL table (except those entries associated
with the failed root port). By default, approximately 15 dummy multicast
frames are transmitted per 100 milliseconds.
Each dummy multicast frame uses the station address in the EARL table entry
as its source MAC address and a dummy multicast address (01-00-0C-CD-CD-CD)
as the destination MAC address.
Switches receiving these dummy multicast frames immediately update their
EARL table entries for each source MAC address to use the new port, allowing
the switches to begin using the new path almost immediately.
If connectivity on the original root port is restored, the switch waits for
a period equal to twice the forward delay time plus 5 seconds before
transitioning the port to the forwarding state. This wait allows the
neighbor port time to transition through the listening and learning states
to the forwarding state."
Rich
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Bob Sinclair
Sent: Saturday, February 23, 2002 10:08 AM
To: ccielab@groupstudy.com
Subject: Fw: Uplinkfast issues
Annu,
The 30 seconds is caused by the STP forward delay timer. The timer is 15
seconds by default, and it is used once as STP goes through listening state
and again as STP goes through learning state. No way to avoid this that I
know of. You can speed up the process by getting aggressive with the
forward delay timer for each vlan.
>From what I understand of your setup, you could use the Spantree root macro
with a diameter of 3 to automatically set a more aggressive forward delay.
I would definitely suggest testing first, and also close study of Kennedy
Clark's Cisco LAN Switching book.
-Bob
----- Original Message -----
From: "Annu Roopa" <annu_roopa@yahoo.com>
To: "John Mistichelli" <jmistichelli@yahoo.com>
Cc: <ccielab@groupstudy.com>
Sent: Saturday, February 23, 2002 8:46 AM
Subject: RE: Uplinkfast issues
> John,
> Thanks for replying.here is how its connected.Let me
> try textual explanation.
>
> 1.Access layer switch is where hosts are.
> 2.Uplink fast on the access layer switch.
> 3.The connection to 6509 is layer 2 without
> channeling.
> 4. Access layer connected to 2 core switches which
> have the CSM( load balancing blade in 6509).
> 5. Link to left switch fails (this is Spantree Root
> now).
> 6. Due to UPlinkfast the Right core switch becomes
> Root.
> 7.When link comes back up agian the Root flips to left
> core switch and we loose flows for around 20 seconds.
>
> hope this helps.thanks in advance for ur answers.
> Bye
> Annu
>
>
> --- John Mistichelli <jmistichelli@yahoo.com> wrote:
> > I am not sure we have a clear picture of how you
> > are wired. Is Uplinkfast configured on the switch
> > you expect to be the root bridge (and backup to the
> > root)? If so, its not designed for that. Uplinkfast
> > is for access layer switches.
> > John
> > Rich <rmallory@enteract.com> wrote: Question(s):
> >
> > Are the uplinks from the closet switches single
> > connections to the 2 core
> > switches or are you using Etherchannel on the
> > uplinks to each core switch?
> > How many VLAN's are being used in the closet switch?
> > Are the root bridges
> > for the VLAN's placed on the core switches to enable
> > spanning tree load
> > balancing? If not, which core is root for the VLAN
> > you are testing from, and
> > does it matter which of the links drops? In other
> > words does the problem
> > occur if the link which comes back up is connected
> > to the root bridge?
> >
> > Thanks,
> >
> > Rich
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com
> > [mailto:nobody@groupstudy.com]On Behalf Of
> > Annu Roopa
> > Sent: Friday, February 22, 2002 2:10 PM
> > To:
> > Cc: annu_roopa@yahoo.com
> > Subject: OT:Uplinkfast issues
> >
> >
> > Group,
> >
> > I have a issue with one of the setups hopefully
> > someone has come across this or has some ideas ?
> >
> > My setup is as follows:
> >
> > Firewall1 Firewall2
> > | |
> > | |
> > Cat6509(with CSM) Cat6509 (with CSM)
> > Primary Backup
> > | |
> > | <--Uplinkfast -->| Layer2
> > ---- ----- conn
> > | |
> > |----------|
> > | Switch |
> > ============
> > PC Hosts
> >
> > My issue is when link to Cat6509 which is primary
> > (with CSM blade) fails the Uplinkfast fails over to
> > secondary and traffic goes thru Backup Cat6509 and
> > goes well.
> >
> > The PROBLEM IS WHEN THE LINK TO OLD PRIMARY comes
> > back...upkink fast takes around 30 seconds and
> > meanwhile traffic in terms of flows is lost.
> >
> > Is there a way to speed up this process in any way ?
> >
> > Let me know the connection between access switch and
> > Cat6509 is Layer 2 and cannot be Layer 3 connection
> > as
> > per requirements.
> >
> > Thanks in advance for ur answers.
> > Annu
> >
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 13:46:31 GMT-3