Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Cisco > Spanning Tree issue

Reply
Thread Tools

Spanning Tree issue

 
 
teton67
Guest
Posts: n/a
 
      11-19-2003
I have a data center LAN with two Hybrid mode 6509's with MSFC's at the core
and a series of 2950 T switches set up as access layer switches. The 2950's
have links back to both of the 6509's. I have uplinkfast configured on all
of the 2950's. When I did maintenance on the 6509's and took down the
primary switch, which is root bridge for all VLAN's the The other 6509
configured as backup root bridge for all VLANS took over and I lost only a
couple of pings. When I brought the primary switch back up after the
maintenance was complete it appears that the 2950's started forwarding on
the primary link and blocked the backup link before the primary switch had
started to forward on any ports. The result of this behavior was that I had
a 90 second outage rather than the 10 to 30 second outage I anticipated. Is
there any work around for this?
thanks for any insight you all might have on this.


 
Reply With Quote
 
 
 
 
Andre Beck
Guest
Posts: n/a
 
      11-21-2003
"teton67" <(E-Mail Removed)> writes:
>
> I have a data center LAN with two Hybrid mode 6509's with MSFC's at the core
> and a series of 2950 T switches set up as access layer switches. The 2950's
> have links back to both of the 6509's. I have uplinkfast configured on all
> of the 2950's. When I did maintenance on the 6509's and took down the
> primary switch, which is root bridge for all VLAN's the The other 6509
> configured as backup root bridge for all VLANS took over and I lost only a
> couple of pings. When I brought the primary switch back up after the
> maintenance was complete it appears that the 2950's started forwarding on
> the primary link and blocked the backup link before the primary switch had
> started to forward on any ports. The result of this behavior was that I had
> a 90 second outage rather than the 10 to 30 second outage I anticipated. Is
> there any work around for this?


I've never touched uplinkfast/backbonefast as they give me a bad feeling.
That's probably also due to their strange documentation, which explains
to you a lot of tech details with inserted warnings, but doesn't really
give you practical advise. As the only location to really test this stuff
are large enterprise networks and I refuse to "just try" such things in
a customer network, I've never come about to activate one of these.

My advice would be to rather upgrade the whole cloud to rapid STP. I'm
not sure with the hybrid IOS (integrated IOS will work), but I expect
you can migrate all of your switches to "Rapid PVST+", which (in a pure
Cisco cloud) gives you both very fast reconfiguration (typically you
lose either one ping or none, in other words, the stuff reconverges in
less than a second) and convenient automatic per VLAN spanning trees.
Another advantage of RSTP is that you can get rid of the dangerous
"spanning-tree portfast" as well (including all the security hacks that
are just there to make it less so). While it takes a bit longer to de-
block against a typical host than against a bridge (a host will not send
any BPDUs so the algorithms go through some guesswork until they decide
the port is not leading to any bridge), the time seems to be <= 4s
approximately. In a majority of cases, this should be sufficient.

--
The _S_anta _C_laus _O_peration
or "how to turn a complete illusion into a neverending money source"

-> Andre "ABPSoft" Beck +++ ABP-RIPE +++ Dresden, Germany, Spacetime <-
 
Reply With Quote
 
 
 
 
Andrey Tarasov
Guest
Posts: n/a
 
      11-21-2003
Hello, Andre!
You wrote on 21 Nov 2003 17:21:34 +0100:

AB> I've never touched uplinkfast/backbonefast as they give me a bad
AB> feeling.
AB> That's probably also due to their strange documentation, which explains
AB> to you a lot of tech details with inserted warnings, but doesn't really
AB> give you practical advise. As the only location to really test this
AB> stuff are large enterprise networks and I refuse to "just try" such
AB> things in a customer network, I've never come about to activate one of
AB> these.

There is no black magic here Uplinkfast deals with direct failure of the
link from leaf switch to the core and backbonefast deals with indirect failures
somewhere in the LAN. Both were incorporated into Rapid STP.

AB> My advice would be to rather upgrade the whole cloud to rapid STP. I'm
AB> not sure with the hybrid IOS (integrated IOS will work), but I expect
AB> you can migrate all of your switches to "Rapid PVST+", which (in a pure
AB> Cisco cloud) gives you both very fast reconfiguration (typically you
AB> lose either one ping or none, in other words, the stuff reconverges in
AB> less than a second) and convenient automatic per VLAN spanning trees.
AB> Another advantage of RSTP is that you can get rid of the dangerous
AB> "spanning-tree portfast" as well (including all the security hacks that
AB> are just there to make it less so).

