Extreme Networks Homepage Extreme Networks Homepage
Question

Switch is ignoring enable group sharing and it's causing a loopback

A
Hi everyone

I have an issue with one of my stacks where it's acting like a loopback issue. For example, in this case I have ports 1:41 and 14:2 on switch 1 grouped and Uplinked to ports 1:53, 6:53 which are also grouped on switch 2. Now this configuration has been the same since we first deployed these switches and only recently I've been losing connectivity on switch 2. The only way to temporary resolve the issue is to disable port 1:42 on Switch 1. In addition, I also have elrp excluded on both ends of the uplinks. If anyone has any suggestions please let me know.

Thanks

11 replies

P
Userlevel 4
Definitely something has been changed in sharing config or there is physical loop in switch 1... Could you check sharing config on both switches.... Show l2stats Clear l2stats Show l2stats
A
Thank you for your response and I reviewed what you have recommended and I didn't see anything out of the ordinary with associated VLANs on that grouping config.
S
Userlevel 4
What type of switches are these?
Is it X460 with XGM module or X670 switch?
What is the s/w running on it?
A
The first switch model is X670V-48x (Stack) with version 15.3.1.4 v1531b4-patch1-33

second X460-48t (Stack) with version 15.3.1.4 v1531b4-patch1-33
S
Userlevel 4
I think it's know issues.

Please call TAC and asked software which has resolved all the issues related with X670 and X460(XGM module).
A
Sumit Tokle wrote:

I think it's know issues.

Please call TAC and asked software which has resolved all the issues related with X670 and X460(XGM module).

Any idea where I can find their contact information?
A
We bought our switches and service contract with a 3rd party company so I do not have the contact to TAC. Is there a way I can find it?
T
It doesn't sound like a known issue... It's more likely a configuration issue. I would confirm the following:

- show port sharing (verify the LAG configuration is consistent on both sides of the link)

- show elrp (verify that no loop condition exists on any of the VLANs); sift through show config and verify that interconnect LAG ports are in fact excluded from ELRP)

- Show log match : attempt to discern when the interfaces go off-line and what corresponding changes may be causing the event(s); don't rule out a phy problem (i.e. physical layer issue with optics - if applicable, patch cables, etc.)

We use ELRP in conjunction with LAG ports in many scenarios with both current and superannuated firmware versions and have never encountered any issues
A
Tony Steed wrote:

It doesn't sound like a known issue... It's more likely a configuration issue. I would confirm the following:

- show port sharing (verify the LAG configuration is consistent on both sides of the link)

- show elrp (verify that no loop condition exists on any of the VLANs); sift through show config and verify that interconnect LAG ports are in fact excluded from ELRP)

- Show log match : attempt to discern when the interfaces go off-line and what corresponding changes may be causing the event(s); don't rule out a phy problem (i.e. physical layer issue with optics - if applicable, patch cables, etc.)

We use ELRP in conjunction with LAG ports in many scenarios with both current and superannuated firmware versions and have never encountered any issues

Hi Tony,

Thank you for your input, I will definitely use that for troubleshooting if this occurs again. Also, I was able to contact TAC support and what we identified is that when the grouping ports were active on both ends, one of them would stay on a ready state causing the switch to lose some network connectivity. So the engineer, conducted a remote session and reviewed the "debug" results and came to the conclusion that one of the switches on the stack is in fact defective.
T
Tony Steed wrote:

It doesn't sound like a known issue... It's more likely a configuration issue. I would confirm the following:

- show port sharing (verify the LAG configuration is consistent on both sides of the link)

- show elrp (verify that no loop condition exists on any of the VLANs); sift through show config and verify that interconnect LAG ports are in fact excluded from ELRP)

- Show log match : attempt to discern when the interfaces go off-line and what corresponding changes may be causing the event(s); don't rule out a phy problem (i.e. physical layer issue with optics - if applicable, patch cables, etc.)

We use ELRP in conjunction with LAG ports in many scenarios with both current and superannuated firmware versions and have never encountered any issues

I appreciate you keeping me in the loop... This lends itself to my earlier reference to a potentially defective phy. I'm glad it worked out for you.

Tony
S
Userlevel 4
Tony Steed wrote:

It doesn't sound like a known issue... It's more likely a configuration issue. I would confirm the following:

- show port sharing (verify the LAG configuration is consistent on both sides of the link)

- show elrp (verify that no loop condition exists on any of the VLANs); sift through show config and verify that interconnect LAG ports are in fact excluded from ELRP)

- Show log match : attempt to discern when the interfaces go off-line and what corresponding changes may be causing the event(s); don't rule out a phy problem (i.e. physical layer issue with optics - if applicable, patch cables, etc.)

We use ELRP in conjunction with LAG ports in many scenarios with both current and superannuated firmware versions and have never encountered any issues

which switch? is it X460 with XGM module.

Reply

    Back to top