Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
On a Cat9400, when modifying the configuration of the interfaces by overwriting the running-config with a configuration file loaded in flash, we observe that some of the ports fail to authenticate the endpoints with MAB. before confi switchport access vlan 220 switchport mode access switchport voice vlan 358 ip arp inspection limit rate 20 no cdp enable ipv6 nd raguard authentication event fail action authorize vlan 220 authentication event server dead action authorize vlan 220 authentication event no-response action authorize vlan 220 authentication event server alive action reinitialize authentication host-mode multi-domain authentication order dot1x mab authentication port-control auto authentication periodic after config switchport access vlan 1662 switchport mode access switchport voice vlan 358 ip arp inspection limit rate 20 no cdp enable ipv6 nd raguard authentication event fail action next-method authentication event server dead action authorize vlan 1662 authentication event no-response action authorize vlan 1662 authentication event server alive action reinitialize authentication host-mode multi-domain authentication order dot1x mab authentication port-control auto authentication periodic The affected interface doesn't initiate DOT1X authentication. It doesn't affect all of the ports configured, only some of them.
Configuration change is performed by loading a config file (intended config) into the flash, and then replacing the running with this file. The MAC address on the affected port points to DROP. There are no syslog messages from the affected interface in terms of DOT1x at the time of the issue.
Shut down the port before making config push. Bring the port up after the config push. Reload the switch. Use IBNS 2.0
As part of the root cause of this issue, when running IBNS1.0 mode many of the authentication CLIs configured on the port would result in the policy to get deleted and a new policy to be generated. Client is getting connected when the policy is being re-generated and is not yet complete. Since, any such config can trigger this issue, there could be numerous other scenarios where the clients could get stuck in an incorrect state even after successful authentication. This issue is not going to be handled gracefully at the software level due to the implications it may take with several internal components.