Voice VLAN on EtherChannel

[weylin.piegorsch]

We have a policy where ALL client-facing ports have a voice VLAN configured, even if there's no phone on the link.  This is to allow at-will movement of phones from anywhere on-campus, to anywhere else on-campus.  I work at a university, there's more movement within the campus than we can control, so trying to be more "nuanced" would be a failing proposition.

I recently had a client that needed to pin-up an LACP-enabled Etherchannel.  However, what I found is that:

1. I could not place an interface into the channel-group while the "switchport voice vlan" command was applied
2. I could no issue the "switchport voice vlan" command to either the etherchannel interface, or to the member port while it was part of the LAG.

I've been searching for this in the documentation, but for the life of me I can't find it.  Is this an expected behavior?

One approach is to change policy, but that's a difficult proposition unless I can back up the recommendation with something.

For reference, I'm using a Catalyst 3850-48P-L with IOS XE 3.7.0E.  The specific errors I get are:

Command rejected: conflicts with Voice vlan

  - when trying to place into etherchannel

Command rejected: Voice Vlan cannot be configured on this interface

  - when trying to apply voice vlan while port is part of etherchannel

[Predrag Jovic]

If LACP etherchannel is configured as trunk between switches just make sure that voice VLAN is permitted on it (by default all VLANs are permitted). There is no need to configure voice VLAN on trunk interface. If you want increase priority for voice traffic on trunk - configure QoS to make sure that voice traffic will have better treatment than other traffic types.

[weylin.piegorsch]

Thanks Predrag.  It highlights an ambiguity in my original post - the client cannot accept .1q-tagged frames; this needs to be a port-channel in "switchport mode access."

[Predrag Jovic · Accepted solution]

If you need port configured as access and voice at the same time and voice VLAN are rejected you can try to apply network-policy profile on etherchannel (not sure that it will work).

IOS XE 3SE Catalyst 3850 - Configuring LLDP, LLDP-MED, and Wired Location Service

[weylin.piegorsch]

Huh - interesting approach.  Thanks Predrag, I'll check this out!

[weylin.piegorsch]

Hi Predrag,

We've taken a look at this approach, and have chose to accept the "no switchport voice vlan" scenario in preference over this.  Although less preferred than haviung that command supported on port-channel interfaces, we also recognize the limitation afforded and have accepted that as part of our policy.  Updating our compliance validation checks is much easier than the approach you brought up.

However, it's also a VERY interesting approach to define and apply incredibly nuanced policies.  There are some niche scenarios we've had a challenge with in the past that this would have helped with greatly; we'll consider this with a much more favorable eye the next time one of those come around!

[Mark Malone]

take the interfaces out of the etherchannel apply the voice command to the physical interface and then bundle them back into the etherchannel if thats what you really want to do

[weylin.piegorsch]

Thanks Mark.  Unfortunatley, the 3850 throws the error "Command rejected: conflicts with Voice vlan" if I try to apply the channel-group command while the voice vlan is configured.

[BradEast1]

Appears to be expected behavior since I get the same error across a variety of switch models. I can see the logic since it would be impossible to build an etherchannel to an IP Phone... Would the etherchannel you're attempting to build connect to another switch or server and you're just trying to avoid having ports without the voice VLAN configured?

[weylin.piegorsch]

Thanks Brad.  We are in fact trying to just be consistent across a wide range of deployment scenarios.  We could do EEM and apply specific voice command when a phone connects, and then remove them when the phone disconnects.  (LWAPPs, too, since they're on the same switch.)  We were having a hard time with certain scenarios.  We utimately chose to go with a straightforward always-the-same-config approach so that we're not in the business of managing a common EEM policty across all switches.

But, the portchannel-as-access-port scenario was one we never evaluated, since that's so rare.  But, given it's a non-standard deployment, it's something we need to evaluate, consider options, and update policy with whatever we decide.