ISE 802.1X Lab: Fixing 11007 "Could not locate Network Device" on a Wired Switch

The first wired 802.1X test against a new ISE deployment usually fails. One of the most common reasons is also one of the quietest: ISE gets the RADIUS request and drops it without replying, because the request comes from an IP address it has no network device for. In Live Logs that shows up as 11007 Could not locate Network Device or AAA Client.

I built this in my home lab to show that failure end to end. I set it up the way it often goes wrong in real networks: the switch is added to ISE using the address people know it by, while RADIUS is actually sent from a different interface. Then I fix it and walk through what success looks like on ISE, on the switch and on the client.

If you haven't brought ISE up yet, start with Cisco ISE 3.5 Initial Setup: CLI Checks and First GUI Login. For a broader look at the switch side, see the Cisco ISE 802.1x Wired Configuration Guide.

The lab

The switch runs Cisco IOSv-L2 15.2 (vios_l2-ADVENTERPRISEK9-M). All switch output below comes from it. Clients use PEAP with EAP-MSCHAPv2 against the ISE internal user store.

The important design point is that RADIUS leaves the switch from Gi0/0 in the management VRF. It does not leave from either user SVI. Keep that in mind.

ISE side: identities and policy

Identity group and users. Under Administration > Identity Management > Groups, I created a user identity group called Wired-Staff. Then I created two internal users, eng-01 and ops-01, under Identities > Users and put both in that group.

Policy set. Under Policy > Policy Sets, a new set called Wired-Access sits above Default. It matches the built-in Wired_802.1X compound condition and uses Default Network Access as its allowed protocols.

Inside the set:

• Authentication policy: the Default rule uses Internal Users.
• Authorization policy:
• Wired-Staff-Permit matches IdentityGroup·Name EQUALS User Identity Groups:Wired-Staff and returns PermitAccess.
• The Default rule returns DenyAccess, so anyone outside the group is refused rather than allowed by accident.

Switch side: 802.1X with RADIUS sourced from management

This is the relevant part of the running configuration on acc-sw1. The shared secret is replaced with a placeholder.

vrf definition MGMT
 description Out-of-band management
 !
 address-family ipv4
 exit-address-family
!
aaa new-model
aaa group server radius ISE
 server name ISE-1
 ip vrf forwarding MGMT
 ip radius source-interface GigabitEthernet0/0
aaa authentication login CONSOLE none
aaa authentication dot1x default group ISE
aaa authorization network default group ISE
aaa accounting dot1x default start-stop group ISE
aaa session-id common
dot1x system-auth-control
!
interface GigabitEthernet0/0
 description OOB management
 vrf forwarding MGMT
 ip address 10.86.255.10 255.255.255.0
!
interface GigabitEthernet0/1
 description eng-pc 802.1X
 switchport access vlan 860
 switchport mode access
 authentication port-control auto
 dot1x pae authenticator
 dot1x timeout tx-period 10
 spanning-tree portfast edge
!
interface GigabitEthernet0/2
 description ops-pc 802.1X
 switchport access vlan 861
 switchport mode access
 authentication port-control auto
 dot1x pae authenticator
 dot1x timeout tx-period 10
 spanning-tree portfast edge
!
interface Vlan860
 description Engineering wired users
 ip address 10.86.60.1 255.255.255.0
!
interface Vlan861
 description Operations wired users
 ip address 10.86.61.1 255.255.255.0
!
ip route vrf MGMT 0.0.0.0 0.0.0.0 10.86.255.1
radius-server attribute 6 on-for-login-auth
radius-server attribute 8 include-in-access-req
radius-server vsa send accounting
radius-server vsa send authentication
!
radius server ISE-1
 address ipv4 192.0.2.10 auth-port 1812 acct-port 1813
 key <RADIUS-SHARED-SECRET>

Three lines decide which address ISE will see in the request:

• ip vrf forwarding MGMT under the server group sends RADIUS through the management VRF.
• ip radius source-interface GigabitEthernet0/0 under the server group pins the source address to Gi0/0.
• With aaa new-model, the NAS-IP-Address attribute follows the source interface too.

So every Access-Request leaves as 10.86.255.10, not 10.86.60.1 or 10.86.61.1.

The aaa authentication login CONSOLE none line is there only so that aaa new-model doesn't lock the console in a lab. Don't copy it into production.

The clients

Both clients use the same wired wpa_supplicant profile, with their own identity. The CA certificate is ISE's EAP certificate, so the client actually checks who it's talking to:

ctrl_interface=/run/wpa_supplicant
ap_scan=0
eapol_version=2
network={
  key_mgmt=IEEE8021X
  eap=PEAP
  identity="eng-01"
  password="<USER-PASSWORD>"
  ca_cert="/etc/wpa_supplicant/ise-eap.pem"
  phase1="peaplabel=0"
  phase2="auth=MSCHAPV2"
  eapol_flags=0
}

wpa_supplicant -D wired -i eth1 -c /etc/wpa_supplicant/wired.conf -t

Break it: add the switch with the wrong address

