Cisco - VOICE VLAN command on Trunk port

Why would you need to? Just allow the vlan across the trunk. The voice vlan on the end user port is to differentiate the vlans when the phone and pc are daisy-chained.

I want to setup all user-facing ports so that they are ready for either a pc or phone connection.

The reason I ask about the trunk link is that I need to do this to hundreds of stacks of switches. It will be far faster if I can blanket the entire switch with the voice vlan command instead of configuring around trunk ports.

I don't currently have access to my lab to even see if that command can be applied on an trunk port, but I do know that voice vlan isn't supported on trunk ports, so I believe the command will fail if you try to apply it to the trunk ports.

On the version of ios that we're running, the command is accepted, but im unsure as to it's effect-  if any.

I assume that it has the same effect as a switchport access vlan # command on a trunk port.

assigning voice vlan to a trunk port is a waste of time, because all it flags is DSCP 46 (aka TOS184, aka forward expedite.)

You only need to flag QOS in one place, once the packets are flagged with QOS mappings, they don't drop the flag as they go through different equipment.

Setting the ports to tagged and allowing both tags to be presented on the port with tagging aware devices allows the flexibility you're looking for.  Setting voice vlan on every port is unnecessary, and will probably be ineffectual.

The other thing to consider is that QOS flagged doesn't matter on un-congested interfaces.  The switchports will probably never need or use QOS, whereas the trunk ports may experience congestion.  Usually congestion is experienced on the NNI's, or at the trunk hitting the cubes,
99.9% percent of the time, your Cisco voice-feature enabled routers will be out of resources long before congestion is an issue.

Lastly, QOS doesn't do anything if you're really just out of bandwidth or some other resource capacity issue.

Peter

@ pserwe

There is so much incorrect information in your post that I care not to even comment on them.

I have confirmed that adding switchport voice vlan # to an active trunk uplink does not have a negative / noticeable effect.

However, adding the switchport voice vlan # command to an uplink port that is currently in access mode DOES have the capacity to knock the adjacent switch offline.