Security

I have a setup where switch port is configured for dot1x auth and mab as fallback for ip phones. dot1x is used to authenticate users and mac-auth for avaya phones connected to cisco 3750 switch. Profiling is enabled on both the services and ip-helper address pointing to CPPM is configured under both data and vloice vlan interface. The switch port connects to avaya phone and that connects to a computer. The computers are getting profiled correctly but the IP phones fails to profile, although it gets the DHCP and works fine.

 

For the IP phones that are connected to normal ports (no authentication configuration on the port, only configured for data and voice vlan), the profiling works fine.

 

Any guidance here? What could be the issue?

You may need to take a packet capture on both side and see if the DHCP request / discover are make it to ClearPass



Thank you

Victor Fabian

Pardon typos sent from Mobile

Hello Victor,

 

I captured dhcp packets on CPPM and I can see DHCP being received from 192.168.20.1 which is the voice VLAN interface serving the actual DHCP to the phones.

 

However, the requests are being received only from phones that do not have authentication enabled on them.

 

For the phone that has authentication enabled, it gets the DHCP and it works fine but I don't see that request on CPPM. These phones are thus not getting profiled. This looks strange to me. I have attached a few screenshots for the configuration and outputs.

 

Your dhcp request has a completely different MAC (not starting with 14:). Are you sure that you see the correct DHCP address?

 

With phone and device on the same port, it may be challenging to get phones with voice-vlan/tagged-vlan right. When you set it to multi-auth and remove the tagged VLAN for voice, just run all devices untagged, it may work more reliable, however, the ClearPass Wired Enforcement Guide has working examples of multi-domain as well. Have you followed that? For voice VLAN you will need to return the device-traffic-class=voice attribute pair.

 

Would it be possible to contact your Aruba partner or TAC support, as I think interactive testing works better. To see what actually happens it may be useful to enable port-mirroring on your switch for the port, so you can see the 802.1q tags and what mac-addresses are used tagged/untagged and ending up on which VLANs. If you follow the packets it will be clear what is going on.

You should consider using multi-domain instead of multi-auth
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_8021x/configuration/xe-3se/5700/sec-user-8021x-xe-3se-5700-book/sec-ieee-mda.html

Agree with Herman
Sent from Mail for Windows 10

Hello Herman,

 

Thanks for the response. 

 

To answer your questions:

 

Your dhcp request has a completely different MAC (not starting with 14:). Are you sure that you see the correct DHCP address?

- This mac address is for the laptop connected behind the phone which is getting authenticated and profiled correctly. And yes, even the phone is getting correct DHCP from vlan 20 (voice)

 

When you set it to multi-auth and remove the tagged VLAN for voice, just run all devices untagged, it may work more reliable.

- I tried using multi-domain, but with voice vlan as tagged. As soon as I set the authentication mode to multi-domain, the port went into error-disabled mode. After clearing error-disable, it goes back in error-disabled mode after some time. Now as you suggested, I will remove the vlan tag and see what difference does it make.

 

For voice VLAN you will need to return the device-traffic-class=voice attribute pair.

- Since the profiling is not happening, I cannot return this enforcement profile based on category:VOIP Phone. Instead, I created an enforcement profile to send class=voice attribute pair if the "client-mac-vendor" Equals "Avaya Inc". In this way, the phone gets recognized and gets DHCP from voice vlan. Attached screenshot. (without this, even the DHCP is not working and phone is seen to be stuck in voice vlan searching for DHCP that never completes)

 

Would it be possible to contact your Aruba partner or TAC support, as I think interactive testing works better. 

- I have set this up in a lab environment to simulate customer need. We have an implementation to be done soon. Except for this glitch, we are good to go.

 

It's hard from this side to tell what's wrong in this situation. If you have it running in lab as preparation for a customer deployment, you should be able to contact TAC for assistance. For them, it's easier to assist you in a broken lab, than in a broken live customer situation.