IBNS 2.0 Policy Map Retries/Retry-time vs Interface configuration?

[jacob.fredriksson]

Hello everyone!

I have been going through some documentation for IBNS 2.0 templates and have some questions regarding 802.1x retries and timeout.

When using IBNS 2.0, you can set the 802.1x number of retries and retry-time between attempts directly in an Event in the Policy Map, such as the ones below.

Snipped of IBNS 2.0 Policy Map below:

policy-map type control subscriber PMAP_DefaultWiredDot1xClosedAuth_1X_MAB
  event session-started match-all
   10 class always do-until-failure
     10 authenticate using dot1x retries 2 retry-time 0 priority 10

....

....

   event agent-found match-all
  10 class always do-until-failure
    10 terminate mab
    20 authenticate using dot1x retries 2 retry-time 0 priority 10

But these values can also be set directly on an interface, using the commands below:

For example:

interface Gi 1/0/1

   dot1x timeout tx-period 5
   dot1x max-reauth-req 3

My questions are:

1) Do the 802.1x timeout/retries interface commands override the Policy Map events timeout/retries?

2) What is the actual result of "retry-time 0"? Does this mean the switch will send all EAP Requests to the endpoint immediately when the link goes into UP state, without a waiting period between each attempt? Does it have some special use-case exclusive to IBNS 2.0 deployments, since you cannot use "dot1x timeout tx-period 0" on an interface, this command must have a parameter of "1-65535".

3) If the answer to question 2 is "Yes" (meaning all EAP Requests are sent at once and if no answer from endpoint = proceed with MAB instead), are we supposed to count on the "agent-found" event to trigger 802.1x authentication on endpoints where it should be used, in a scenario where the endpoint wasn't able to respond to the EAP Requests that was sent immediately from the switch on link state UP? I can imagine there are scenarios where a PC might put its wired NIC in an UP state pretty quickly on boot-up but maybe not being ready for EAP authentiction right away. Should we count on the PC sending EAPoL Start message to the switch to initiate the 802.1x authentication?

Best regards

Jacob

[Arne Bier]

Great questions. The entire IBNS thing is event driven and any packet can come from the switch at any time and in any order. 

And also, we cannot predict what the endpoint's operating system will send first (e.g. I have seen devices that have supplicants, but that part of the code takes a while to initialise ... and so you see a few DHCP discovery packets before you see the first EAPOL frame).

I have been hoping that one day we get a state diagram showing how a switch processes frames on a NAC enabled port.

My answer to question number 3 is that you have to make the IBNS policy cycle around until it finds an authentication that succeeds.

In most cases (and I guess, the ideal case) is that 802.1X is preferred over MAB - and also, you check EAP first, and then timeout and try MAB. If 802.1X times out and the DHCP triggers a MAB, which gets an Access-Accept, then the MAB will win. But if you have an Agent-Found class then that will still flip the session into 802.1X if 802.1X has a higher priority than MAB.

Funky things happen when you tell IBNS 2.0 to accept 802.1X and MAB simultaneously. Only one can succeed. So if you decided to reject unknown endpoints in ISE, then you might see lots of failed MABs and successful 802.1X auth (for endpoints with supplicants).

I suggest testing in the lab ... and then when you think you know how it works ... test it again

[jacob.fredriksson]

Thank you for your comments, Arne!

In my usual template for IBNS 2.0 switch configuration I haven't included the "retries 2 retry-time 0" parameters (yet), but I've been seeing more and more documentation and examples using these parameters, which is why my initial questions started to surface. First time seeing these parameters was when a colleague of mine configured a switch using DNA Center, and when I took at look at the configuration, the "retries 2 retry-time 0" was a part of it.

I set up a small lab just now with two different switches to test the effect of these parameters:

• Switch1 was a C3560CX-8PC-S running IOS 15.2(7)E2.
• Switch2 was a C9200L-48P-4X running IOS-XE 17.3.4.

After putting in my IBNS 2.0 configuration and connecting a PC (running Wireshark) to a switch port, the result was that the "retries 2 retry-time 0" parameter seems to do nothing at all in terms of number of authentication attempts or the timeout between them.

No matter which combination of values I tried, it seems that the configuration on the interface it the one that matters. Even when I removed all interface configuration (using the commands "no dot1x timeout tx-period" and "no dot1x max-reauth-req"), the configuration in the Policy Map event didn't affect the retry/retry-time, the switch simply started using the interface defaults instead (which is 30 seconds timeout period and 2 re-attempts, which can be seen using the command "show dot1x interface Gi0/1" and I confirmed it in Wireshark). Between my attempts, I tried removing and re-applying the port configuration to make sure nothing was "stuck" in terms of logic, and I even rebooted both of the switches a few times. Nothing seems to make a difference.

Part of me thought that since IBNS 2.0 has moved a lot of the interface configuration to global settings/templates via C3PL, maybe this was just one more step to get rid of configuration directly applied on the interfaces themselves, but now I don't really know what to believe.

Cisco's own documentation says very little of these parameters. The description of both ways to configure these retry/timeouts are so very similar, but the values you can put differ from each other (like I quickly mentioned in my question#2 above):

Policy Map event configuration:

Retries = <1-5>

Retry-time = <0-65535>

Interface Dot1x Configuration:

Max-Reauth-Req = <1-10>

Timeout TX-period = <1-65535>

It would be great to get some kind of confirmation from Cisco what the deal with these parameters are. If they are not working because of a bug or something else, it could be troublesome if they started working for real, for example, after a software upgrade, and you find out that they are causing troubles with your particular environment.

After writing all of this, my last thought it that maybe the "retries 2 retry-time 0" makes changes that are "equal" to these interface commands instead:

interface Gi1/0/1

  dot1x timeout supp-timeout <1-65535>

  dot1x max-req <1-10>

These commands deal with re-transmission of EAP frames only AFTER an EAP authentication has started and for some reason fails mid authentication, due to supplicant failure/error or some weird wire issue.

[thomas]

We had an ISE Webinar on IBNS 2.0 today... hopefully you were able to catch it.

If not, it should be on our CiscoISE YouTube Channel in about 1 week.

Until then, here are the resources from the session if they help you find answers to some of your IBNS questions:

•Cisco Automation Series on Cisco BLOGs
https://blogs.cisco.com/tag/dna-center-automation-series

•Cisco DevNet Automation Exchange
https://cs.co/DNAC-Templates

•GitHub Content
https://tinyurl.com/DNAC-Templates

•Lab Content
https://tinyurl.com/DNAC-Templates-Labs

•SA Prescriptive Deployment Guide
https://cs.co/ISEPrescriptiveDeploymentGuide