Dynamic voice VLAN assignment when different phone systems are in play

[Christopher Bell]

First, understand I have no control over the different types of phones systems.  This is a very large enterprise that is a child of an even larger enterprise (50K plus users).  The parent organization uses a Cisco phone system while the child organization (the one I'm in) uses an NEC phone system.  The child org is health care while the parent is EDU.  The parent org has networks within our org that must be separated by vrf because of HIPPA.  One of those scenarios is voice.  Whenever the parent needs to place a voice network on one of our switches that already has our voice network on it, we have to start manually configuring ports for different voice vlans instead of just setting a default voice vlan on all the switchports.  This causes all kinds of issues with automation as you can imagine.  

My question is simply this, using Cisco ISE (3.0+) can I dynamically assign the voice VLAN for each port based on the type of device that's connecting (using either MAB or 802.1x).  I've been trying to test this but I'm not getting anywhere.  

[Arne Bier]

Do you get hits against those AuthZ rules? And can you see that the Template has been mentioned in the Access-Accept in each case?

[Christopher Bell]

Yes in both cases.  Here's the result for one of the NEC phones I'm testing with:

On the switch side, it's complaining there isn't already a voice vlan and it's trying to connect the phone to the data vlan:

%DOT1X_SWITCH-5-ERR_VLAN_EQ_VVLAN: Data VLAN ^A on port TwoGigabitEthernet1/0/5 cannot be equivalent to the Voice VLAN AuditSessionID

And then ends with:

%SESSION_MGR-5-FAIL: Switch 1 R0/0: sessmgrd: Authorization failed or unapplied for client (blah blah) on Interface TwoGigabitEthernet1/0/5 AuditSessionID 0400040A00000018A4B1EC84.

I'll also add that I switch to 802.1x and the phone authenticates using creds we hard coded on it.  So authentication is working.  What's broken is the interface template being passed back to the switch so the switchport voice command can be applied. 

[Arne Bier]

Have you tried putting a voice vlan on the interface (even if it's not the one you might need in the AAA case)? If this doesn't work, then I would assume that dynamic voice domain VLAN assignment just wasn't ever meant to work.

[Christopher Bell]

Yes, I've tried it while using MAB to authenticate but not 802.1x.  I'll try that next if I can. 

[MaErre21325]

The voice vlan must be configured in the dot 802.1x port configuration even if it is not used?
i'm getting this error:

DOT1X_SWITCH-5-ERR_VLAN_EQ_VVLAN: Data VLAN 9 on port GigabitEthernet0/16 cannot be equivalent to the Voice VLAN AuditSessionID 0AD24A0E0004411B12E4E0F3

but on the switch where i'm getting the errors we don't use the voice vlan; what should be configured?

[Arne Bier]

@MaErre21325 what does your interface config look like (show derived int x/y/z) ?  Are you returning the RADIUS voice permission AVPair ? 

An interface cannot have the same access VLAN (DATA domain) and a voice VLAN (VOICE domain). Voice vlan is not mandatory on an interface. But if the RADIUS server is returning the voice permission AVPair, then the switch will expect the voice vlan to be configured on the interface.

It's also come to my attention that newer IOS-XE version (don't know from what version) now supports dynamic voice VLAN assignment via RADIUS attributes. 

[davidgfriedman]

We had that problem with some Intercoms we onboarded last year.  I think we had to remove the VLAN tag from the authorization profile->common tasks area, then set the authorization profile->common tasks checkbox for voice domain profile. 

We had another set of phones or intercoms fighting us where they kept dropping data alternatively on the data VLAN and the voice VLAN, no rhyme or reason. For that one, we set the data domain, wanted to use the voice domain VLAN, and kept learning it from CDP. We had to make the vendor disable CDP so it couldn't learn from the switch that we'd defined a voice domain/VLAN.   

Devices and NAC/authentication can be quite the pain, sometimes....