In Administration > Network Resources > Network Devices, I added acc-sw1 with the Cisco profile, RADIUS enabled and the shared secret. For its IP I used 10.86.60.1/32, the Vlan860 SVI. That's the address the engineering users use as their gateway, so it feels like the switch's address. It isn't the address RADIUS comes from.

What the client sees

eng-pc sends its identity, then hears nothing for about 20 seconds, and finally gets an EAP-Failure. This is trimmed debug output:

1793310397.850466: EAPOL: SUPP_PAE entering state AUTHENTICATING
1793310397.850498: EAP: Received EAP-Request id=1 method=1 vendor=0 vendorMethod=0
1793310397.850507: eth1: CTRL-EVENT-EAP-STARTED EAP authentication started
1793310397.850532: EAP: EAP entering state SEND_RESPONSE
1793310397.850536: EAP: EAP entering state IDLE
1793310418.145818: EAP: Received EAP-Failure
1793310418.145900: eth1: CTRL-EVENT-EAP-FAILURE EAP authentication failed
1793310418.145925: EAPOL: SUPP_PAE entering state HELD
1793310418.145989: EAPOL authentication completed - result=FAILURE

No PEAP method is ever proposed. The conversation stops after the identity, which tells you the problem lies between the switch and ISE, not in the credentials.

What the switch sees

acc-sw1#show authentication sessions interface GigabitEthernet0/1 details
            Interface:  GigabitEthernet0/1
          MAC Address:  0000.5e00.5321
         IPv6 Address:  Unknown
         IPv4 Address:  Unknown
            User-Name:  eng-01
               Status:  Unauthorized
               Domain:  UNKNOWN
       Oper host mode:  single-host
     Oper control dir:  both
      Session timeout:  N/A
      Restart timeout:  N/A
Periodic Acct timeout:  N/A
       Session Uptime:  68s
    Common Session ID:  0A56FF0A0000000E000B463C
      Acct Session ID:  Unknown
               Handle:  0x7F000001
       Current Policy:  POLICY_Gi0/1

Method status list: 
      Method            State 

      dot1x              Running

The counters are the giveaway:

acc-sw1#show aaa servers

RADIUS: id 1, priority 1, host 192.0.2.10, auth-port 1812, acct-port 1813
     State: current UP, duration 183s, previous duration 0s
     Dead: total time 0s, count 0
     Quarantined: No
     Authen: request 8, timeouts 7, failover 0, retransmission 6
             Response: accept 0, reject 0, challenge 0
             Response: unexpected 0, server error 0, incorrect 0, time 0ms
             Transaction: success 0, failure 1

Eight requests, seven timeouts, and zero responses of any kind: no reject and no challenge. A wrong password produces an Access-Reject. A wrong shared secret usually shows up in ISE as a different failure. Silence plus timeouts means ISE dropped the packet before any policy ran.

What ISE sees

Under Operations > RADIUS > Live Logs, the attempt shows as a red entry with no identity. The Misconfigured Network Devices and RADIUS Drops counters at the top each went to 1.

The detail report explains why:

• Event: 5405 RADIUS Request dropped
• Failure Reason: 11007 Could not locate Network Device or AAA Client
• NAS IPv4 Address: 10.86.255.10
• Steps: 11001 Received RADIUS Access-Request → 11017 RADIUS created a new session → 11007 → 5405

The NAS IPv4 Address field is the one that matters. ISE is telling you exactly which address the request came from, and that address doesn't match any network device. Because ISE won't reply to an unknown client, the switch can only time out.

Fix it: match the network device to the RADIUS source

There are two valid fixes:

1. Change the network device in ISE to the address the switch really sends from.
2. Change the switch's RADIUS source to match what ISE already has.

In this design, RADIUS is meant to stay on the management VRF, so the fix belongs in ISE. I edited acc-sw1 and changed its IP to 10.86.255.10/32, leaving the profile and shared secret as they were.

With a lot of switches, it's cleaner to add a device range that covers the whole management subnet. That only works if every switch actually sources RADIUS from that subnet.

Prove it

Client

1793311187.059271: eth1: CTRL-EVENT-EAP-STARTED EAP authentication started
1793311188.485246: eth1: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=13 -> NAK
1793311188.682505: eth1: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
1793311188.685395: eth1: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
1793311189.243273: eth1: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/CN=ise35.example.com' hash=<trimmed>
1793311189.243845: eth1: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:ise35.example.com
1793311189.790894: EAP-MSCHAPV2: Authentication succeeded
1793311192.206940: eth1: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
1793311192.207028: eth1: CTRL-EVENT-CONNECTED - Connection to 01:80:c2:00:00:03 completed [id=0 id_str=]

This time ISE answers:

• ISE proposes EAP-TLS (method 13) first, as Default Network Access allows it.
• The client NAKs EAP-TLS and asks for PEAP (method 25).
• The tunnel comes up against ISE's certificate, and MSCHAPv2 succeeds inside it.

