[f-nsp] Spanning tree on brocade

[Eldon Koyle]

That is _really_ old code on the turboiron.  It may be the version they
shipped with, which was extremely buggy.  You are correct that it is
routing code (TIR is routing, TIS is switching).  Are you doing any routing
on that device?

-- 
Eldon
On May 18, 2016 6:48 AM, "Nick Cutting" <ncutting at edgetg.com> wrote:

> I think its routing code:
>
>
>
> Remote switches using FDP show it as a router and I have:
>
>
>
> telnet at Turbo4 (config)#router ?
>
>   bgp             Enable bgp
>
>   msdp            Enable msdp
>
>   ospf            Enable ospf
>
>   pim             Enable pim
>
>   rip             Enable rip
>
>   vrrp            Enable vrrp
>
>   vrrp-extended   Enable vrrp-extended
>
>   vsrp            Enable vsrp
>
>
>
> sh ver
>
>   SW: Version 04.2.00c Copyright (c) 1996-2010 Brocade Communications
> Systems, Inc.
>
>       Compiled on Jan 12 2011 at 19:46:00 labeled as TIR04200c
>
>       (5473051 bytes) from Primary TIR04200c.bin
>
>       Compressed Boot-Monitor Image size = 373767, Version:04.1.00T205
> (grz04100)
>
>
>
>
>
> As you all can probably guess – we had a bit of a spanning tree meltdown.
> I am trying to figure out what happened.
>
> I get plenty of incorrect costs, and it is stable now and am trying to
> figure out what happened, what may have caused this.
>
>
>
> I know we need to enable 802-1w everywhere and move the root bridges, but
> right now I’m in the audit phase and am trying to understand what happened.
>
> The port-level spanning tree – when not running any form of spanning tree
> – does this forward unmodified BPDUs (i.e a cost of 0 as stated)
>
>
>
> “STP configured to ON, priority is level0”
>
>
>
> I cannot find what this does in any brocade documentation .
>
>
>
> Also – any Ideas why a trunk does not lower the cost of the link? Or get
> treated as an aggregated link by STP?
>
>
>
>
>
>
>
> *From:* ekoyle at gmail.com [mailto:ekoyle at gmail.com] *On Behalf Of *Eldon
> Koyle
> *Sent:* Wednesday, May 18, 2016 2:03 AM
> *To:* Nick Cutting
> *Cc:* foundry-nsp
> *Subject:* Re: [f-nsp] Spanning tree on brocade
>
>
>
> So neither "show span" nor "show 802-1w" shows spanning tree running?  Is
> this turboiron running routing code or switch code?  IIRC, the default is
> single spanning tree on switch code and no spanning tree on routing code.
>
> --
> Eldon Koyle
>
> On May 17, 2016 2:12 PM, "Nick Cutting" <ncutting at edgetg.com> wrote:
>
> I think I have found my answer – as this switch is not participating in
> spanning tree – I believe that :
>
>
>
> STP configured to ON, priority is level0
>
>
>
> Is forwarding the BPDU’s unmodified.
>
>
>
> Would I be correct in this assumption? I see the correct Bridge ID’s as if
> this switch is not there.
>
>
>
> *From:* Nick Cutting
> *Sent:* Tuesday, May 17, 2016 3:26 PM
> *To:* Nick Cutting; Eldon Koyle
> *Cc:* foundry-nsp at puck.nether.net
> *Subject:* RE: [f-nsp] Spanning tree on brocade
>
>
>
> Now I have another switch – that has no IEEE spanning tree, No 802w, and
> no pvst configured.
>
>
>
> however, it says it is enabled on the port??
>
>
>
> 10GigabitEthernet23 is up, line protocol is up
>
>   Hardware is 10GigabitEthernet, address is 748e.f821.57d3 (bia
> 748e.f821.57e9)
>
>   Configured speed 10Gbit, actual 10Gbit, configured duplex fdx, actual fdx
>
>   Member of L2 VLAN ID 501, port is untagged, port state is FORWARDING
>
>   BPDU guard is Disabled, ROOT protect is Disabled
>
>   Link Error Dampening is Disabled
>
> *  STP configured to ON, priority is level0*
>
>
>
> Now – the loops prevention is on the otherside – and they are receiving
> BPDU’s on this switch – how can this be possible with no stp config?
>
>
>
> Can someone please elaborate on the port level spanning tree?
>
>
>
> Thanks !
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20160518/54fe2c12/attachment.html>