Loop Detection Problem in Stack

[cankaya_univers]

Hello,

I have 2 stakcs. One of them has 9 switches and another one has 11 switches. I activate loop detection for all vlans. 

When I connect my uplink to stack masters, there is no problem. Loop detection works.

But when I connect uplink to another stack members and I make a loop, loop detection does not work.

Is this a firmware problem or a configuration problem? Have you ever heard of this problem before?

There is stack config below: 5/2/5 is uplink port.  

CUS_211_HUKUK# show running-config
Current configuration:
!
ver 08.0.90jT213
!
stack unit 1
  module 1 icx7250-48p-poe-port-management-module
  module 2 icx7250-sfp-plus-8port-80g-module
  priority 128
  stack-trunk 1/2/1 to 1/2/2
  stack-trunk 1/2/3 to 1/2/4
stack unit 2
  module 1 icx7250-48p-poe-port-management-module
  module 2 icx7250-sfp-plus-8port-80g-module
  stack-trunk 2/2/1 to 2/2/2
  stack-trunk 2/2/3 to 2/2/4
stack unit 3
  module 1 icx7250-48p-poe-port-management-module
  module 2 icx7250-sfp-plus-8port-80g-module
  stack-trunk 3/2/1 to 3/2/2
  stack-trunk 3/2/3 to 3/2/4
stack unit 4
  module 1 icx7250-48p-poe-port-management-module
  module 2 icx7250-sfp-plus-8port-80g-module
  stack-trunk 4/2/1 to 4/2/2
  stack-trunk 4/2/3 to 4/2/4
stack unit 5
  module 1 icx7250-48-port-management-module
  module 2 icx7250-sfp-plus-8port-80g-module
  stack-trunk 5/2/1 to 5/2/2
  stack-trunk 5/2/3 to 5/2/4
stack unit 6
  module 1 icx7250-48-port-management-module
  module 2 icx7250-sfp-plus-8port-80g-module
  stack-trunk 6/2/1 to 6/2/2
  stack-trunk 6/2/3 to 6/2/4
stack unit 7
  module 1 icx7250-48-port-management-module
  module 2 icx7250-sfp-plus-8port-80g-module
  stack-trunk 7/2/1 to 7/2/2
  stack-trunk 7/2/3 to 7/2/4
stack unit 8
  module 1 icx7250-48-port-management-module
  module 2 icx7250-sfp-plus-8port-80g-module
  stack-trunk 8/2/1 to 8/2/2
  stack-trunk 8/2/3 to 8/2/4
stack unit 9
  module 1 icx7250-48-port-management-module
  module 2 icx7250-sfp-plus-8port-80g-module
  stack-trunk 9/2/1 to 9/2/2
  stack-trunk 9/2/3 to 9/2/4
stack enable
stack mac d4c1.9e77.a9ac
!
!
!
!
!
vlan 1 name DEFAULT-VLAN by port
 loop-detection
!
!
!
!
vlan 1810 name Idari by port
 tagged ethe 5/2/5
 untagged ethe 1/1/1 to 1/1/48 ethe 1/2/5 to 1/2/8 ethe 2/1/1 to 2/1/48 ethe 2/2/5 to 2/2/8 ethe 3/1/1 to 3/1/48 ethe 3/2/5 to 3/2/8 ethe 4/1/1 to 4/1/48 ethe 4/2/5 to 4/2/8 ethe 5/1/1 to 5/1/48 ethe 5/2/6 to 5/2/8 ethe 6/1/1 to 6/1/48 ethe 6/2/5 to 6/2/8 ethe 7/1/1 to 7/1/48 ethe 7/2/5 to 7/2/8 ethe 8/1/1 to 8/1/48 ethe 8/2/5 to 8/2/8 ethe 9/1/1 to 9/1/48 ethe 9/2/5 to 9/2/8
 loop-detection
!
vlan 1911 name Yonetim by port
 tagged ethe 5/2/5
 router-interface ve 1911

loop-detection
!
!
!
!
!
!
!
!
!
!
loop-detection-interval 30
errdisable recovery cause loop-detect
errdisable recovery interval 600
aaa authentication web-server default local
aaa authentication login default local
enable aaa console
enable acl-per-port-per-vlan
hostname CUS_211_HUKUK
ip dhcp snooping vlan 1810
ip route 0.0.0.0/0 192.168.11.1
!
no telnet server
username super password .....
!
!
!
!
hitless-failover enable
!
!
sz registrar
!
!
!
!
!
!
!
!
!

interface ethernet 5/2/5
 dhcp snooping trust
!
interface ve 1911
 ip address 192.168.11.212 255.255.255.0
!
!
!
!
!
!
!
!
!
!
!
!
!
end

[netwizz]

Sounds like loop-detection is working for you as designed.  Specifically, loop-detection works by generating layer-2 loop-detection frames, which are the the layer-2 PDU (Protocol Data Unit).  These carefully crafted loop-detection frames are sends out on all interfaces, and if received by the same logical chassis (i.e. the same stack) it detects that there is a layer-2 switching loop and places an interface in err-disabled state mitigating the loop.

The issue you are having is that loop-detection is recognized by only the sending chassis that generated the loop-detection frames.

The answer to resolve your problem is to look to implementing your favorite flavor of per-vlan spanning-tree.  As long as it is supported by all devices in your topology, spanning-tree will function between different chassis, logical-chassis, and even different vendors equipment.  That said, I would highly recommended against mixing and matching vendor equipment within the same Layer-2 because there are proprietary protocols that will likely cause you problems.  For example, if a Cisco device sees and FDP frame for Foundry Discovery Protocol, it will not recognize it and merely forward it on like it does any other unrecognized layer-2 frame.  Then another connected ICX device will receive that FDP and and construct a neighbors table that does not accurately reflect your topology.

Similarly, it is possible for a loop-detection frame to be reflected back to the same chassis that created it most likely coming in on a fiber-uplink dropping an entire stack of 9 or 11 switches, so take that into consideration.  I actually had a very similar issue years ago where a Cisco device was running BPUD guard on an uplink (I did NOT configure that) and an ICX device did exactly what it should have and forwarded a Cisco proprietary BPDU through from one Cisco device to another dropping a stack, so the knife cuts both ways.

You are going to find the ICX devices are absolutely excellent and almost certainly spanning-tree can be implemented in your deployment to make it work as you desire.

[cankaya_univers]

Thanks you have a point but what I do not understand is why loop detection works when I connect my fiber uplink to master switch. If uplink is connected to any switch in stack besides master, loop-detection does not work. 

Loop-detection works when switch connected to other devices only when uplink is on master switch. This looks like a problem between stack members?

[BenBeck]

Can you post 'show loop-detection status'? This will show you how the control packets are being seen. Keep in mind loop-detection will not catch absolutely every loop scenario.

Also, 'clear loop-detection' will clear those statistics if you want to do some fresh tests. 

[netwizz]

You will probably need to do packet captures to see what is different otherwise, you can see what each stack is doing with the show loop-detection status command and try to infer the behavior.

You might want to switch to spanning-tree as your loop-mitigation methodology; I am uncertain which is best in your use case.

[Orlando_Elias]

We should also be careful about the config.

When loop detection is configured on a per VLAN basis, the loop-detect will be triggered only if the packet is received in the same VLAN.

Would you help us verify that the port in the member switch that is linking to the uplink is tagged/untagged in the same VLANs?