$ wpa_cli -i eth1 status
key_mgmt=IEEE 802.1X (no WPA)
wpa_state=COMPLETED
ip_address=10.86.60.21
address=00:00:5e:00:53:21
Supplicant PAE state=AUTHENTICATED
suppPortStatus=Authorized
EAP state=SUCCESS
selectedMethod=25 (EAP-PEAP)
eap_tls_version=TLSv1.2
EAP TLS cipher=ECDHE-RSA-AES256-GCM-SHA384
EAP-PEAPv1 Phase2 method=MSCHAPV2

$ ping -c 3 10.86.60.1
PING 10.86.60.1 (10.86.60.1): 56 data bytes
64 bytes from 10.86.60.1: seq=1 ttl=255 time=16.026 ms
64 bytes from 10.86.60.1: seq=2 ttl=255 time=21.001 ms

--- 10.86.60.1 ping statistics ---
3 packets transmitted, 2 packets received, 33% packet loss

The first ping is lost to ARP. The rest get through, so the port is forwarding.

Switch

acc-sw1#show authentication sessions

Interface    Identifier     Method  Domain  Status Fg Session ID
Gi0/2        0000.5e00.5322 dot1x   DATA    Auth      0A56FF0A0000000F00175308
Gi0/1        0000.5e00.5321 dot1x   DATA    Auth      0A56FF0A0000000E000B463C

Session count = 2

acc-sw1#show authentication sessions interface GigabitEthernet0/1 details
            Interface:  GigabitEthernet0/1
          MAC Address:  0000.5e00.5321
         IPv6 Address:  Unknown
         IPv4 Address:  10.86.60.21
            User-Name:  eng-01
               Status:  Authorized
               Domain:  DATA
       Oper host mode:  single-host
     Oper control dir:  both
      Session timeout:  N/A
      Restart timeout:  N/A
Periodic Acct timeout:  N/A
       Session Uptime:  51s
    Common Session ID:  0A56FF0A0000000E000B463C
      Acct Session ID:  0x00000002
               Handle:  0x7F000001
       Current Policy:  POLICY_Gi0/1

Local Policies:
    Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)
      Security Policy:  Should Secure
      Security Status:  Link Unsecure

Server Policies:

Method status list: 
      Method            State 

      dot1x              Authc Success

acc-sw1#show dot1x interface GigabitEthernet0/1 details

Dot1x Info for GigabitEthernet0/1
-----------------------------------
PAE                       = AUTHENTICATOR
QuietPeriod               = 60
ServerTimeout             = 0
SuppTimeout               = 30
ReAuthMax                 = 2
MaxReq                    = 2
TxPeriod                  = 10

Dot1x Authenticator Client List
-------------------------------
EAP Method                = PEAP
Supplicant                = 0000.5e00.5321
Session ID                = 0A56FF0A0000000E000B463C
    Auth SM State         = AUTHENTICATED
    Auth BEND SM State    = IDLE

The RADIUS counters now show real conversations. There were 20 challenges for the PEAP exchanges and 2 accepts, one per client. Accounting starts were sent for both sessions:

acc-sw1#show aaa servers | include RADIUS|State|Authen|Response: accept|Account|Request: start
RADIUS: id 1, priority 1, host 192.0.2.10, auth-port 1812, acct-port 1813
     State: current UP, duration 954s, previous duration 0s
     Authen: request 30, timeouts 8, failover 0, retransmission 6
             Response: accept 2, reject 0, challenge 20
             Response: accept 0, reject 0, challenge 0
     Account: request 2, timeouts 0, failover 0, retransmission 0
             Request: start 2, interim 0, stop 0

The timeouts from the broken run stay in the counters. Clear them with clear aaa counters servers all if you want a clean baseline before testing.

ISE

Live Logs shows a green pass for each user, followed by the blue session entries:

The detail report for eng-01 shows the whole path through the policy:

• Event: 5200 Authentication succeeded
• Authentication Policy: Wired-Access >> Default, identity store Internal Users
• Authorization Policy: Wired-Access >> Wired-Staff-Permit, result PermitAccess
• Authentication Protocol: PEAP (EAP-MSCHAPv2)
• Network Device: acc-sw1, NAS IPv4 Address 10.86.255.10, NAS Port Id GigabitEthernet0/1

Checklist for 11007

When Live Logs shows 11007:

1. Open the detail report and copy the NAS IPv4 Address. That is the only address that matters.
2. Search Network Devices for it. Check the mask too, because a /32 on the wrong host is the same as no entry.
3. On the switch, check what decides the source address:
4. ip radius source-interface, either globally or under the server group;
5. ip vrf forwarding under the server group;
6. which interface routes toward ISE.
7. Confirm the symptom on the switch: show aaa servers showing timeouts with zero responses.
8. Fix one side to match the other. Then re-authenticate the port, either by bouncing the client's supplicant or with clear authentication sessions interface Gi0/1, and confirm 5200 in Live Logs.

For a wider view of ISE as a RADIUS server for 802.1X, including other policy options, see Configure Cisco ISE as RADIUS Server for 802.1X.