01-23-2024 02:10 AM - edited 01-23-2024 02:59 AM
We are facing issues related to the ATM, Printers they all have static IP adresses. After succcesfull authetication of the MAB it works fine but after sometime maybe 2 hours or 5 hours they get APIPA IP adresss. Issue gets resolved after shut/noshut of the interface or plug/unplug the ethernet wire. We face the issue on the regular basis. We are using cisco ISE 3.2 version and Cisco Catalyst 1000 series switch. Can anyone help us for this issue.
This is the config of the port
description << USER-PORT >>
switchport access vlan 100
switchport mode access
switchport voice vlan 110
authentication control-direction in
authentication event server dead action authorize vlan 100
authentication event server dead action authorize voice
authentication event server alive action reinitialize
authentication host-mode multi-auth
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
mab
dot1x pae authenticator
dot1x timeout tx-period 25
spanning-tree portfast edge
01-23-2024 02:15 AM
I will start check the AAA are it alive or not
if not
then these
authentication event server dead action authorize vlan 110
authentication event server dead action authorize voice
this meaning any device try to auth and AAA dead it get vlan 110 but it is VoIP not data client
MHM
01-23-2024 04:53 AM
If they have a static IP that should never change. This to me sounds like a printer network stack bug.
01-23-2024 05:51 AM
I agree with @ahollifield, if the printers have static IP addresses assigned and the issue is fixed by disconnecting/shut and reconnecting/unshut the ports it seems that there is something wrong on those devices network cards themselves. I would try to contact the vendor asking support, maybe a firmware upgrade would fix the issue.
01-24-2024 11:55 AM
One way to rule out if NAC is the cause, is to remove all the NAC config on one printer port to the most basic commands only.
If by some miracle, removing NAC fixes it, then check if you enable a regular session-reauth when such a printer connects? If so, I would consider removing the session-reauth from the ISE Authorization Profile, and checking if the IP state is more stable as a result. I have had to do that on certain devices that don't handle session-reauth well.
I would think also that Adam and Aref are on the right track with their thinking! But at least prove it by removing NAC for a day.
01-25-2024 03:53 AM
@Arne Bier i have remove the authentication commands from the access port then it works fine without getting the APIPA IP. Issue occurs only when authentication commands are there. we are not doing re-authentication and also i have check after clearing the session from the interface it still shows the apipa ip. Only shut/noshut is the solution. IP Device tracking is enabled by default on switches and if i do show ip device tracking all APIPA IP againt the mab endpoint mac address is visible.
01-25-2024 04:11 AM
you mention static IP and APIPA IP is only for DHCP
so I think you meaning using MAC of printer to assing static IP via DHCP
and as I mention before
show authentication session interface <<- check the domain
show mac address <<- check the vlan appear for printer MAC
MHM
01-25-2024 04:32 AM
If turning off the reauthentication on those ports fixes the issue, then you can disable the reauthentication only for those ports through the authorization profile of those printers in ISE. You can do that via the RADIUS custom attributes.
06-26-2024 08:21 AM - edited 06-26-2024 08:22 AM
Did you ever get this resolved? I have exactly the same issue using ISE 2.7 with Cisco 1000 switches and ATM machines with static addresses. I've just changed the authentication priority and order to MAB first in an attempt to remedy. Was just curious if there was a known fix in your case. Thanks
06-26-2024 08:27 AM
make new post
MHM
01-25-2024 01:18 PM - edited 01-25-2024 01:20 PM
I have another theory. What we know about printers, is that most of the time they don't send any traffic. Therefore, after some time, the authenticated session would become inactive and then session manager might be clearing the session.
Are you using IBNS 2.0? I ran into an issue once with a customer using a certain model of Cisco desk phones. When the phones were idle, they didn't send any packets other than CDP every 60 seconds. And the switch's Inactivity Timer was also 60 seconds. The discrepancy/sync was out by a few micro/milliseconds, but that caused a clearing of the session and re-auth every 60 seconds when the phone was idle. The solution was to decrease the Device-Tracking probe interval to be less than the inactivity timer.
Below is a typical IBNS 2.0 Policy - the important stuff is the last two events
policy-map type control subscriber PORT-AUTH-POLICY
event session-started match-all
10 class always do-until-failure
10 authenticate using dot1x priority 10
event authentication-failure match-first
5 class DOT1X_FAILED do-until-failure
10 terminate dot1x
20 authenticate using mab priority 20
15 class AAA_SVR_DOWN_UNAUTHD_HOST do-until-failure
10 clear-authenticated-data-hosts-on-port
20 activate service-template CRITICAL_DATA_TEMPLATE
30 activate service-template CRITICAL_VOICE_TEMPLATE
40 authorize
50 pause reauthentication
20 class AAA_SVR_DOWN_AUTHD_HOST do-until-failure
10 pause reauthentication
20 authorize
30 class DOT1X_NO_RESP do-until-failure
10 terminate dot1x
20 authenticate using mab priority 20
40 class MAB_FAILED do-until-failure
10 terminate mab
20 authentication-restart 60
60 class always do-until-failure
10 terminate dot1x
20 terminate mab
30 authentication-restart 60
event agent-found match-all
10 class always do-until-failure
10 terminate mab
20 authenticate using dot1x priority 10
event aaa-available match-all
10 class IN_CRITICAL_AUTH do-until-failure
10 clear-session
20 class NOT_IN_CRITICAL_AUTH do-until-failure
10 resume reauthentication
event inactivity-timeout match-all
10 class always do-until-failure
10 clear-session
event authentication-success match-all
10 class always do-until-failure
10 activate service-template IA-TIMER
After any successful authorization, the "authentication-success" event would trigger, and set an IN-TIMER of 60 seconds. If the device does not send any data within 60 seconds, then the "inactivity-timeout" event would clear the session.
In my case, notice the keyword "probe" at the end? It didn't send any ARP probes after 60 seconds. That was part of the problem. We suspected a buggy IOS.
service-template IA-TIMER
inactivity-timer 60 probe
The fix was to make the device-tracking probe more aggressive, by checking every 30 seconds if it gets an ARP response. If it does (because printer is idle, but it's still there and responding to ARP), then it resets the Inactivity-Timer, and session doesn't get cleared.
device-tracking policy IPDT_POLICY
no protocol udp
tracking enable reachable-lifetime 30
In case it's IBNS 1.0 I don't recall if you can achieve the same thing.
Another crucial command, especially for devices that go to sleep, is the "access-session control-direction in" - to support Wake on LAN (WOL)
interface GigabitEthernet1/0/22
description Raspberry Pi
switchport access vlan 200
switchport mode access
switchport nonegotiate
switchport voice vlan 100
device-tracking attach-policy IPDT_POLICY
ip access-group PREAUTH_ACL in
power efficient-ethernet auto
authentication periodic
authentication timer reauthenticate server
access-session control-direction in
access-session port-control auto
mab
dot1x pae authenticator
spanning-tree portfast
spanning-tree bpduguard enable
spanning-tree guard root
service-policy type control subscriber PORT-AUTH-POLICY
Might be worth investigating - do whatever you can to check that the session never goes inactive, and use the ARP probing to keep it alive.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide