I have a simple question (i think i already know the answer, but a second opinion never hurts):
Suppose you have a trunk and on SIDE A the VLAN allowed list is: 1-4094
On the other side B the VLAN allowed list is: 1-4
If i have a VLAN 300 on SIDE A, it will be put in forwarding state (because it is allowed). On SIDE B, i see the VLAN 300 (because of VTP propagation), but because it is not allowed on the trunk, the switch does not run a STP instance for it and i don't see it in "show spanning tree".
The question now is:
1) if i have a broadcast storm in VLAN 300, will the broadcasts be transmitted to SIDE B ? My opinion is: yes, because it is in forwarding state on SIDE A.
2) When arriving at side B, the switch will drop the packet on the trunk because it has a VLAN ID of 300 which is not allowed. Correct ? Is there any command on the switch to see the amount of dropped packets received because the VLAN_ID tag does not match the "allowed vlan list" ? How can i detect from this side, that the other side is actually sending me lots of "bogus" vlan_id packets ?
3) If the port on SIDE B has "storm-control broadcast 10%" configured, will these invalid VLAN_D 300 packets be included in the storm-control calculation ? As far as i know, storm-control is not VLAN aware and will take into account any broadcast packet, no matter on which VLAN it arrives.
4) If storm-control applies a drop filter because of these VLAN300 broadcasts, the drop filter is applied to all VLANs on the trunk, therefore impacting vlan1-4 (and maybe dropping arp broadcasts in these vlans for example).
first of all your question is not simple at all and it is very intersting.
I follow you in the scenario up to point 3:
to know what happens if frames of not allowed vlans are dropped before being counted as broadcast traffic by storm control or if they trigger storm control you should perform some tests using a traffic generator.
I agree with you on point 4: if storm-control can be triggered by broadcast frames on unwanted vlans it will affect also the wanted vlans traffic (including multicast traffic with the execption of STP BPDUs but not on all modules)
Vlan trunking, 802.1Q are not mentioned in the chapter.
a possible mitigation to this could be provided by VTP pruning in which the second switch can tell to the other to avoid to send traffic for some vlans.
However, clearly this scenario starts with an asymmetric configuration and the best fix is to use the same vlan allowed list on both ends.
Are you analysing a network issue ?
Have you seen multicast traffic dropped ?
This can confirm your understanding about point 3.
Hope to help
ok, i have done some tests in the lab and indeed, "un_allowed vlan" broadcasts were taken into account with "storm-control".
2950 Access switch 12.2(25)SED1, vlans allowed 1-4, has "storm-control broadcast level 30 20" configured on uplink port.
3750 "Core" switch, vlans allowed 1-4 + 1000
When i create a spanning tree loop in vlan 1000:
-core goes to 100% cpu
-access remains pretty low, because it hardware drop the packets
-the Access switch however triggers stormcontrol and puts a drop filter on the trunk, dropping broadcasts in ALL vlans (1-4) (no ARP resolution, no DHCP anymore in any vlan).
- stormcontrol is more effective on the edge end-user ports.
- i can see the benefit of stormcontrol on the core switch trunks (blocking incoming broadcasts from an access and cutting off the access from the rest of the network). However, i feel putting stormcontrol on the Access trunks should not be done.
- always have the "allowed vlans" match on both sides of a trunk
for me storm -control is a way to protect network devices from the effects of a broadcast storm.
For big enterprises with multiple campus networks is important to provide enough time to network engineers to access the core switches and to cut the loop by disabling some links.
We use storm-control combined with loop guard and we are satisfied of it.
It is not possible during an emergence to try to distinguish useful broadcast traffic (ARP requests, DHCP requests) from "noise".
The key point is time: to have time and opportunity to access the core switches remotely.
Otherwise if the campus is isolated you need to find an on site person and to guide him/her on the phone to unplug cables and fibers to break the loop, and in some cases to switch off one core switch.
This happened more often in the past.
Good Easter !!
Hope to help
(-hum-) That is exactly what happened: we couldn't access the core switches anymore and had to go onsite and restart one of the two. The customer had storm-control, loop-guard and udld deployed, but somehow it was unable to stop the loop. I am still trying to determine where the loop was created but it is very hard. I am also wondering if a flapping OSPF link didn't create a 100% cpu utilisation such that the switch was unable to generate any BPDU's anymore. The first log messages i am seeing are "loopguard" related, so this could be the case. (mmm, i wonder if ALL access switches had loopguard enabled, the network is only as strong as the weakest link, so if only one switch was missing loopguard, he could be the cause...)
Small question: do you also have storm-control on the core trunks defined ? Do you use the drop filter+trap action or the shutdown+err disable recovery action ?
I find one of the disadvantages of the drop filter action is that a message is logged when the filter is applied, but NO message is logged when the filter is removed. With the shutdown and err-disable, at least you see a log message "attempting to recover int x/x from storm-control".
Great easter to you too...