spanning-tree portfast is required command in Cisco's RSTP implementation to
define edge ports. Behavior was changed so unlike PortFast, an edge port that
receives a BPDU immediately loses its edge port status and becomes a normal
spanning tree port.

The problem with not using spanning-tree portfast is that when port will change
it state it will trigger topology change notification thus causing excessive
flooding.

With best regards,
Andrey.

 
Reply With Quote
 
Andre Beck
Guest
Posts: n/a
 
      11-23-2003
"Andrey Tarasov" <(E-Mail Removed)> writes:
> Hello, Andre!
> You wrote on 21 Nov 2003 17:21:34 +0100:
>
> AB> I've never touched uplinkfast/backbonefast as they give me a bad
> AB> feeling.
> AB> That's probably also due to their strange documentation, which explains
> AB> to you a lot of tech details with inserted warnings, but doesn't really
> AB> give you practical advise. As the only location to really test this
> AB> stuff are large enterprise networks and I refuse to "just try" such
> AB> things in a customer network, I've never come about to activate one of
> AB> these.
>
> There is no black magic here


I hoped so, but more or less proprietary modifications to STP always gave
me the creeps. I've just seen some of these go boom in inter vendor land.

> Uplinkfast deals with direct failure of the
> link from leaf switch to the core and backbonefast deals with indirect
> failures somewhere in the LAN.


That's what I understood about them, too. But the details, and the impli-
cations of these in a multivendor cloud - it's hard enough to marry the
new 802.1t style of bridge root priorities with the good old DEC imple-
mentation that uses just 8 bits for the priority (thanks to strange luck
all the setups I've deployed in such environments so far came out with
the intended order of root and fallback root just by the MACs, using a
priority of 0).

> Both were incorporated into Rapid STP.


But together with a set of other changes that makes the whole thing more
reliable, including a standby path concept and especially a full set of
rules of how the whole thing has to interoperate towards 802.1D edges.
That (and the IEEE brand sign) makes me feel less disturbed about it

> AB> My advice would be to rather upgrade the whole cloud to rapid STP. I'm
> AB> not sure with the hybrid IOS (integrated IOS will work), but I expect
> AB> you can migrate all of your switches to "Rapid PVST+", which (in a pure
> AB> Cisco cloud) gives you both very fast reconfiguration (typically you
> AB> lose either one ping or none, in other words, the stuff reconverges in
> AB> less than a second) and convenient automatic per VLAN spanning trees.
> AB> Another advantage of RSTP is that you can get rid of the dangerous
> AB> "spanning-tree portfast" as well (including all the security hacks that
> AB> are just there to make it less so).
>
> spanning-tree portfast is required command in Cisco's RSTP implementation to
> define edge ports. Behavior was changed so unlike PortFast, an edge port that
> receives a BPDU immediately loses its edge port status and becomes a normal
> spanning tree port.


Highly interesting. But I'd like to bash Cisco a bit about this for reusing
portfast in a non-intuitive way. I'll have to reread this, though, maybe
it's not as non-intuitive as it seems.

> The problem with not using spanning-tree portfast is that when port will change
> it state it will trigger topology change notification thus causing excessive
> flooding.


So far I was under the impression that RSTP can deal with that in a rather
relaxed way. But I'll reread that stuff instead of just extrapolating from
other hardware to Cisco gear.

Thanks for the insight,
Andre.
--
The _S_anta _C_laus _O_peration
or "how to turn a complete illusion into a neverending money source"

-> Andre "ABPSoft" Beck +++ ABP-RIPE +++ Dresden, Germany, Spacetime <-
 
Reply With Quote
 
Andrey Tarasov
Guest
Posts: n/a
 
      11-23-2003
Hello, Andre!
You wrote on 23 Nov 2003 14:35:47 +0100:

>> Uplinkfast deals with direct failure of the link from leaf
>> switch to the core and backbonefast deals with indirect
>> failures somewhere in the LAN.


AB> That's what I understood about them, too. But the details, and
AB> the implications of these in a multivendor cloud -

I believe there much more things in multivendor environment to worry about first
than STP tuning

AB> it's hard enough to marry the new 802.1t style of bridge root priorities
AB> with the good old DEC implementation that uses just 8 bits for the
AB> priority (thanks to strange luck all the setups I've deployed in such
AB> environments so far came out with the intended order of root and
AB> fallback root just by the MACs, using a priority of 0).

