topic RE: Share group vanishes after reboot in ExtremeSwitching (EXOS/Switch Engine)

Share group vanishes after reboot

davidj_cogliane — Thu, 16 Aug 2018 19:38:00 GMT

I believe I understand why the issues occurs, but am curious if it is expected behavior or a bug. See config below (I don't how how we managed to configure it)

1:17 LACP 1 L2 A 1:17 - R 2
L2 1:18 - R 0
L2 2:17 - R 0
L2 2:18 - R 2

Port: 1:17(to_Firewall):
Virtual-router: VR-Default
Type: 1000T
Random Early drop: Unsupported
Admin state: Enabled with auto-speed sensing (1G Advertised), auto-duplex
Port: 1:18(to_Firewall):
Virtual-router: VR-Default
Type: NONE
Random Early drop: Unsupported
Admin state: Enabled with 10G full-duplex
Port: 2:17(to_Firewall):
Virtual-router: VR-Default
Type: NONE
Random Early drop: Unsupported
Admin state: Enabled with 10G full-duplex
Port: 2:18(to_Firewall):
Virtual-router: VR-Default
Type: 1000T
Random Early drop: Unsupported
Admin state: Enabled with auto-speed sensing (1G Advertised), auto-duplex

Obviously you can't have an LACP share group with different speed ports but as you can see it is configured and functions. The behavior that we noted was that even though the config was saved the share group was gone after a reboot.

My theory is as follows:
The switch must load the config line by line after the reboot. The port speed loads before the share group is created so the share group line fails to load and is removed from the config.

Am I correct?
Is this expected behavior or a bug?
Or is the bug whatever loop whole allowed us to create the config?

I would argue that anything that causes or allows the config to be changed by a reboot is a bug.

Thanks,

Forgot to mention:

summitX-21.1.4.4-patch1-6.xos
Slot-1 X670G2-48x-4q X670G2-48x-4q Operational 64
Slot-2 X670G2-48x-4q X670G2-48x-4q Operational 64

RE: Share group vanishes after reboot

Ronald_Dvorak — Thu, 16 Aug 2018 19:45:00 GMT

What if I've the 10G SFP+ in the chassis > configure it > replace half the 10G SFP+ with 1G.

no idea whether that makes sense 

RE: Share group vanishes after reboot

davidj_cogliane — Thu, 16 Aug 2018 19:45:00 GMT

Yes,
I did wonder if we created the share group then inserted the 1G optic and that changed the advertised speed which created the conflict.

I really think that is what we did, but I guess I didn't think inserting an optic would write a line to the config.

RE: Share group vanishes after reboot

Ron_Huygens — Thu, 16 Aug 2018 19:45:00 GMT

Interesting topic.
In my lab I was not able to replicate. I tried several scenarios and most of the times it was simply denied by EXOS.
Only inserting the 1000T will not show an error but in all cases the share will stay in the config after a reboot.

Any change that you can remember the exact order of steps?

RE: Share group vanishes after reboot

davidj_cogliane — Thu, 16 Aug 2018 19:45:00 GMT

Looks like I recreated the issue below. Inserting the 1G optic changes the config making the share group invalid, so the share group disappears after the reboot. I trimmed the output but did not eliminate any commands. I have the unedited session log which I can email if anyone would like it.

Slot-1 Stack.6 # enable sharing 1:1 grouping 1:1,1:2,2:1,2:2 lacp algorithm address-based L2
Warning: Any config on the master port is lost (IGMP Filter, IGMP Static Group, MAC-Security, CFM, TRILL etc.)

* Slot-1 Stack.7 # sho sharing
Load Sharing Monitor
Config Current Agg Min Ld Share Dist Ld Share Agg Link Link Up
Master Master Control Active Algorithm Flags Group Mbr State Transitions
================================================================================
1:1 LACP 1 L2 A 1:1 - R 0
L2 1:2 - R 0
L2 2:1 - R 0
L2 2:2 - R 0
================================================================================

* Slot-1 Stack.9 # sho sharing
Load Sharing Monitor
Config Current Agg Min Ld Share Dist Ld Share Agg Link Link Up
Master Master Control Active Algorithm Flags Group Mbr State Transitions
================================================================================
1:1 LACP 1 L2 A 1:1 - R 0
L2 1:2 - A 1
L2 2:1 - A 1
L2 2:2 - R 0
================================================================================

* Slot-1 Stack.10 # save
The configuration file primary.cfg already exists.
Do you want to save configuration to primary.cfg and overwrite it? (y/N) Yes
Saving configuration on master ..... done!
Synchronizing configuration to backup ..... done!

Slot-1 Stack.11 # sho port 2:1 info detail
Port: 2:1
Virtual-router: VR-Default
Type: 1000T
Random Early drop: Unsupported
Admin state: Enabled with auto-speed sensing (1G Advertised), auto-duplex

Slot-1 Stack.12 # reboot
Are you sure you want to reboot the stack? (y/N) Yes
The system is going down NOW!

login: admin
password:

Slot-1 Stack.1 # sh sharing
Load Sharing Monitor
Config Current Agg Min Ld Share Dist Ld Share Agg Link Link Up
Master Master Control Active Algorithm Flags Group Mbr State Transitions
================================================================================
================================================================================
Link State: A-Active, D-Disabled, R-Ready, NP-Port not present, L-Loopback

RE: Share group vanishes after reboot

Ron_Huygens — Thu, 16 Aug 2018 19:45:00 GMT

I recreated this as well and I think it is expected behavior in this very specific situation.
This is only seen with the 1000T gbic.

As soon a 1000T is inserted we see the following in the log:
08/20/2018 11:02:36.07 Slot-1: Media 1000T is inserted into Port 2:1
08/20/2018 11:02:36.07 Slot-2: The configuration for the 1000T optic module is not correct - please configure port 2:1 for auto-negotiation On and speed 1000
08/20/2018 11:02:36.07 Slot-1: Port 2:1 was changed to auto negotiation on due to 1000BaseT GBIC.

From that moment there is indeed a config change (you will see the dirty bit in the prompt) and when you save the config, the sharing will be illegal upon a reboot.
We can argue about the question that the switch should not accept the gbic when it is inserted in a existing share group.

RE: Share group vanishes after reboot

davidj_cogliane — Thu, 16 Aug 2018 19:45:00 GMT

I like that the optic is supported.

I would argue that it shouldn't write a line to the config. If the config loaded without the change then when the port became active things would have worked fine.

But that's all I have. It works fine if the port speed is configured before creating the share group.

Thanks,