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)
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
(-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".
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...