<p dir="ltr">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.</p>
<p dir="ltr">-- <br>
Eldon</p>
<div class="gmail_quote">On May 24, 2016 3:16 PM, "Nick Cutting" <<a href="mailto:ncutting@edgetg.com">ncutting@edgetg.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All of your tips and best practices, none of which exist at present  - will be going into a maintenance window.<br>
<br>
Does anyone have any experience with Broadcast storm control?<br>
<br>
I see for iSCSI it is supposed to be turned off according to the "best practice FCX for iSCSI"<br>
<br>
Rate Limiting<br>
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.<br>
<br>
Syntax: [no] broadcast limit <num><br>
Syntax: [no] multicast limit<br>
Syntax: [no] unknown<br>
-unicast limit<br>
<br>
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.<br>
<br>
<a href="http://community.brocade.com/dtscp75322/attachments/dtscp75322/ethernetswitches/2538/1/BrocadeFCX_iSCSI_SAN_ConfigGuide_GA-CG-285-00.pdf" rel="noreferrer" target="_blank">http://community.brocade.com/dtscp75322/attachments/dtscp75322/ethernetswitches/2538/1/BrocadeFCX_iSCSI_SAN_ConfigGuide_GA-CG-285-00.pdf</a><br>
<br>
<br>
<br>
-----Original Message-----<br>
From: foundry-nsp [mailto:<a href="mailto:foundry-nsp-bounces@puck.nether.net">foundry-nsp-bounces@puck.nether.net</a>] On Behalf Of Jethro R Binks<br>
Sent: Wednesday, May 18, 2016 11:11 AM<br>
To: foundry-nsp<br>
Subject: Re: [f-nsp] Spanning tree on brocade<br>
<br>
Some thoughts;<br>
<br>
"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.<br>
<br>
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:<br>
<br>
vlan xyz<br>
 spanning-tree 802-1w<br>
<br>
and on one device which you choose, specifically define it is to be the root bridge:<br>
<br>
vlan xyz<br>
 spanning-tree 802-1w<br>
 spanning-tree 802-1w priority 0<br>
<br>
You can also consider the following, which you will probably find in any generic spanning tree reference:<br>
<br>
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.<br>
<br>
For links between network devices, consider explicitly setting them to be p2p with spanning-tree 802-1w admin-pt2pt-mac.<br>
<br>
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.<br>
<br>
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.<br>
<br>
And sometimes switches do go bad.  Really really bad.<br>
<br>
Jethro.<br>
<br>
<br>
<br>
On Wed, 18 May 2016, Nick Cutting wrote:<br>
<br>
> No routing at all<br>
><br>
> The meltdown is almost certainly the result of 6 Fastirons, 2<br>
> turboIrons running a combination of IEEE, 802.1w and No spanning tree<br>
> at all. Ive diagrammed this now for each vlan, and I have found some<br>
> serious deisgn issues.<br>
><br>
> MGT wanted me to figure out what happened, All I can think about is<br>
> how to fix this - i.e 801.w everywhere, on all vlans - It seems that<br>
> this runs as a per-vlan spanning tree flavor?<br>
><br>
> NickC<br>
><br>
> From: Nick Hilliard [mailto:<a href="mailto:nick@foobar.org">nick@foobar.org</a>]<br>
> Sent: Wednesday, May 18, 2016 10:28 AM<br>
> To: Eldon Koyle<br>
> Cc: Nick Cutting; foundry-nsp<br>
> Subject: Re: [f-nsp] Spanning tree on brocade<br>
><br>
> Eldon Koyle wrote:<br>
> > That is _really_ old code on the turboiron. It may be the version<br>
> > they shipped with, which was extremely buggy. You are correct that<br>
> > it is routing code (TIR is routing, TIS is switching). Are you doing<br>
> > any routing on that device?<br>
><br>
> old and buggy, but stp on 4.02.00c was fine. If there was an STP<br>
> meltdown, it's more likely to have been the result of a network misconfig.<br>
><br>
> 7.3.00f was the next usable version of the tix code after 4.02.00c.<br>
> Upgrading would be a really good idea, not least due to the unicast<br>
> flooding problem in all versions of the turboiron code before 7.3<br>
> (DEFECT000362191).<br>
><br>
> Nick<br>
><br>
> ________________________________<br>
><br>
<br>
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .<br>
Jethro R Binks, Network Manager,<br>
Information Services Directorate, University Of Strathclyde, Glasgow, UK<br>
<br>
The University of Strathclyde is a charitable body, registered in Scotland, number SC015263.<br>
_______________________________________________<br>
foundry-nsp mailing list<br>
<a href="mailto:foundry-nsp@puck.nether.net">foundry-nsp@puck.nether.net</a><br>
<a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" rel="noreferrer" target="_blank">http://puck.nether.net/mailman/listinfo/foundry-nsp</a><br>
<br>
_______________________________________________<br>
foundry-nsp mailing list<br>
<a href="mailto:foundry-nsp@puck.nether.net">foundry-nsp@puck.nether.net</a><br>
<a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" rel="noreferrer" target="_blank">http://puck.nether.net/mailman/listinfo/foundry-nsp</a><br>
</blockquote></div>