I was under impression that DEC and IEEE STP implementations are not compatible.
May be you are talking about 802.1t vs. 802.1D implementation? In this case
priorities are still compatible. The only difference is that in 802.1D you can
choose priority with granularity 1, thus 65536 values, when in 802.1t
implementation granularity is 4096 which gives 16 values. But if you using
default Cisco values - 32768 by default, 8192 for primary root and 16384 for
secondary - you wouldn't even notice the difference.

BTW, do you know what will happen, if somebody will plug something ancient like
AGS/AGS+ with enabled bridging in one of the deployments you done?

>> Both were incorporated into Rapid STP.


AB> But together with a set of other changes that makes the whole
AB> thing more reliable, including a standby path concept and
AB> especially a full set of rules of how the whole thing has to
AB> interoperate towards 802.1D edges.

What is the uplinkfast if not a standby path concept?

With best regards,
Andrey.

 
Reply With Quote
 
teton67
Guest
Posts: n/a
 
      11-23-2003
Thanks to you both Andrey and Andre,
I think for now I will allways schedule my maintenance in windows where a
90second outage will not impact production. The uplinkfast feature works
greeat for the leaf nodes, but the new root bridge dillemma when you bring a
downed root bridge back up from maintenance doesn't appear to be handled. I
will investicbate RSTP but I suspect the fact that I have a number of XL
series switches in the enviornment will prevent me from utilizing this
feature.

"Andrey Tarasov" <(E-Mail Removed)> wrote in message
news:bpqqs3$1g5b$(E-Mail Removed)...
> Hello, Andre!
> You wrote on 23 Nov 2003 14:35:47 +0100:
>
> >> Uplinkfast deals with direct failure of the link from leaf
> >> switch to the core and backbonefast deals with indirect
> >> failures somewhere in the LAN.

>
> AB> That's what I understood about them, too. But the details, and
> AB> the implications of these in a multivendor cloud -
>
> I believe there much more things in multivendor environment to worry about

first
> than STP tuning
>
> AB> it's hard enough to marry the new 802.1t style of bridge root

priorities
> AB> with the good old DEC implementation that uses just 8 bits for the
> AB> priority (thanks to strange luck all the setups I've deployed in such
> AB> environments so far came out with the intended order of root and
> AB> fallback root just by the MACs, using a priority of 0).
>
> I was under impression that DEC and IEEE STP implementations are not

compatible.
> May be you are talking about 802.1t vs. 802.1D implementation? In this

case
> priorities are still compatible. The only difference is that in 802.1D you

can
> choose priority with granularity 1, thus 65536 values, when in 802.1t
> implementation granularity is 4096 which gives 16 values. But if you using
> default Cisco values - 32768 by default, 8192 for primary root and 16384

for
> secondary - you wouldn't even notice the difference.
>
> BTW, do you know what will happen, if somebody will plug something ancient

like
> AGS/AGS+ with enabled bridging in one of the deployments you done?
>
> >> Both were incorporated into Rapid STP.

>
> AB> But together with a set of other changes that makes the whole
> AB> thing more reliable, including a standby path concept and
> AB> especially a full set of rules of how the whole thing has to
> AB> interoperate towards 802.1D edges.
>
> What is the uplinkfast if not a standby path concept?
>
> With best regards,
> Andrey.
>



 
Reply With Quote
 
Andre Beck
Guest
Posts: n/a
 
      11-26-2003
"Andrey Tarasov" <(E-Mail Removed)> writes:
> Hello, Andre!
> You wrote on 23 Nov 2003 14:35:47 +0100:
>
> AB> That's what I understood about them, too. But the details, and
> AB> the implications of these in a multivendor cloud -
>
> I believe there much more things in multivendor environment to worry about first
> than STP tuning


Well, I don't even remotely know all possible multivendor environments
(I had the luck to never actually touch either SNA or IPX, for instance),
but in those where I had to deploy new hardware, STP was one of the primary
source for headaches. The problem with STP is essentially that nobody
notices it's there because it simply works - until it goes boom. Most
traditional networks (that I contact with) are centered around a shared
medium and bridge to local segments from there (to name it, an FDDI ring
with Bridges to Ethernets). In such a setup, choice of the root bridge
is not a real concern, and thus it was simply bypassed. When deploying
a new core switch, it suddenly becomes really necessary to do this one
thing correct - and that can mean you have to correct the complete
existing cloud first. If you can...

And BTW, it didn't become that much better with RSTP in multivendor:
The path costs where hardly converging to the new IEEE ones with 802.1D
in the last year or such, with still some vendors not getting it right
(and while you can fix it on most platforms, how do you fix a path cost
on an speed autosensing port) - now the same thing starts over with RSTP.
Cisco reuses the IEEE values and thus stays compatible with 802.1D, but
makes no use of the new flexibility. HP chooses a complete new set of
values. Others not seen yet...

