ISE is Profiling an IP Phone Incorrectly?

[Matthew Martin]

Hello All,

Cisco ISE: v2.0.0.306
Switch: 3560
IP Phone: 7941G

I have had many other 7941G IP Phones connected to this switch, which have all profiled/authenticated correctly.

The only difference between those phones and this one, is that this phone has not been powered on in probably a few years (*long before ISE was setup).

So I plugged the phone into the switch and after the phone powers-up its stuck on "Configuring IP". The "show auth session" command shows it attempting to auth with dot1x, which would fail as expected. However, it should pass the MAB auth, since its an IP Phone. But, the phone fails MAB authentication as well. And looking on the ISE Server's Radius LiveLog I can see the IP Phone is getting Profiled as "Cisco-Device" instead of "Cisco-IP-Phone-7941".

Also, I'm seeing something I've never seen before, as far as I can remember. Looking at the mac address-table, the phone is showing "Drop" under where the port should be. Does that have to do with it failing authentication?

Vlan    Mac Address       Type        Ports
----    -----------       -------     -----
 114    fcfb.fbcb.5eca    DYNAMIC     Drop

*Also, Vlan 114 shown above is the DATA Vlan. Voice Vlan is 124...

If I check the CDP on that port (*last device listed below), it is showing the device correctly, so I'm not sure what the problem is.

JWP-3560sw1-SP#show cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone, 
                  D - Remote, C - CVTA, M - Two-port Mac Relay 

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
ISR4321          Fas 0/2           135             R S I  ISR4321/K Gig 0/0/0
4510R-HQ         Fas 0/1           164             R S I  WS-C4510R Gig 9/22
VG202XM-MRM      Fas 0/3           152              R B   VG202XM   Fas 0/0
SEPFCFBFBCB5ECA  Fas 0/25          125             H P M  IP Phone  Port 1

The IP Phone is plugged into Fa0/25, which you can see in the CDP above...

Any idea what could be the problem here?

Thanks in Advance,
Matt

[andrewswanson]

Hi Matt
apologies - misread your config - link in last post explains ACL scenario with closed mode as well.

1 - enable dhcp snooping on switches with clients - in short "DHCP snooping acts like a firewall between untrusted hosts and trusted DHCP servers" - configure the uplinks from your access switches as trusted. Check the following links for details

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/4_1/nx-os/security/configuration/guide/sec_nx-os-cfg/sec_dhcpsnoop.html
https://supportforums.cisco.com/discussion/12145716/ise-and-dhcp-snooping

2 - not sure if an ios upgrade "converts" the radius host command to the new syntax - like any upgrade it would be wise to test this before upgrading your production network.

hth
Andy

[Matthew Martin]

Hey Andy, thanks again for the reply.

I get which ports I should set as "trusted" on most of our switches, using the uplink ports (*any port that links to the 4500 where the ISE/dhcp servers are directly connected).

But, what about the 4500 switch, which is our main/core-switch.? Which port(s) should be set as trusted on there?


As for the "radius-server host" command... I was more referring to converting the command now, before the switch is upgraded. Because the 4500 seems to accept both forms of the command. So if I were to remove the current "radius-server host ..." command, and replace it with "radius server <name>" command. Would that be something that should be done after-hours?

I wasn't sure if I removed that current command and replaced it with the non-deprecated version, if that would unauth the clients connected to the switch and force everyone to have to re-authenticate, or something along those lines...

Thanks Again,
Matt

[andrewswanson]

Hi Matt

dhcp snooping is a L2 security measure. From your previous posts it looks like your dhcp pools are located on your 4500 - in that case configure "trust" on access switch links connecting to the 4500. If you require dhcp messages to reach ISE (which will be on a differnet subnet from your clients) - you have to configre a helper address on the client vlan svi - see links below:

https://mrncciew.com/2012/12/27/understanding-dhcp-snooping/
http://packetpushers.net/five-things-to-know-about-dhcp-snooping/

If you rely on RADIUS for authorising/authenticating clients it would be best to make RADIUS changes during a maintenance window

hth
Andy

[Matthew Martin]

Ok, that makes sense. So you want any port where a switch connects to (*where that switch would have DHCP clients connected to it), to be a trust'ed port. So if my 3560 switch is on Gi3/25 I would set Gi3/25 as trusted... So, can you think of it as: any port where DHCP messages would need to be "relayed" through, should be a trusted port, if that makes sense...?

Also, you are correct that our Voice Vlan's DHCP Pool is on the 4500, but mostly all of our other pools are located on a Linux VM inside a UCS server, which is part of a Port-Channel. So would I want to "trust" that whole port-channel that the UCS server's port is a part-of on the 4500? It looks like the "ip dhcp snooping trust" command is available on Port-Channels.

One last thing... The 3560 switch is connected to the 4500 on port Fa0/1 (*3560's port), which I had set as a trusted port for dhcp snooping, which from you explanation sounds correct. I also have a Access Point connected to a port on the 3560 as well. So would an Access Point fall under that same category and would need to be set as trusted as well? I wasn't sure about this since wireless clients connecting through this access point would require dhcp to get an address... But, maybe in the case of wireless, only the Wireless Controller would need to be trusted?


Thanks Again,
Matt

[andrewswanson]

Yes - set any L2 uplink as trsuted. Your dhcp server will be on a differnet subnet so you'll already be using a helper address on your client vlan SVI to forward dhcp messgaes to it. Your lightweight AP tunnels all traffic back to WLC so need to trust AP interface.

hth
Andy

[Matthew Martin]

Ok, sounds good. Thanks for all the help Andy! Very much appreciated!

Thanks Again,
Matt

[BrianPersaud]

Did this ever work out?  I have the same problem.

[CherryPie666]

I have the same issue too.. My switches are Meraki MS. I have one Cisco phone 7821 authenticating and profiled correctly during the test and before roll-out on all the switches. The Cisco 7812 phones are just being profiled as "Cisco Device" and not hitting the authorization rule, so DenyAccess...

CDP/LLDP is enabled on the ports to the phones.

[Greg Gibbs]

AFAIK, Meraki still has no support for Device Sensor so ISE will not get CDP information about the endpoint. I believe the profiling considerations stated in this document are still accurate.
How To: Integrate Meraki Networks with ISE

Any further questions regarding the Meraki MS capabilities should be directed to the Meraki Community.

[CherryPie666]

I have it working though... but the MAC address of the Cisco Phone needs to be authenticated first. I have done this through a static MAC address list. Once it authenticates and I then remove the MAC address from the Group, the Cisco Phone is profiles correctly.

Any one has an idea on how I can get this done through the ISE policy ? So, make sure the Cisco phone authenticates.. some sort of a catch all rule ?? When then the port on the switch is bounced, the request hits the correct Authorization Policy rule with the Cisco Phone profile...and the Cisco Phone is allowed.