cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
1827
Views
10
Helpful
4
Replies
Highlighted

Device-Tracking Set , Authentication Session Detailed IP Missing

This is a unique issue as TAC has been having a hard time figuring it out.  One minute it starts working, another it doesnt.  So to break it down, we are using:

 

Not Working

Catalyst 9410 -- Latest version 16.9.4 with two patches.

 

Working

Catalyst 4506

   --Same usual configuration.  Works flawlessly.

 

What RADIUS?

ISE 2.6 - Base License -- Uses same policies for both.  So we know that is not the issue.

 

Now, you would believe its just a cut-and-paste of the configs..not so.  So here is what I have, I hope you all can shed some light as I'm hitting a dead end here.

 

ip dhcp snooping glean
ip dhcp snooping vlan 200,400, 800
no ip dhcp snooping information option

        --They said this is not supposed to work, but this is causing it to sort-of-work.
ip dhcp snooping

 

device-tracking logging packet drop
device-tracking logging theft
device-tracking tracking auto-source fallback 0.0.0.10 255.255.255.0 override
device-tracking tracking retry-interval 30

!

authentication critical recovery delay 1000

!

switchport access vlan 200
switchport mode access
switchport voice vlan 800
spanning-tree portfast
auto qos voip cisco-phone
spanning-tree bpdufilter enable
authentication control-direction in
authentication host-mode multi-auth
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication periodic
authentication timer reauthenticate server
authentication violation restrict
authentication event fail retry 3 action authorize vlan 400
mab

dot1x pae authenticator
dot1x timeout tx-period 10
qos trust device cisco-phone

!

radius-server attribute 6 on-for-login-auth
radius-server attribute 6 support-multiple
radius-server attribute 8 include-in-access-req
radius-server attribute 32 include-in-access-req format %h
radius-server attribute 25 access-request include
radius-server attribute 31 mac format ietf
radius-server dead-criteria time 10 tries 3
radius-server vsa send cisco-nas-port

 

 

If looking at show device-tracking database.  It shows all is reachable; cool.  

If looking at show authentication sessions interface Blah/Blah/Blah detail.  It shows:

 

Interface: GigabitEthernetBlah/Blah/Blah
IIF-ID: 0x16105801
MAC Address: 0080.64f1.4ba6
IPv6 Address: Unknown
IPv4 Address: Unknown
User-Name: 00-80-64-F1-4B-A6
Status: Authorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: in
Session timeout: N/A
Common Session ID: 0B6410AC000000F311D980CA
Acct Session ID: 0x000000d4
Handle: 0x8a0000e2
Current Policy: POLICY_GiBlah/Blah/Blah


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

Server Policies:
ACS ACL: xACSACLx-IP-DATA_THINCLIENT_ACL_backup-5e7a240c

 

Method status list:
Method State
mab Authc Success

 

So the Authentication is a success. 

The VLAN is where it should be

The dACL is what it should be (includes bootps and bootpc in the dACL)

if its voice phone, its where it should be

if its a guest it gets blackholed (as it should be)

after next business day, I can't connect to it any longer.  So since then I put in:

                device-tracking binding down-lifetime 600

                device-tracking binding reachable-lifetime 86400

                device-tracking binding stale-lifetime 600

 

If I look at ISE RADIUS Logs, it reads and authenticates, but does not show the IP address.

 

I can ping, https to it but it does not show correctly on there as it shows up on the database and the core arp logs up stream.  I have other ports within the same switch that is not using RADIUS and it works well too.  What am I missing?

 

 

4 REPLIES 4
Highlighted
Cisco Employee

With the newer IOS-XE code, you should be using the SISF-based Device Tracking feature as shown in the ISE Secure Wired Access Prescriptive Deployment Guide. I can't tell from your configuration  snippet, but it doesn't look like this is configured.

If you haven't done so, try using the following configuration example:

Sw(config)#device-tracking policy IPDT_POLICY
Sw(config-device-tracking)#tracking enable
Sw(config-device-tracking)#no protocol udp
!
interface GigabitEthernet x/y/z
device-tracking attach-policy IPDT_POLICY

Highlighted

Hello and thanks for replying,

 

I have that configured and have it set for one interface:

device-tracking policy IPDT_POLICY
trusted-port
no protocol udp
tracking enable

 

Policy IPDT_POLICY configuration:
trusted-port
security-level guard
device-role node
gleaning from Neighbor Discovery
gleaning from DHCP
gleaning from ARP
gleaning from DHCP4
NOT gleaning from protocol unkn
tracking enable

 

 

The rest are on the default.

 

Policy DT-PROGRAMMATIC configuration:
security-level glean
device-role node
gleaning from Neighbor Discovery
gleaning from DHCP
gleaning from ARP
gleaning from DHCP4
NOT gleaning from protocol unkn
limit address-count for IPv4 per mac 1
tracking enable

 

So the total for all

Gi2/0/6 PORT IPDT_POLICY Device-tracking vlan all
vlan 200 VLAN DT-PROGRAMMATIC Device-tracking vlan all
vlan 400 VLAN DT-PROGRAMMATIC Device-tracking vlan all
vlan 800 VLAN DT-PROGRAMMATIC Device-tracking vlan all

 

So far today (knock on wood) since I wrote the post that the global commands are working and is showing reachable.

device-tracking logging packet drop
device-tracking logging theft
device-tracking tracking auto-source fallback 0.0.0.10 255.255.255.0 override
device-tracking tracking retry-interval 30

device-tracking binding stale-lifetime 600

device-tracking binding reachable-lifetime 86400

device-tracking binding down-lifetime 600

 

But it has not been 24 hours so this may have an effect later.  the devices rarely move so this would not be a bad thing.  Cisco did create that, applied, and was still not working until they put in the "no ip dhcp snooping information option", but shortly after it went down again.  From your knowledge what did I put in is wrong, what is right, and why it was being wonky despite your aligning knowledge with TAC?  

Highlighted
Cisco Employee

As this specific IOS-XE 16.x and likely specific Catalyst 9400-series, I moved this thread to Switching.

IP Device Tracking New CLI - SISF - Denali 16.3.5 might be of interest to you.

Highlighted

Hello all, so it appears that it is working now still and has not faltered.  So the global commands worked.  I will be continuing to slowly implement other ports to ensure they are working properly.  Both the port that has a separate policy and the default policy both work.  If all floors work but ISE is having another issue, like being able to display the RADIUS logs correctly, I will move on to the next section on here and link it to the response.

 

To be fair with other peoples suggestions, yes under a typical scenario 9/10 that would work.  For some reason mine required more configuration for it to work.  I am still open into giving information if others are willing to take a crack what could of caused it as I have no idea.

 

Configs in relation:

==========================================================

 

device-tracking binding down-lifetime 600
     #After its been down for 10 minutes, it will discard the entry.

 

device-tracking binding reachable-lifetime 86400
     #This will keep it reachable for 24 hrs. If yours is a highly dynamic environment, don't have this up so high.

 

device-tracking binding stale-lifetime 600
     #This will give it 10 minutes to be stale until its discarded

 

device-tracking tracking auto-source fallback 0.0.0.10 255.255.255.0 override
     #This is used if ARP is causing Conflicts, it will use a IP address (192.168.1.10/24) as a backup to continue. In documentations it says .1, but there has been several people voting against this as .1 is used as the gateway and it can be confusing. So instead, just have it use its own IP that nobody else uses. Must be on Layer 2 Only.

 

device-tracking tracking retry-interval 30
     #If there is link problems (flapping, duplicate IP addresses like my THIN Clients default IP address), this will check it again.

Content for Community-Ad