Header Only - DO NOT REMOVE - Extreme Networks

Stacking strange behavior


Userlevel 2
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,

22 replies

80/4 is 20gig.

There is a blocked port to prevent a loop, this is normal is all stacks.
Userlevel 2
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.
Userlevel 6
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.
Julian Eble wrote:

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.

Stack port 1:1 should connect to 2:2, at least we always go 2 - 1 through the stack.
Userlevel 6
Julian Eble wrote:

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.

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)
Userlevel 2
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
================================================================================
Userlevel 6
Hello Julian,

Are you seeing an issue with the stack? or just investigating the speeds on the stack ports?
Userlevel 2
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
Userlevel 6
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.
Userlevel 2
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.
Userlevel 6
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.
Userlevel 2
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?
Userlevel 6
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.
Userlevel 2
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.
Userlevel 6
Julian Eble wrote:

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.

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.
Userlevel 2
Julian Eble wrote:

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.

Thanks for the info, I'm going to change that.
Userlevel 6
Julian Eble wrote:

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.

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)
Userlevel 2
Julian Eble wrote:

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.

So, if I want to use the other 2 ports, the V160 should be fine, right?
Userlevel 6
Julian Eble wrote:

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.

The v160 will double the bandwidth and will work in your current setup.
Userlevel 6
Julian Eble wrote:

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.

Yes V160 is perfectly fine, if you need the other ports for some other purpose.
Userlevel 7
You were mislead by the V80 denomination. Using the 40G port at normal speed is V160, and you can go to V320 if using all 4x 40G ports. This V80 mode is for interconnection with V80 module present on x460G1. Between x670 (G2 or not), you shouldn't configure V80.

The blocked state is to prevent a loop to happen. This is only for broadcast traffic (while multicast is blocked on a per group basis). Unicast traffic can use any link (it will choose the fastest one).
Userlevel 2
Grosjean, Stephane wrote:

You were mislead by the V80 denomination. Using the 40G port at normal speed is V160, and you can go to V320 if using all 4x 40G ports. This V80 mode is for interconnection with V80 module present on x460G1. Between x670 (G2 or not), you shouldn't configure V80.

The blocked state is to prevent a loop to happen. This is only for broadcast traffic (while multicast is blocked on a per group basis). Unicast traffic can use any link (it will choose the fastest one).

"Unicast traffic can use any link (it will choose the fastest one)."

So it's not going to load balance?

Reply