[f-nsp] Spanning tree on brocade

Tue May 24 21:41:33 EDT 2016

We have the broadcast/multicast/unknown unicast limit configured on all of
our campus edge ports (IIRC, we set it to the minimum).  The documentation
and the switch disagreed about the units (pps vs kbps, at least with the
last code version I checked), and I haven't actually tested to see that it
acts as expected; but I haven't noticed any problems because of it, either.

-- 
Eldon
On May 24, 2016 3:16 PM, "Nick Cutting" <ncutting at edgetg.com> wrote:

> All of your tips and best practices, none of which exist at present  -
> will be going into a maintenance window.
>
> Does anyone have any experience with Broadcast storm control?
>
> I see for iSCSI it is supposed to be turned off according to the "best
> practice FCX for iSCSI"
>
> Rate Limiting
> iSCSI traffic can generate bursts of heavy traffic that can be mistaken as
> traffic storms. The Brocade FCX provides ability to limit these storms on
> the switch, but in dedicated iSCSI SANs, as being configured through this
> document, this feature should not be enabled. By default, this feature is
> disabled which is why there is no need to enter any additional commands.
>
> Syntax: [no] broadcast limit <num>
> Syntax: [no] multicast limit
> Syntax: [no] unknown
> -unicast limit
>
> However this same "best practice FCX for iSCSI" document recommends
> disabling spanning tree on host facing ports...which I do not want to do,
> happy with portfast instead.
>
>
> http://community.brocade.com/dtscp75322/attachments/dtscp75322/ethernetswitches/2538/1/BrocadeFCX_iSCSI_SAN_ConfigGuide_GA-CG-285-00.pdf
>
>
>
> -----Original Message-----
> From: foundry-nsp [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf
> Of Jethro R Binks
> Sent: Wednesday, May 18, 2016 11:11 AM
> To: foundry-nsp
> Subject: Re: [f-nsp] Spanning tree on brocade
>
> Some thoughts;
>
> "What happened" may be hard to determine at this point, but generally
> apart from the obvious causes (like cabling and config mistakes), one
> possible is that someone connected a device in a way that connected
> together two vlans together and caused the instability (you might never
> find that).  Or a device handling multiple VLANs failed in some way.
>
> What's more interesting is how to protect yourself for the future.  At a
> minimum, if you are completely Brocade, ensure you are running 802.1w in
> each vlan on all the devices:
>
> vlan xyz
>  spanning-tree 802-1w
>
> and on one device which you choose, specifically define it is to be the
> root bridge:
>
> vlan xyz
>  spanning-tree 802-1w
>  spanning-tree 802-1w priority 0
>
> You can also consider the following, which you will probably find in any
> generic spanning tree reference:
>
> Where you have edge connections, consider explicitly set them to be edged
> with spanning-tree 802-1w admin-edge-port (which stops them becoming part
> of the spanning tree so cuts down on needless STP calculations when they
> come up and down).  Then enable stp-bpdu-guard on them so they will shut
> down if someone does something rash and creates a loop there, or tries to
> extend your network by connecting their own stp-aware devices.
>
> For links between network devices, consider explicitly setting them to be
> p2p with spanning-tree 802-1w admin-pt2pt-mac.
>
> Be aware that making changes, such as changing spanning tree type (from 1d
> to 1w or 1s) usually causes some initial disruption so you might want to
> plan out what you are going to change and where and get a downtime window
> where you can progress it out.  Don't do it until you are sure you know
> what connects to where and that there are no unknown parts.
>
> If you want to give management something to do, ask them to support a
> policy that absolutely forbids anyone from extending the network (by adding
> hubs/switches for themselves) without authorisation, if you are in the sort
> of environment where that could cause you issues.  If you are aiming for an
> accurate predictable STP deployment, you really really want to know exactly
> what the network looks like and don't want someone else adding bits to it
> without you knowing.
>
> And sometimes switches do go bad.  Really really bad.
>
> Jethro.
>
>
>
> On Wed, 18 May 2016, Nick Cutting wrote:
>
> > No routing at all
> >
> > The meltdown is almost certainly the result of 6 Fastirons, 2
> > turboIrons running a combination of IEEE, 802.1w and No spanning tree
> > at all. Ive diagrammed this now for each vlan, and I have found some
> > serious deisgn issues.
> >
> > MGT wanted me to figure out what happened, All I can think about is
> > how to fix this - i.e 801.w everywhere, on all vlans - It seems that
> > this runs as a per-vlan spanning tree flavor?
> >
> > NickC
> >
> > From: Nick Hilliard [mailto:nick at foobar.org]
> > Sent: Wednesday, May 18, 2016 10:28 AM
> > To: Eldon Koyle
> > Cc: Nick Cutting; foundry-nsp
> > Subject: Re: [f-nsp] Spanning tree on brocade
> >
> > Eldon Koyle wrote:
> > > 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?
> >
> > old and buggy, but stp on 4.02.00c was fine. If there was an STP
> > meltdown, it's more likely to have been the result of a network
> misconfig.
> >
> > 7.3.00f was the next usable version of the tix code after 4.02.00c.
> > Upgrading would be a really good idea, not least due to the unicast
> > flooding problem in all versions of the turboiron code before 7.3
> > (DEFECT000362191).
> >
> > Nick
> >
> > ________________________________
> >
>
> .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
> Jethro R Binks, Network Manager,
> Information Services Directorate, University Of Strathclyde, Glasgow, UK
>
> The University of Strathclyde is a charitable body, registered in
> Scotland, number SC015263.
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
> _______________________________________________
> 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/20160524/0fa35a56/attachment.html>