Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

"dot1x supplicant controlled transient" breaks my NEAT switch management connection



As per this doco:


I have configured the global command:

dot1x supplicant controlled transient

..on my supplicant switch. After doing so the port refuses to come up and I get CISP errors.


Previous config on the supplicants uplink port:

interface GigabitEthernet0/10
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 100-105,200
 switchport mode trunk
 switchport nonegotiate
 dot1x pae supplicant
 dot1x credentials NEAT
 dot1x supplicant eap profile EAP_PRO

with spanning-tree bpdu-filter


After adding the dott1x supplicant controlled transient I removed the BPDU filter as I thought it would no longer be required.


According to the authenticator switch the supplicant authorises successfully however the line protocol on my management SVI remains down (VLAN 200)

  • AAA Identity and NAC
New Member

So further to this issue I've

So further to this issue I've now discovered this particular switch won't even work the same as my other switch that is not using dot1x supplicant controlled transient


So to make that clear: I have two NEAT switches, identically configured except for different usernames and management IP's (same VLAN). They both authenticate to ISE fine but the second one refuses to communicate on the management or any other VLAN. 

On the authenticator switch I see:

MSBBSWAS01#show cisp interface G6/0/30
CISP Status for interface Gi6/0/30
  Version:     (not negotiated)
  Mode:        Authenticator
  Peer Mode:   
  Auth State:  Idle


New Member

Hi Franklinb, Can you solved

Hi Franklinb, Can you solved the problem?

New Member

Hi, yes I think I have the

Hi, yes I think I have the answer although I never fully tested the exact reproduction of the issue as it depends on the order.

The issue seems to be converting existing old-style configuration on the SUPPLICANT switch to new-style. You may need to add access-session port-control auto to the supplicant port.

In other testing I had not enabled old-style dot1x before converting to new-style and did not experience the same issue, so as I said it seems to be possibly an issue with the conversion script.