> AB> it's hard enough to marry the new 802.1t style of bridge root priorities
> AB> with the good old DEC implementation that uses just 8 bits for the
> AB> priority (thanks to strange luck all the setups I've deployed in such
> AB> environments so far came out with the intended order of root and
> AB> fallback root just by the MACs, using a priority of 0).
>
> I was under impression that DEC and IEEE STP implementations are not compatible.
> May be you are talking about 802.1t vs. 802.1D implementation? In this case
> priorities are still compatible.


I have a number of networks where older DEC equipment is deployed that
allows priority to be adjusted only from 0..255 with a default of 128.
Path costs may actually fit or are at least configurable, and the boxes
behave properly in a 802.1D cloud. But try to undervote a root priority
of 128 with 802.1t extensions - there's only one value left (0) and you
should make sure the VLANs that touch these broadcast domains have an ID
below 128.

> The only difference is that in 802.1D you can
> choose priority with granularity 1, thus 65536 values, when in 802.1t
> implementation granularity is 4096 which gives 16 values.


Exactly.

> But if you using
> default Cisco values - 32768 by default, 8192 for primary root and 16384 for
> secondary - you wouldn't even notice the difference.


The 32768 is the IEEE default anyway. I've never used the statements
Cisco provides to set the priorities for (backup) roots, mainly because
I was used to set them manually anyway - and I prefered values like 32
and 64. From the above, you know why - I didn't want an old PEswitch900
out there at the periphery of the net to become root.

> BTW, do you know what will happen, if somebody will plug something ancient like
> AGS/AGS+ with enabled bridging in one of the deployments you done?


That somebody gets a nice head wash

I don't know these boxes (besides from threads here that deal with nostalgia),
what will happen? The MAC will probably not be lower than that of the
current switches, as Cisco started out with a 08-00-something and newer
switches are numbered from a new space starting 00-something.

> AB> But together with a set of other changes that makes the whole
> AB> thing more reliable, including a standby path concept and
> AB> especially a full set of rules of how the whole thing has to
> AB> interoperate towards 802.1D edges.
>
> What is the uplinkfast if not a standby path concept?


Of course it is one - but wasn't that made a bit more universal and rounded
up properly with RSTP? But anyway, after rereading RSTP I will give the
docs for Uplink-/Backbonefast another chance. Maybe they get clearer then
(after reading an 802.x spec usually anything else reads clearer

--
The _S_anta _C_laus _O_peration
or "how to turn a complete illusion into a neverending money source"

-> Andre "ABPSoft" Beck +++ ABP-RIPE +++ Dresden, Germany, Spacetime <-
 
Reply With Quote
 
Andrey Tarasov
Guest
Posts: n/a
 
      11-26-2003
Hello, Andre!
You wrote on 26 Nov 2003 21:47:41 +0100:

AB> I have a number of networks where older DEC equipment is
AB> deployed that allows priority to be adjusted only from 0..255
AB> with a default of 128.
AB> Path costs may actually fit or are at least configurable, and
AB> the boxes behave properly in a 802.1D cloud. But try to
AB> undervote a root priority of 128 with 802.1t extensions -
AB> there's only one value left (0) and you should make sure the
AB> VLANs that touch these broadcast domains have an ID below 128.

How does BridgeID than look like? If DEC has one byte for priority and IEEE - 2
bytes... 7 vs. 8 - we are one byte short.

>> BTW, do you know what will happen, if somebody will plug
>> something ancient like
>> AGS/AGS+ with enabled bridging in one of the deployments you
>> done?


AB> That somebody gets a nice head wash

AB> I don't know these boxes (besides from threads here that deal
AB> with nostalgia), what will happen? The MAC will probably not
AB> be lower than that of the current switches, as Cisco started
AB> out with a 08-00-something and newer switches are numbered
AB> from a new space starting 00-something.

Surprise! It starts with 00:00:0C. I was trying to find out why I remember this
thing and finally I came up with the right set of keywords Here is URL

http://groups.google.com/groups?hl=e...ff&selm=MPG.15
54f2ec4c6d352c989707%40news-server.nyc.rr.com

With best regards,
Andrey.

 
Reply With Quote
 
Andre Beck
Guest
Posts: n/a
 
      12-07-2003
Privjet Andrey,

