Cisco IP phones not working after Closed mode

[getaway51]

Hi,

After activating closed mode, I found these devices not working. They are all Cisco IP phones. Avaya Phones seems to be working fine under same port config. Sh auth br showing all these authenticated (AZ). 

Is there any workaround for this or have anyone encountered this kind of issue?

sh mac address-table

1 08cc.68e9.7bbq STATIC Gi1/0/17
1 08cc.68e9.7d11 STATIC Gi1/0/32

1 34a8.4ea6.d352 STATIC Gi1/0/34
1 34a8.4ea6.a25e STATIC Gi1/0/31

101 00ee.ab78.8b77 STATIC Vl01
101 08cc.68e9.7bbq DYNAMIC Drop
101 08cc.68e9.7d11 DYNAMIC Drop
101 34a8.4ea6.d352 DYNAMIC Drop
101 34a8.4ea6.a25e DYNAMIC Drop

Below are port config standard for all ports. 

interface GigabitEthernet1/0/XX
description IP Phones
switchport access vlan 101
switchport mode access

[getaway51]

sorry the port config is as belows

interface GigabitEthernet1/0/XX
description IP Phones
switchport mode access
switchport nonegotiate
switchport voice vlan 101

[Arne Bier]

How is this closed mode? Do you mean this is 802.1X closed mode? I don't see that in your switch interface configurations

[getaway51]

Yes , 802.1x closed mode. Port config as below

interface GigabitEthernet1/0/XX
description IP Phones
switchport mode access
switchport nonegotiate
switchport voice vlan 101

source template closed

template closed
dot1x pae authenticator
mab
access-session control-direction in
access-session port-control auto
authentication periodic
authentication timer reauthenticate server
service-policy type control subscriber authen1x
no access-session closed

[Arne Bier]

The show mac address output reveals to me that there are some static assigned MAC addresses - did you run port security at some previous stage?

I have never had issues with Cisco phones and 802.1X

Do you have CDP enabled for the entire switch (or at least for the interfaces where the Cisco phones are connected - it's crucial to have CDP enabled. For Avaya you can also enable LLDP)

cdp run
lldp run

For the interface connecting the Cisco phone, try 

access-session control-direction both
access-session host-mode single-host    <-- if the phone has a PC switch port then change this to 'multi-auth'

I would also just assign a data vlan to that interface (even though you might not need it (no PC attached to phone)) -

switchport access vlan xxx

Does the Cisco phone do MAB auth or does it have a supplicant configuration?

What is the output of the command

show access-session interface gig  1/0/xx detail

[getaway51]

Hi,

Cdp is enabled.

May I know the cmd below how does it affect the 802.1x closed mode? Only Cisco IP phones having issues in closed mode. 

access-session control-direction both

It seems the method of auth is none or NA. When i checked in ISE, the mac address has already been configured for mac bypass.

the device doesnt seems react to any source of auth even after port reset.

sh access-session int gi1/5

Interface Identifier Method Domain Status Fg Session ID
-----------------------------------------------------------------------------
Gi1/5 34a8.4ea6.d352 N/A UNKNOWN Unauth AC536477036191BFAA75C

Key to Session Events Blocked Status Flags:

A - Applying Policy (multi-line status for details)
D - Awaiting Deletion
F - Final Removal in progress
I - Awaiting IIF ID allocation
N - Waiting for AAA to come up
P - Pushed Session
R - Removing User Profile (multi-line status for details)
U - Applying User Profile (multi-line status for details)
X - Unknown Blocker

Runnable methods list:
Handle Priority Name
16 0 dot1xSupp
15 5 dot1x
17 10 mab
25 15 webauth

BB001#sh access-session int gi1/5 details
Interface: GigabitEthernet1/5
MAC Address:  34a8.4ea6.d352
IPv6 Address: Unknown
IPv4 Address: 10.1.3.4
Status: Unauthorized
Domain: UNKNOWN
Oper host mode: multi-auth
Oper control dir: in
Session timeout: N/A
Restart timeout: N/A
Periodic Acct timeout: N/A
Session Uptime: 166s
Common Session ID: AC536477036191BFAA75C
Acct Session ID: Unknown
Handle: 0xF9000454
Current Policy: authen1x

Method status list: empty

sh access-session br

Interface MAC Address AuthC AuthZ Fg Uptime

Gi1/5 34a8.4ea6.d352 UZ: SA- FA- 4294967s

sh access-session

Interface Identifier Method Domain Status Fg Session ID

Gi1/5 34a8.4ea6.d352 N/A UNKNOWN Unauth

[Arne Bier]

The command

access-session control-direction both

allows the EAP to be initiated from both directions - if it's just set to direction IN, then ISE will never initiate an EAP Identity Request - it will be up to the attached device to send 'something' to initiate the port control algorithm. BOTH is also the default.  I have never tried to be too clever about it - it seems to work well.

If you're authenticating the phones via MAB, did you see any Live Logs in ISE for this MAC address. I assume that in your ISE Authorization Profile you are returning the 'Voice Domain' AVPair if you're using the voice VLAN?

It's a little tickbox that allows the Cisco AVPair to be sent to the switch to allow voice vlan.

Taking this port gig1/5 as an example - please do a show run of that interface and save the config in a notepad.

Does the phone come active when you default the interface and simply configure the following:

default int gig 1/5
int gig 1/5
 switchport mode access
 switchport nonegotiate
 switchport voice vlan 101
 no shutdown

I just want to be sure that you don't need the access vlan in addition to the voice VLAN.

Replace the port config with the 802.1X/MAB config

If you are still not seeing any auth events in ISE then the phone will have no chance to come active on that port.

I'd change the control direction to both and retest. Check ISE logs. 

What is ISE telling you?

[Aref Alsouqi]

You don't seem to have the voice domain permission enabled on ISE authorization profile applied to the phones authorization rules. If that is the case, please try to enable that and try again. Regarding the control direction command, if that is set to in, it means that the traffic from the switch to the phone will not be controlled in the scenario the port is in unauthorized state. An example of this when the phone goes into sleep mode. In that case, the traffic leaving the switch port towards the phone will be allowed, however, if the phone should initiate any traffic that is not EAPoL it will be denied. The concept behind applying the control direction in is to allow the other devices to kinda wake up the phone, so when the phone receives the traffic, it will go through the authentication process before its port being authorized. When you apply the command with both keyword, that would prevent the any traffic in both direction, however EAPoL traffic is always permitted. One thing to keep in mind with the control direction command is that I think if the switch port is not configured in portfast, the switch will imply the control direction command in both direction.