topic RE: Stacking strange behavior in ExtremeSwitching (Other)

Stacking strange behavior

Julian_Eble — Thu, 23 Jun 2016 17:42:00 GMT

Hello,

I've 2 X670G2-48x-4q with version 16.1.3.6 patch1-7 and they're stacked each other.

There're two QSFP cables connected in the ports 57 and port 61 ( suppose to be 80G), but after checking the stack-ports some really strange thing comes up.

Stack Topology is a RingSlot Port Select Node MAC Address Port State Flags Speed
---- ---- ------ ----------------- ----------- ----- -----
*1 1 Native 00:04:96:9a:8d:2f Operational CB 20G
*1 2 Native 00:04:96:9a:8d:2f Operational C- 20G
2 2 Native 00:04:96:9a:74:1f Operational C- 20G
2 1 Native 00:04:96:9a:74:1f Operational CB 20G
* - Indicates this node
Flags: (C) Control path is active, (B) Port is Blocked

Why they're connected by 20G?
Why is there blocked ports?

Thanks,

RE: Stacking strange behavior

davidj_cogliane — Thu, 23 Jun 2016 17:45:00 GMT

80/4 is 20gig.

There is a blocked port to prevent a loop, this is normal is all stacks.

RE: Stacking strange behavior

Julian_Eble — Thu, 23 Jun 2016 18:01:00 GMT

Hello David,

But the 1:1 is connected to 2:1 right?
The port is 40G.

The block is just for broadcast and multicast, and there's no traffic on that port, even unicast.

RE: Stacking strange behavior

Patrick_Voss — Thu, 23 Jun 2016 18:01:00 GMT

Hello Julian,

The 80g you are referring to is probably v80 stacking. This simply means that between both ports ingress and egress you will get 80g of throughput. As David mentioned this is normal based on the configuration of the stack.

RE: Stacking strange behavior

davidj_cogliane — Thu, 23 Jun 2016 18:01:00 GMT

Stack port 1:1 should connect to 2:2, at least we always go 2 - 1 through the stack.

RE: Stacking strange behavior

Henrique — Thu, 23 Jun 2016 18:01:00 GMT

There is a stack protocol that identify the ring topology and block one stack-port link regardless of any traffic on that.

That blocked port behavior is to avoid broadcast and multicast (blocked by mcast group)

RE: Stacking strange behavior

Julian_Eble — Thu, 23 Jun 2016 18:03:00 GMT

The utilization :

h ports stack-ports utilization bandwidth
Port Link Link Rx Peak Rx Tx Peak Tx
State Speed % bandwidth % bandwidth % bandwidth % bandwidth
================================================================================
1:1 A 20000 55.98 65.59 58.00 71.30
1:2 A 20000 0.16 0.23 0.13 0.48
2:1 A 20000 58.05 62.78 56.03 65.24
2:2 A 20000 0.13 0.44 0.16 0.23
================================================================================

RE: Stacking strange behavior

Patrick_Voss — Thu, 23 Jun 2016 18:17:00 GMT

Hello Julian,

Are you seeing an issue with the stack? or just investigating the speeds on the stack ports?

RE: Stacking strange behavior

Julian_Eble — Thu, 23 Jun 2016 18:26:00 GMT

Patrick, Ivestigating the ports to don't have any future problem And as the traffic grows I've concern about getting the port to discard packets

RE: Stacking strange behavior

Patrick_Voss — Thu, 23 Jun 2016 18:30:00 GMT

I might be able to help with that. Can you provide me with more information on how this stack is setup? What module is installed? Native or Alternate?

Some of these questions I can assume based on what you provided me but I want to be 100% certain before I make recommendations.

RE: Stacking strange behavior

Julian_Eble — Thu, 23 Jun 2016 18:33:00 GMT

So there's no module I'm using the the 2 ports in front of the switch, ports 57 and 61.
I configured that with native V80.

The switchs are connect boths with the same ports, like the 1:57 and the 2:57 , same to the ports 1:61 and 2:61.

RE: Stacking strange behavior

Patrick_Voss — Thu, 23 Jun 2016 18:38:00 GMT

Hello Julian,

If you will allow me some time I would like to do some testing with the x670g2. You should be able to use v160 stacking and essentially double your stack port bandwidth.

Also to reiterate what David said the recommended stacking setup is to have the cables crossed. For example, port 1:57 to 2:61 and 1:61 to 2:57.

RE: Stacking strange behavior

Julian_Eble — Thu, 23 Jun 2016 18:45:00 GMT

No problem, what you want to do?
I thought the V80 has the meaning of having 80Gbps full throughput, as there is two ports connected.

If I do this topology, that will change to daisy-chain right or am I wrong?

RE: Stacking strange behavior

Patrick_Voss — Thu, 23 Jun 2016 18:49:00 GMT

The testing I would like to do would be in the lab. The topology change would still give you a ring. The amount of connections remains the same you are just swapping the cables on one slot to make them crossed instead of straight up and down.

RE: Stacking strange behavior

Julian_Eble — Thu, 23 Jun 2016 18:53:00 GMT

Is there any cons to use directly to v320 ?

The lab is to test the other port that is not forwarding the traffic?

I'll schedule a new maintance window to do these changes.

RE: Stacking strange behavior

Chad_Smith1 — Thu, 23 Jun 2016 18:53:00 GMT

Yes I believe v320 is the best option for you. You are already connecting the nodes with 40G cables so you might as well use all the bandwidth.

RE: Stacking strange behavior

Julian_Eble — Thu, 23 Jun 2016 18:53:00 GMT

Thanks for the info, I'm going to change that.

RE: Stacking strange behavior

Chad_Smith1 — Thu, 23 Jun 2016 18:53:00 GMT

Just to clarify, as Stephane said below, you need to use 4 40G connections for v320. So if you need those other 40G ports for some other purpose, then v320 may not be ideal.

The VXXX stacking numbers are based on all ports ingress and egress. So:

V160 = 40G port * 2 ports * 2 (ingress and egress)
V320 = 40G port * 4 ports * 2 (ingress and egress)

RE: Stacking strange behavior

Julian_Eble — Thu, 23 Jun 2016 18:53:00 GMT

So, if I want to use the other 2 ports, the V160 should be fine, right?

RE: Stacking strange behavior

Patrick_Voss — Thu, 23 Jun 2016 18:53:00 GMT

The v160 will double the bandwidth and will work in your current setup.