Extreme Summit stack randomly decided to give all unlabeled ports a generic display string?

[Justin_Noland]

Hey everyone,

I'm seeing some odd behavior on a handful of my switch stacks. This behavior has only occurred on stacks where a failed node has been replaced. Stacks that have never had a failed node do not display this behavior. That may totally be a red herring, but I wanted to point it out.

The behavior we are seeing is that all ports that did not previously have a display-string configured are now configured with a simple (and useless) name of "switchSNMPname_portnumber". We only have two network engineers with access to our CLI, and neither of us would have (intentionally) done something quite this dumb.

For example, here is the expected output from a good configuration:

Slot-1 MDF.1 # sh vlan eng

Ports: 117. (Number of active ports=88)
Untag: *1:1, *1:2, *1:3, *1:9, *1:10, *1:11, *1:12,
*1:17, *1:18, *1:19, *1:20, *1:26, *1:28, *1:33,
*1:34, *1:35, *1:36, *1:41, *1:42, 1:43, *1:44,
*1:47, *2:10, *2:12, 2:13, 2:15, 2:16, *2:17,
*2:18, *2:20, *2:21, *2:23, *2:26, 2:28, 2:29,

And here is the output from a stack showing the behavior in question:

Slot-1 IDF01.2 # sh vlan eng

Ports: 20. (Number of active ports=7)
Untag: *1:5(IDF01_1:5),1:6(IDF01_1:6),*1:9(IDF01_1:9),*1:10(IDF01_1:10),*1:13(IDF01_1:13),1:14(IDF01_1:14),1:20(IDF01_1:20),
1:21(IDF01_1:21),1:22(IDF01_1:22),1:30(IDF01_1:30),2:21(IDF01_2:21),2:22(IDF01_2:22),4:14(IDF01_4:14),4:28(IDF01_4:28),
4:29(IDF01_4:29),*4:30(IDF01_4:30),6:5(IDF01_6:5),*6:37(IDF01_6:37)
Tag: *1:53bg, *6:53g

As you can see, this makes it super annoying to look at things in the CLI, and we have no idea why it happened. I can go through and manually unconfigure the display strings (and have been) but we are just generally curious what caused this in the first place.

Thanks for any insight!

[Tooley__Akiko]

Hello Justin,

I'm glad we were able to figure out that the issue was port alias was configured in Extreme Management Center (OneView) and that it was pushing out the port alias configuration to the switch.

[Justin_Noland]

An Extreme engineer reached out to me and provided me the following GTAC article:

https://gtacknowledge.extremenetworks.com/articles/How_To/How-do-I-add-a-port-alias-on-a-switch-in-t...

This is exactly what is happening. All otherwise unlabeled ports are configured with a port alias in Netsight, so I assume that even though I manually cleaned up the switches by unconfiguring their display strings, the problem will recur until I correct the alias applied in Netsight. Currently trying to figure out if there is a bulk way to do that, though I'm still confused about how we configured an option we didn't even know existed.

Scratch that last bit, I figured out how to select multiple rows. It looks like this has been resolved for now, other than not knowing the origin of the original alias creation.

[davidj_cogliane]

This sounds exactly like what happened to me. I will let you know if I remember what I did.

[Justin_Noland]

We are running 16.1.3.6 patch 1-9, currently. Planned upgrade to 16.2.2.4 this weekend. All X460-G1's. We do have Netsight configured but currently (in theory) it is just running configuration backups and some SNMP monitoring. I'm looking at that now, per David's comment, to see if maybe we have something in Netsight that is pushing this out to the switches. That said, a) I have no idea what exactly I'm looking for, and b) I'm curious as to why I'm not seeing this behavior across all our stacks, because we aren't doing anything to separate them into discrete management groups in Netsight.