"Andrey Tarasov" <(E-Mail Removed)> writes:
> Hello, Andre!
> You wrote on 26 Nov 2003 21:47:41 +0100:
>
> AB> I have a number of networks where older DEC equipment is
> AB> deployed that allows priority to be adjusted only from 0..255
> AB> with a default of 128.
> AB> Path costs may actually fit or are at least configurable, and
> AB> the boxes behave properly in a 802.1D cloud. But try to
> AB> undervote a root priority of 128 with 802.1t extensions -
> AB> there's only one value left (0) and you should make sure the
> AB> VLANs that touch these broadcast domains have an ID below 128.
>
> How does BridgeID than look like? If DEC has one byte for priority and IEEE - 2
> bytes... 7 vs. 8 - we are one byte short.


I'll have a sniff as soon as I'm on location or reactivate such device in
the lab or a class. This is getting me nervous. I so far assumed that they
would just send a interoperable STP with that Byte in the lower octett of
the 16bit root priority field of the bridge ID, filling the upper eight
bits with zeros. But maybe they do something completely different and
other, newer Digital Networks components (VNswitch etc) just speak both
protocols and do a sort of transliteration. As the new core switch likely
never connects directly to such ancient device but rather through a newer
switch like a VN900CG, maybe that transliteration integrates the old
device towards the new core. But I'll clarify this with a sniffer ASAP.
Maybe they even plug the byte to the *upper* 8bit and all is well...

BTW, those ancient or at least old boxes may have had their specialties,
but at least they never broke in a way that I've now seen with several
different Cisco gear from 35xxXL through 3550 to 6509: The CPU dies and
thus STP ceases, but the lower switch functions stay alive. The result
should be obvious...

> >> BTW, do you know what will happen, if somebody will plug
> >> something ancient like
> >> AGS/AGS+ with enabled bridging in one of the deployments you
> >> done?

>
> AB> That somebody gets a nice head wash
>
> AB> I don't know these boxes (besides from threads here that deal
> AB> with nostalgia), what will happen? The MAC will probably not
> AB> be lower than that of the current switches, as Cisco started
> AB> out with a 08-00-something and newer switches are numbered
> AB> from a new space starting 00-something.
>
> Surprise! It starts with 00:00:0C.


Ough. How our memories can betray us...

> I was trying to find out why I remember this
> thing and finally I came up with the right set of keywords Here is URL
>
> http://groups.google.com/groups?hl=e...ff&selm=MPG.15
> 54f2ec4c6d352c989707%40news-server.nyc.rr.com


In classes, I'm also giving the explanation that according to murphy,
usually the most peripheral and oldest bridge will have the lowest
MAC and thus will get root. This isn't really true anymore as most
vendors are no longer using their first IEEE OUI assignments and the
newer ones tend to be smaller (I wonder whether that is pure coincidence
or actually intentional). But that 00:00:0c is likely to spoil it all

--
The _S_anta _C_laus _O_peration
or "how to turn a complete illusion into a neverending money source"

-> Andre "ABPSoft" Beck +++ ABP-RIPE +++ Dresden, Germany, Spacetime <-
 
Reply With Quote
 
Andrey Tarasov
Guest
Posts: n/a
 
      12-08-2003
Hallo, Andre!
You wrote on 07 Dec 2003 16:17:43 +0100:

>> How does BridgeID than look like? If DEC has one byte for
>> priority and IEEE - 2 bytes... 7 vs. 8 - we are one byte short.


AB> I'll have a sniff as soon as I'm on location or reactivate
AB> such device in the lab or a class.

I'll really appreciate if you will post your findings.

AB> BTW, those ancient or at least old boxes may have had their
AB> specialties, but at least they never broke in a way that I've
AB> now seen with several different Cisco gear from 35xxXL through
AB> 3550 to 6509: The CPU dies and thus STP ceases, but the lower
AB> switch functions stay alive. The result should be obvious...

Do you mean that CPU physically dies or just hit 100% utilization? I recently
had very unpleasant experience with WS-X6408 which didn't died completely but
merely ceased to receive any frames. Considering the fact that we've had 6 floor
switches connected to this blade I learned value of having UDLD configured on
inter-switch ports in a hard way

Mit freundlichen Gruß,
Andrey.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
spanning tree issue brumiku@gmail.com Cisco 0 09-04-2012 11:12 PM
Gigastack, Spanning Tree, And Trunk Links Amy L. Cisco 1 12-06-2003 12:31 AM
Spanning Tree Sizwe Dumisani Cisco 3 11-16-2003 02:33 AM
B tree, B+ tree and B* tree Stub C Programming 3 11-12-2003 01:51 PM
Spanning Tree And Per Vlan Spanning Tree Amy L. Cisco 0 07-24-2003 10:01 PM



Advertisments