Fallback 802.1x authentication for voice-vlan

jeroenboot · ‎06-23-2010

Is there a way to authenticate the voice-vlan (VVID) when the Radius server becommes "dead" ?

There is a fallback; but this only authenticates the critical-vlan

Per Interface: authentication event server dead action authorize

Or

Global with AAA: aaa authentication dot1x default group radius none

There is a fallback; but this only authenticates the critical-vlan

In this example we only see vlan180 being authenticated, but Vlan190 isn't authenticated.

This causes the VoIP to fail authorization for the Voice-Vlan only. (note, it does get authenticated in the access-vlan)

interface FastEthernet0/1
description 802.1x + MAB
switchport access vlan 180 <<<<<<<<<<
switchport mode access
switchport voice vlan 190 <<<<<<<<<<

no logging event link-status
speed auto 10 100
srr-queue bandwidth share 10 10 60 20
priority-queue out
authentication event fail retry 3 action authorize vlan 201
authentication event server dead action authorize <<<<<<<<<<
authentication host-mode multi-domain
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication periodic
authentication violation replace
mab
mls qos trust cos
no snmp trap link-status
auto qos voip trust
dot1x pae authenticator
dot1x timeout tx-period 5
dot1x timeout ratelimit-period 30
dot1x max-req 5
dot1x max-reauth-req 5
end

mlitka · ‎06-25-2010

We are also having this issue, so you are not alone. I currently have a case open with TAC to see what they have to say about this. I have also noticed that this feature doesn't work with the Low Impact design (using dACLs). The pre-authentication ACL applied to the port remains active even when the user/device is authorized which causes the traffic on the port to be blocked accordingly.

Curious if anyone has any suggestions on how to handle these two scenarios.

Thanks!

jeroenboot · ‎07-08-2010

Thanks for your reply,

We're still looking into this but for now it looks like there isn't another feasable option then adding more resilience to the AAA server.

We have many spokes, which are all managed centrally. Unfortunately the addition of a local radius server, to allow AAA successful authentication in case the uplink is interrupted, is not desired.

I hope Cisco has some more information related to your TAC case.

Please keep me updated

jeroenboot · ‎07-12-2010

I've been reading the IP Telephony In IEEE 802.1X-Enabled Networks Deployment and Configuration Guide.

In this guide I've found the following paragraph, which confrimed my findings.

Cisco confirms the impact on a inaccessible AAA server for devices in the voice-vlan.

There is only full support for the data-vlan. The voice-vlan can only be configured by using Radius's AV's.

2.3.6 Inaccessible-Auth Bypass

If an IEEE 802.1x authentication fails because the AAA server is unavailable, the switch can be configured to allow clients access to a special VLAN (sometimes called the “Critical VLAN”) that provides configurable access to the network. The Critical VLAN can be any VLAN except for the voice VLAN. When MDA is deployed, Inaccessible-Auth Bypass is fully supported for the data domain. The operational impact of this feature on IP Phones depends on the authorization state of the voice domain when the failure occurs.
● If a phone has previously authenticated and re-authentication occurs after the AAA server has become unreachable, the switch puts the critical port in the critical-authentication state in the current VLAN (either the statically configured voice VLAN or a dynamically assigned voice VLAN from the AAA server). IP connectivity will not be disrupted for previously authenticated phones.
● If a phone plugs into the port when the AAA server is down, the switch will put the port in the critical VLAN. Phones that get assigned to the critical VLAN will not function properly (since they will not have access to the voice VLAN). Because the switch relies on the device-traffic-class=voice VSA that only the AAA server can provide, the switch has no way to authorize a phone into the voice domain if the AAA server is down. While there is no concept of Inaccessible Auth Bypass for phones today, it is important to remember that wired phones are typically static devices. Therefore, most wired phones will be properly authenticated when the AAA server is up and stay authenticated when the AAA server is unavailable. Only phones that connect to the network when the AAA server is down will be affected. Since this would be a rare occurrence, the current behavior of Inaccessible-Auth Bypass is usually not a significant operational issue for IP telephony deployments