Spanning Tree issue

Discussion in 'Cisco' started by teton67, Nov 19, 2003.

  1. teton67

    teton67 Guest

    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.
     
    teton67, Nov 19, 2003
    #1
    1. Advertising

  2. teton67

    Andre Beck Guest

    "teton67" <> 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 <-
     
    Andre Beck, Nov 21, 2003
    #2
    1. Advertising

  3. 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.
     
    Andrey Tarasov, Nov 21, 2003
    #3
  4. teton67

    Andre Beck Guest

    "Andrey Tarasov" <> 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 <-
     
    Andre Beck, Nov 23, 2003
    #4
  5. 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.
     
    Andrey Tarasov, Nov 23, 2003
    #5
  6. teton67

    teton67 Guest

    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" <> wrote in message
    news:bpqqs3$1g5b$...
    > 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.
    >
     
    teton67, Nov 23, 2003
    #6
  7. teton67

    Andre Beck Guest

    "Andrey Tarasov" <> 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 <-
     
    Andre Beck, Nov 26, 2003
    #7
  8. 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=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=MPG.15
    54f2ec4c6d352c989707%40news-server.nyc.rr.com

    With best regards,
    Andrey.
     
    Andrey Tarasov, Nov 26, 2003
    #8
  9. teton67

    Andre Beck Guest

    Privjet Andrey,

    "Andrey Tarasov" <> 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=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&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 <-
     
    Andre Beck, Dec 7, 2003
    #9
  10. 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.
     
    Andrey Tarasov, Dec 8, 2003
    #10
  11. teton67

    Andre Beck Guest

    "Andrey Tarasov" <> writes:
    > 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.


    I expect I'm going to be able to sniff that to the bottom in an L1/L2
    class next month.

    > 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?


    In cases of the 3500XL and 3550, it appeared to be a physical knockout
    of the CPU after sum runtime. The box ist alive and kicking, but all of
    a sudden, it doesn't answer anything CPU-related (dead console, dead IP,
    dead STP). The ports and switching paths stay in exactly the same way
    they where before the CPU died. In case of the 6509, I had an incorrect
    confreg on the Supervisor (had "BREAK has effect" set), while the confreg
    on the MSFC2 was well. When the console port received a BREAK, the Sup
    went down to rommon, with the MSFC2 starting to cry about the watchdog
    not seeing the Sup anymore and finally following the Sup 120s later.
    At that time, the switch matrix seemed to continue to switch on the
    paths established before the brains gone to rommon consciouslessness...

    > 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 :)


    Sounds like a similar problem. It appears any modern switch architecture
    (consisting of a controlling CPU and an ASIC-based switch matrix) is to
    some extend sensitive to the CPU dropping out of service. I'd expect the
    designers to integrate some sort of "reverse watchdog" into the ASICs,
    one that lets them cease any operation if not constantly beaten upon the
    head by the CPU. It should be hardwired into the most basic operation
    protocols between the CPU and the ASICs IMO...

    --
    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 <-
     
    Andre Beck, Dec 27, 2003
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Amy L.
    Replies:
    0
    Views:
    2,446
    Amy L.
    Jul 24, 2003
  2. Sizwe Dumisani

    Spanning Tree

    Sizwe Dumisani, Nov 6, 2003, in forum: Cisco
    Replies:
    3
    Views:
    1,394
    username
    Nov 16, 2003
  3. Amy L.
    Replies:
    1
    Views:
    1,488
  4. wade
    Replies:
    0
    Views:
    1,149
  5. spanning tree issue

    , Sep 5, 2012, in forum: Cisco
    Replies:
    0
    Views:
    647
Loading...

Share This Page