cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3803
Views
14
Helpful
9
Replies

802.1x clients behind Cisco IP Phones..... and the code released this week

I have had a lot of grief with this and thought I had a reasonably stable environment, however.....

I have some Catalyst 3560 PoE switches running the latest 12.2(50)SE1 image. I have a working configuration for STP, QoS, Voice & Access VLANs, Port-Security & IGMP snooping - I stress this is working PERFECTLY. Now I have been playing with wired 802.1x port authentication for a while which again I have sucessfully deployed on ports without IP Phones. I did some more testing with 802.1x clients behind some Cisco IP Phones and after understanding the issues and workarounds I thought I had a working environment. The environment is XP SP3 with the new separate wired 802.1x supplicant, workstations are all in a 2003 AD Domain and the wired 802.1x settings are configured through group policy. I had issues with Windows Server 2003 SP2 not working behind IP Phones but this I put down to the supplicant being different from the new one in XP SP3. MS don't have any plans for Server 2003 SP3 (or XP x64 SP3?) nor can I find any hotfixes to resolve this so it's a 'caveat'.

Anyway I have tested this many times and with XP SP3 and the new supplicant it all seems to work well (only the access VLAN is using 802.1x Authentication, I am not authenticating the IP Phones via 802.1x).

Now today it stopped working and 802.1x clients behind the 7970 IP Phones no longer authenticate. I have spent an hour or so looking at this and the IOS is the same, as is the configuration on the IAS (Radius) server, as are the XP clients. I was scratching my head a bit and then looked at the IP Phone - the software on the phone has been upgraded to 8.5(2) - previously it was 8.4(4). I managed tp downgrade the software via CUCM to 8.4(4) and it now works. I have retested it several times so this is obviously an issue (either a new feature or a bug?) with the latest code for the 7970. I have checked and it's the same codebase for all the latest IP Phones - 7906, 7911, 7931, 7941, 7942, 7945, 7961, 7962, 7965, 7970, 7971 & 7975 which was released on 1st June. I have looked through the release notes and EAP-FAST has been added but this is an update to the EAP supplicant on the phone and not a feature of the 802.1x pass-thru from the attached device. I can find no other 802.1x or EAP references.

Thanks for this, another hour lost :o(

Andy

9 Replies 9

jconi
Level 3
Level 3

Hi Andy,

I don't have the solution, but I can tell you that you're not alone facing this problem, with the 8.5(2) phone Firmware.

Aargh.....

jp

jconi
Level 3
Level 3

Hi Andy,

For me the following worked:

- Add the Root CUCM certificate on the CTL list of the ACS.

- Change the usernames on the ACS database and keep only the device name SEPxxxxxxxxxxxx (remove the CP-79xx-)

- Allow EAP-FAST on the ACS, do not use PAC, Require Client certificate, Disable Client Certificate Lookup and Comparisons.

(Thanks Peter from the Cisco TAC)

rgds

jp

Thanks for the reply jp, however I am not trying to get 802.1x working for the Voice VLAN, just the Access (untagged Data) VLAN. What you describe seems to relate to 802.1x authentication for the actual IP Phone, I am only interested in authenticating the access device on the Native (access, untagged or whatever you care to call it...) VLAN behind the IP Phone. This worked on previous firmware releases but not the 8.5(2) release.

I noticed 8.5(2)SR1 has now been released but there is nothing in the release notes about 802.1x authentication. I'll install it on a test phone and see what happens later this week...

Andy

Hi, Andrew. I'm having a similar issue, with 3560 switches and Vista behind the IP Phones (both 7960 and 7961 models). I was wondering if you can share the workarounds and caveats you found when installing it in your environment.

In my network, when we plug the computer to the cable attached to the phone, it authenticates in 802.1x ok, but if you reboot it then it wouldn't get accepted a second time.

Also, did 8.5(2)SR1 solve your problem ?

Regards

Hi guys,

      I have exactly the same problem and have just found a bug CSCta69051 which looks like the problem. The MTU is being limited by the phone for PC traffic which was not happening previously. Workaround = use older firmware.

You may well have already seen this but I thought it worth mentioning for others with the same problem.

Regards

Mike

Andy,

See the release notes for phone firmware version 8.5.3.  This issue should be resolved there.  I am currently running into the exact problem as you with the exact hardware.

Bug ID:CSCsz59661

A note from my TAC engineer regarding this bug:  "The notes indicate that the hardware needed time to come up before the any packets arrived on the phone port. It talked about resynching to the speed and duplex settings. The fix was to enable the hardware at all times so it always stays up.

They mentioned workarounds as sending in multiple EAPOL start packets which is typical (instead of just 1) and to configure the supplicant to retry when it gets no response. Of course, the problem with the second method is if you connect into a switch with no 802.1x configured, it just keeps retrying. Not sure what configuration options are there for the Microsoft 802.1x supplicant."

Cheers,

Dom

FYI - the phone firmware upgrade did not resolve my particular issue.

Dom

mistr
Level 1
Level 1

Hi Everybody,

     This issue is fixed in 9.0.2sr1s. Tested and works fine on a 7941. Doesn't work on 8.5.2 or 8.5.3. Looks like it is the bug I mentioned earlier re the MTU size.

Regards

Mike

Hi Mike,  Thanks a lot for your feedback on this, I know this is a pretty old story, but I faced this problem too. I had my 802.1x authentication working fine when I plugged my laptop directly in the switch, but as soon as I plugged it behind the IP Phone, it didn't work anymore. I had a Cisco 7965 with the firmware version 8.5(4). I upgraded the Phone's firmware to version 9.1(1)SR1 and the 802.1x authentication just worked fine with my Windows 7 and Windows Vista laptops.  For those who may experience the same problem, I had the following error message on my ACS: Authentication failed : 11500 Invalid or unexpected EAP payload received.  And as I ran some dot1x debug commands on my Cisco Switch, I had some EAP Packet length errors coming up, probably this was related to this MTU size problem, as stated in Mike's reply.  Regards. Yann

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: