1 
┌─────┐      ┌─────┐
|  A  ┼------┼  B  |
└─────┘      └┬───┬┘
              └---┘   <-- loop

behold the above drawing. this is a test setup connectin switch A and B, and a test loop

A: cisco switch with rstp

GLOBAL CONFIG

spanning-tree mode rapid-pvst
spanning-tree portfast default
spanning-tree portfast bpduguard default

PORT CONFIG

switchport mode access
udld port aggressive

B: alcatel lucent omniswitch

  • as dumb as possible
  • passes all traffic
  • no stp
  • filters bpdu (default setting, not kidding)

when i create the loop on B, the whole system just drowns in a broadcast strom (because switch B filters the bpdu).

but when I change the port setting on A to a trunk (no other changes), stp does kick in.

switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate

why? i don't understand, can somebody pleas explain this to me? and can I protect my network against this 'feature' of alcatel lucent? (besides putting all my port's in trunk)

Improve this question
4
  • Maybe the Alcatel switch is sending BPDUs tagged?
    – user27899
    Jul 26, 2018 at 6:38
  • I did check this but could not see it with wireshark. I created port mirror's on both switches and sniffed them both :( will check it again later today
    – pvc_be
    Jul 26, 2018 at 6:43
  • Make sure you use encapsulation replicate on the Cisco side, and make sure your Wireshark machine is able to receive tagged frames. Some vendors require the destination port to be a trunk as well
    – user27899
    Jul 26, 2018 at 7:41
  • You can limit broadcast traffic on access ports using storm-control broadcast level 5.00 2.00 which is recommended by Cisco.
    – user36472
    Jul 26, 2018 at 8:16

2 Answers 2

Reset to default
0

While switch A is running STP, switch B is not. STP detects local loops and loops between STP devices but it cannot detect loops on devices (or ports) not using STP (edit: unless they forward BPDUs as well).

Therefore, A cannot detect the (remote) loop - broadcasts will circle around, reflect back and suffocate the network. From A's point of view, B is a high-bandwidth broadcasting source - A cannot tell that it's a storm nor that it's reflecting broadcasts.

In addition to the broadcast storm, A's and B's MAC tables will become unstable due to reflected broadcasts coming from the wrong port. So, if the A-B link's bandwidth is lower than the rest of A's ports and the broadcast storm doesn't suffocate the other links you'll experience problems due to misforwarded frames.

RPVST works by sending STP BPDUs on each VLAN - tagged. When BPDUs are tagged (not 802.1-compliant), it seems the Omniswitch doesn't recognize them as such any more and passes them to the loop, reflecting them back to the Cisco which is then detecting a local loop, blocking the link.

If you use RSTP or MSTP instead of RPVST the Omniswitch likely recognizes those untagged BPDUs and continues to filter them.

Imho, if the Omniswitch doesn't support a reasonable STP variant you should replace it.

Improve this answer
4
  • stp can detect self loop's and loop's with non stp (dumb) switches, I tested this. But only if the bpdu's are not filtered by the remote device/switch. Even cisco default keepalive detects loops without stp and err-disable's the port
    – pvc_be
    Jul 26, 2018 at 10:09
  • STP can only detect remote loops on really dumb switches not filtering BPDUs - this is common but 802.1D non-compliant. The Omniswitch does filter and thus hides the remote loop. Of course, there are various alternative ways for detecting loops, other than STP - however, RSTP/MSTP is vendor-agnostic and can also detect/block redundant, larger loops which other methods often cannot.
    – Zac67 ♦
    Jul 26, 2018 at 11:35
  • the omniswitch works good, I just disabled all features to make it as dumb as possible. But by default it filters bpdu's, not what I expected, learning moment :D for anyone interessted to enable bpdu's: bridge bpdu-switching enable
    – pvc_be
    Jul 27, 2018 at 14:11
  • 1
    802.1D-compliant switches are supposed to filter BPDUs, even with STP deactivated (which generally isn't a very good idea unless loops are impossible in a very controlled environment).
    – Zac67 ♦
    Jul 27, 2018 at 15:59
1

In my first test setup i used vlan 2 for testing, ignoring vlan 1

with the tips i got, i've removed all vlan's and used only vlan 1 on both switches, the same behavior is seen on trunk and access ports (loop's) when the omniswitch (B)(wich filters bpdu) is plugged in with a loop on itself or a loop on another port of A. This is more consistent.

When i add vlan 2 again on switch A and set it as native on the trunk, stp works. The log (A) show's the following:

%SPANTREE-2-BLOCK_PVID_PEER: Blocking FastEthernet0/1 on VLAN0001. Inconsistent peer vlan.

I asume it was the untagged bpdu's (from vlan2 on A) that got forwarded from B back into vlan1 on A and triggerd the stp.

No easy fix here i think

the storm control helps ease the loop's impact.

layer 2 security seems more difficult then i anticipated...

thank you everyone helping me out on this !

Improve this answer
1
  • 1
    re: layer 2 security seems more difficult then i anticipated. Add to that statement: Managing multi-vendor networks is much more complicated than most people anticipate. One could go on for a long time about the differences in vendor implementations which are painful to get right, multiplied by the number of different vendors colliding with each other. Sometimes the idea of "saving money" with multiple vendors becomes an exercise in "penny-wise, pound foolish".
    – Mike Pennington
    Jul 26, 2018 at 17:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.