Do I have a loop in this stack?

[Neal_Howard]

I am a brand new owner of a pair of X670V-48t switches and am a complete newb to Extreme switches and XOS but I've got over 15 years of experience with Cisco Catalyst switches and am well-versed in those.

My pair of X670V-48t switches are equipped each with a VIM4-40G4X module and are connected together as a stack with a pair of QSFP+ cables.

I had Extreme's tech support assist me with configuring the stack and was advised to connect the VIM4 ports on the back of each unit as Port 3 on Switch A to port 4 of Switch B and Port 4 of Switch A to Port 3 of Switch B.

Tech Support remoted into my PC and configured the switch stacking configs for me and the stack seems to be functioning, but part of the behavior of the switches troubles me.

All the blue LEDs on the connected ports of the VIM4 modules themselves and the blue "ST" LEDs on the front panels, and also all the link LEDs of any Ethernet port connected to a computer all blink rapid-fire, machine-gun-like *in unison* at a very high rate of speed even when there is no real network traffic. In the Cisco world, where I'm much more familiar, this unison-LED-blinking generally indicates very bad juju... that a loop exists or that some kind of broadcast or multicast packet storm is happening. Even with no computers connected to the switches, or any connections to the rest of my network (just the two switches connected to each other via the QSFP+ cables and isolated from the rest of the world) the blue LEDs on the back and front of the units still blink rapid-fire in unison.

Is this normal behavior for a stacked pair of switches in the Extreme switch world?

Here is my stacking configs:

Slot-1 SANBONE-10G.1 # show stacking
Stack Topology is a Ring
Active Topology is a Ring
Node MAC Address Slot Stack State Role Flags
------------------ ---- ----------- ------- ---
*00:04:96:97:de:07 1 Active Master CA-
00:04:96:97:de:0b 2 Active Backup CA-
* - Indicates this node
Flags: (C) Candidate for this active topology, (A) Active Node
(O) node may be in Other active topology
Slot-1 SANBONE-10G.2 # show stacking configuration
Stack MAC in use: 02:04:96:97:de:07
Node Slot Alternate Alternate
MAC Address Cfg Cur Prio Mgmt IP / Mask Gateway Flags Lic
------------------ --- --- ---- ------------------ --------------- --------- ---
*00:04:96:97:de:07 1 1 100 CcEeMm-Nn --
00:04:96:97:de:0b 2 2 90 CcEeMm-Nn --
* - Indicates this node
Flags: (C) master-Capable in use, (c) master-capable is configured,
(E) Stacking is currently Enabled, (e) Stacking is configured Enabled,
(M) Stack MAC in use, (m) Stack MACs configured and in use are the same,
(i) Stack MACs configured and in use are not the same or unknown,
(N) Enhanced protocol is in use, (n) Enhanced protocol is configured,
(-) Not in use or not configured
License level restrictions: (C) Core, (A) Advanced edge, or (E) Edge in use,
(c) Core, (a) Advanced edge, or (e) Edge configured,
(-) Not in use or not configured
Slot-1 SANBONE-10G.3 # show stacking-support

Stack Available Ports
Port Native Alternate Configured Current
----- ----------------- ---------- ----------
1 Yes 47 Native N/A
2 Yes 48 Native N/A
stacking-support: Enabled N/A

Flags: * - Current stack port selection

Slot-1 SANBONE-10G.4 # show stacking stack-ports
Stack Topology is a Ring
Slot Port Select Node MAC Address Port State Flags Speed
---- ---- ------ ----------------- ----------- ----- -----
*1 1 Native 00:04:96:97:de:07 Operational CB 40G
*1 2 Native 00:04:96:97:de:07 Operational C- 40G
2 1 Native 00:04:96:97:de:0b Operational C- 40G
2 2 Native 00:04:96:97:de:0b Operational CB 40G
* - Indicates this node
Flags: (C) Control path is active, (B) Port is Blocked
Slot-1 SANBONE-10G.5 #

[Drew_C]

Hi Neal,
Since you already have a case open, you likely already know that the rapid LED blinking issue is expected to be resolved under CR xos0059128. I'm not sure of the timeline, but it looks like it will be included in a patch soon, as well as future releases.

-Drew

[Paul_Russo]

Thanks Neal. Let us know if we can help. We can try and look at some loaner gear for a few weeks if that will help you to get familiar with MLAG.

P

[Neal_Howard]

Thanks Paul,

I was looking at the MLAG feature in the Concepts Guide earlier and it's definitely interesting. Maybe someday when I've got more time to play with these switches I can look further into it. I'm just under a time crunch right now to get the 10Gbe L2 iSCSI network ready for our EMC engineer who's coming onsite probably sometime this week to stand up our new VNXe3200 system so I can get ready to start moving LUNS off our old Celerra SAN which is filled to capacity.

I've just set up a pair of lacp LAGs to our existing Cisco 3750 1Gbe SAN Backbone stack (etherchannel lacp on that end), one to each Summit switch and that was effortless and is working perfectly at 2Gbps full duplex each LAG. I've also already moved a couple of my lesser iSCSI clients off the Cisco's and over to the Summits and they're working as expected as well. I have to wait to Friday evening after hours to move the rest of my current iSCSI clients and the Celerra server itself off the Ciscos and onto the Summits, then I can disconnect the Ciscos and re-purpose them to another network where we need them.

[Paul_Russo]

Hey Neal, I know that GTAC has not finished this testing and I have requested them to call you and help verify either the config or the operation.

Sorry this has been so frustrating. With that said if this is an area where you need redundancy there is another option which provides more protection. The feature is called MLAG and it allows two independent devices to create a Load share group to another device. Uses are for servers with two connections, one into each switch, or other switches with redundant connections into a redundant core. MLAG provides not only link and switch redundancy it also allows you the ability to upgrade the switches without taking both of them down.

P