Cisco 3850 Lost Connection When Using Interface Range Command To Remove Dot1x Commands

[seanharvey15116]

Good Morning,
Using the interface range to remove dot1x commands from Cisco 3850 switchport interfaces, we lost SSH connection to the switch. The interface range was Gi1/0/3 to Gi1/0/47. The router was connected to Gi1/0/48 on the switch. We are trying to determine why using the interface range commands to remove dot1x commands made the switch inaccessible. Could there a memory buffer that could cause the switch inaccessible? Has everyone experienced this same behavior with Cisco 3850?

[Leo Laohoo]

Our switches, running 16.9.5 and 16.12.4, crash when we APPLIED Dot1x into ranged ports.  

[seanharvey15116]

our switch is on 16.09.04. Was there a cash file generated when your switch crash? Was there a bug ID for this issue? 

s1-glsdoedpem#sh ver
Cisco IOS XE Software, Version 16.09.04
Cisco IOS Software [Fuji], Catalyst L3 Switch Software (CAT3K_CAA-UNIVERSALK9-M), Version 16.9.4, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2019 by Cisco Systems, Inc.
Compiled Thu 22-Aug-19 17:33 by mcpre

[Leo Laohoo]

---

@seanharvey15116 wrote:

Was there a cash file generated when your switch crash? Was there a bug ID for this issue?

---

TAC says "the fix is in 16.12.4".  Well, that was a major catastrophe because we walked straight into a major PoE bug that is found in the entire 16.12.X train (16.12.1 to 16.12.4).  The bug "bites" after 8 weeks.  If SMU is applied, the bug "bites" after 4 weeks. 

I also created a new TAC Case yesterday because we have another stack, running 16.9.5, having a memory leak: 

4-RP0 Critical  3977748  3874060 (97%)   103688 ( 3%)   4808000 (121%)

If this is the same bug as my previous TAC Case, the fix is meant to be in, you guessed it, 16.12.4. 

So now, I have a major dilemma:  Regularly reboot stack with memory leak or upgrade to 16.12.4 and regularly reboot the stack every 4 to 8 weeks before the PoE bug bites.

[seanharvey15116]

Good Morning, 

Did Cisco TAC provide you with a Bug ID? 

[Leo Laohoo]

The first memory leak was attributed to a brand-new Bug ID:  CSCvv66845

I am still waiting for the 2nd TAC Case to get analyzed.  

[Leo Laohoo]

TAC has confirmed that the 2nd TAC Case, memory leak on 3850 stack running 16.9.5, is due to the same bug, CSCvv66845. 

NOTE: 

• From what I have observed, this bug gets triggered when the stack is configured for Dot1X.  We have several stacks running this same IOS-XE version but NOT on Dot1X and I do not see any signs of memory leak. 
• Workaround is reboot the stack every <35 weeks. 
• Permanent fix is to upgrade to 16.12.X and run the risk of hitting CSCvv28324, which, cannot be resolved even when SMU is applied.  

[seanharvey15116]

Thank you for the information!

[seanharvey15116]

Thank you for the information.

[marce1000]

                  - You may also want to check the logs when this happens.

 M.