ISE 2.4 patch 4 & HP H3C Comware 5 - Basic dot1x

[vncnt]

Hi there,

I'm getting stuck with an ISE deployement and HP H3C 5500 Comware 5 switch. Basically, that's a very simple DOT1X configuration, with just PermitAccess and some device-traffic-class=voice attribute to handle IP Phone authentication.

The authentication itself is working like a charm. The problem occurs when the reauth timer is reached : I got two different "red" logs. See attachment : the 1st one seems to indicate that on the first Access-Challenge, the switch is initiating a new EAP session. Meaning the current session is discarded by ISE. The 2nd one refers to an invalid state attribute, session being discarded again.

Looking at a packet capture, I can see that in the first Access-Challenge, ISE sends a state attribute (=1st log). But then, the switch seems to start a new session (still 1st log), meaning the state attribute is not valid anymore. There comes the second log : switch is starting a new EAP session with the state attribute that has been discarded by ISE (=2nd log).

The second log looks like a consequence of the first behavior.

Then, everything is reseted on both sides, a new EAP session is built and the endpoint is authenticated again. The problem is that during the two tenths of second this whole procedure takes, the phone is losing its connectivity and reboots...

Any idea ? Thank you.

BR,

Vincent

[howon]

Have you confirmed that device-traffic-class=voice works with H3C switches? The AVP is Cisco AVP so not sure if it applies to the 3rd party switch like H3C. Also, if the attribute is accepted, then I would suggest looking into 802.1X and RADIUS timers on the switch to address the timing issue.

[vncnt]

Hi,

Yes it is working. I configured it manually for H3C switch, as h3c-av-pair = device-traffic-class = voice and this is working good.

Phones are being put in the voice VLAN while computers and other endpoints are not.

At the moment and for test purposes, the re-authentication timer on the switch is set to 2 minutes, but the behavior is exactly the same if it is set at 2 hours.

I might be wrong, but I have the feeling that this is not timers related, only radius / dot1x.

Thanks

[hslai]

For DOT1X like this, the endpoint is the IP phone but not the switch. Thus, please also check the auth timer(s) on the phone.

[vncnt]

Hi,

What do you mean ? Of course the endpoint is the phone, but the phone never discuss with ISE.

It gets challenged by the switch, and the switch is acting as authenticator, isn't it ?

By the way, I got the same behavior with Windows 7 or Windows 10 supplicant...

Thanks

[hslai]

All three components are involved and each has its own timers, which may influence the outcomes.

It seems CoA-reauth is not working properly. As I do not have such NAD gear myself, I can't comment more. A good workaround is to avoid reauth during business hours.

[vncnt]

Alright, what would you advice for the timeouts on the three devices ?

ISE EAP timeout greater than switch timeout greater than endpoint timeout ?

Thanks a lot

[hslai]

I think they should be about the same value. The first error you got is due to either the switch or the endpoint restarting the EAP conversation while ISE waiting for it. ISE has a fixed timer of 2 minutes.

[vncnt]

Hi,

No it did not help : I configured everything with a 2 minutes timer, still same behavior.

What I'm seeing in the PCAP and in the logs :

- NAD sends a re-auth access-request

- ISE is challenging the NAD, a state attribute is sent

- NAD is starting a new EAP session, the state attribute previously sent is discarded on ISE side (that's a guess, but it would make sense)

- NAD sends a new access-request... which contains the attribute received

- ISE has probably discarded the state attribute, which became invalid, and drop the request

> a new EAP session is starting again

[hslai]

Since re-auth problematic, then just disable it.

[vncnt]

If your car's engine oil consumption is getting high, will you stop using it ? No, you will fix it.

I cannot say " well if a basic feature is not working, let's not use it ".

This is basic DOT1X and according the compatibility matrix, this should work like a charm.

[ethan_11 · Accepted solution]

i think this question solved 

please try config this under your interface 

inter g1/0/3 

undo dot1x multicast-trigger