IDLE timeout and probing for access-session IBNS2.0

[tommy182]

Hello Friends!

In IBNS 2.0 Deployment Guide I read that we can define IDLE timeout for our access-session in policy

If we use additional "probe" parameter switch have to check availability of silent endpoint(arp probing)

I defined service template for inactivity timer with probing.

service-template INACTIVITY-TIMER
 inactivity-timer 60 probe
......
event authentication-success match-all
 10 class always do-until-failure
  10 activate service-template INACTIVITY-TIMER
event inactivity-timeout match-all
 10 class always do-until-failure
  10 unauthorize
.......

If I understand correct it must instruct the switch to probe endpoint every 30 seconds of inactivity.

But it doesn`t work this way.

Default timer for arp-probing(device-tracking) on switch is 300 seconds and it doesn`t changed even if we applied those sevice-template.

In the end after 60 seconds of inactivity host will become unauthorized because switch didn`t adjusted arp-probing timer.

Guide says

Intelligent Aging

When the inactivity timer is enabled, the switch monitors the activity from authenticated endpoints.
 When the inactivity timer expires, the switch removes the authenticated session.
.........
To counter these types of cases, an arp-probe can be enabled along with the inactivity-timer, so that the switch periodically sends ARP probes to endpoints in the IP Device Tracking table. As long as the endpoint is connected and responds to these probes, the inactivity timer is not triggered, and the endpoint is not inadvertently removed from the network.
.........

Please help me to understand does the ARP_Probe timer adjustes himself accordingly to inactivity-timer settings with "probe" keyword or not.

Thanks in advance,

Tom

[Andreas Jaeger]

I tested it on 9300 with 16.9 -> It works there.

"show device-tr database" shows adjusted "Time left" value.

Sorry Tommy- I know it doesn't help in your case, but might be helpful for other users.

[franklinb]

I have the same problem and have had to disable all inactivity timers for our IBNS2 deployment. Also you should not use 'unauthorize' action for inactivity-timeout event. We ran into a lot of issues with this and changed to 'clear-session' which works much better.

We are running 16.9.4 for this config and found silent hosts like security devices would drop their auth after inactivity period - clearly the probes are not working.

I got my info from that IBNS2 CiscoLive slide which had the interface level command as well. I don't really understand how those two work together.

service-template IA-TIMER
inactivity-timer 60 probe
policy-map type control subscriber AI_DOT1X_MAB_POLICIES
....
event authentication-success match-all
10 class always do-until-failure
10 activate service-template DEFAULT_LINKSEC_POLICY_SHOULD_SECURE
20 activate service-template IA-TIMER
event inactivity-timeout match-all
10 class always do-until-failure
10 clear-session
template STD_PORT
..
subscriber aging inactivity-timer 30 probe
authentication periodic
authentication timer reauthenticate server
service-policy type control subscriber AI_DOT1X_MAB_POLICIES

[Leroy Plock]

Did you ever get an answer to this? I believe we are experiencing the same issue, the probe simply doesn't work in 16.9.4. Cisco is trying to claim that it's a cosmetic issue a la CSCvs40355 but I think they're wrong. I see no evidence the probe is working, and probe failure completely explains our symptoms. "Quiet" endpoints session evaporates at the end of the inactivity-timer.

[JasonLeschnik]

Hi all,

Thought I'd reply here to possibly help someone else who is in the same situation. We spent about 4 months with our VAR and Cisco trying to get to the bottom of this. It required a TAC Team Leader (TL) to finally step in and tell us the issue we're seeing.

I've asked repeatedly for TAC to update the bug CSCvs40355 with some "hints" or "notes" mentioning this behavior change, but they've ignored my requests. 

Fix

TAC Mentioned that due to back-end changes in 16.x onwards, that the probe feature must be explicitly enabled using the following:  

Source for above screenshot: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/16-12/configuration_guide/sec/b_1612_sec_3850_cg/configuring_ieee_802_1x_port_based_authentication.html

Source for above screenshot: https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9000/white-paper-c11-743346.html

I'm still really upset that TAC didn't put any notes in the bug to guide people with the symptoms of the bug to the correct documentation. Also, if in 16.x code the functionality has been removed or disabled... it should either give a "WARNING:" or mention the functionality is deprecated. That's not a cosmetic issue, that's a bug in the CLI parser. So I guess it's possible that with this bug, due to it being RADIUS driven, it's not the same issue. But I don't see why if it's a common hit for our problem, not to put notes in this bug for travelers.