voice vlan 720xp

At the moment, Voice will still only be available via 4.22.1F pre-releases, and commands/functionality/troubleshooting is subject to change as we approach GA. For now, the following is the information is what we currently have on Voice that we know has been tested:

Interface-level Commands

switchport mode trunk phone
Kind of like a trunk, except (a) we allow only two vlans by default: the native vlan, and the phone vlan (if configured) and (b) there are knobs controlling egress tag behavior (more on this further down). Like normal trunks, you can set an explicit allow list to add more vlans, but the “add” command won’t work by default.

switchport phone trunk […]

untagged
For any traffic egressing a phone trunk port, send it untagged (whether it’s the native vlan or not). Goes hand-in-hand with MAC-based vlan, because devices that aren’t tagging (and getting automagically put on a vlan) don’t expect to see tags in return either.

tagged
If you are setting untagged behavior globally (see below), use this to override that behavior for a single port (if for example one port has a phone that actually expects tags).

switchport phone vlan
Configure the vlan that we will map a phone to if it will not be tagging traffic and we want to map it to a vlan other than the native vlan automatically.

Hi Cord,

You can now download 4.22.1FX-Campus which will allow you to play around with supported Voice VLAN scenarios:
https://www.arista.com/en/support/software-download ==> EOS ==> Other Releases ==> 4.22 ==> 4.22.1FX-Campus

At the moment, we don’t support the LLDP MED TLV, but the good news is that LLDP-MED is not required for the switch to know it is connected to an IP phone. The basic LLDP “System Capabilities” TLV works.

We support learning the Voice VLAN via:
1) Manual config of the phone
2) DHCP
3) Configuring the CLI

If you are configuring the CLI, you will be using trunking ports (not access ports – that won’t work) and have a couple of choices here as Roberto mentioned above.

To confirm:
# show neighbor classification

Hope this helps!
Sarah

Hi Cord and Saskia,

Let me rephrase my previous answer and expound a bit as I see how it can be misleading.

Arista has implemented a mechanism to support VoIP phones (including support for PC behind IP Phones) in a way that existing deployments of IP Phones can work with Arista POE switches without need to change anything in IP phone, AAA server, Call-Manager or other associated entities.

Traditionally, VLAN and QoS/DSCP setting to be used for voice traffic are conveyed to phone over LLDP using the MED extension to LLDP.

Arista's implementation doesn't use MED extension. Instead, the switch is able to add the VLAN and QoS/DSCP setting (or port set to trust QoS/DSCP setting from phone) once the device has been classified as a phone. The classification is done with attributes from LLDP which are then validated with commonly deployed AAA servers (ex. ISE).

Once the device has been authenticated Arista switches slap the VLAN and QoS to VoIP traffic at the ingress port of PoE switch to which phone is connected. We believe that this is a cleaner way of enforcing VLAN and/or QoS/DSCP parameters as the control is 100% in-network. With advances in Silicon technology and software maturity, this implementation provides a normalized and unambiguous way of ensuring that VLAN and/or QoS/DSCP are correctly set for voice traffic.

Additional details:
Arista switches do support LLDP-MED in the following ways: * LLDP-MED Media TLV from connected end-points are parsed and show it in "show lldp neighbors detail".
* We do not advertise LLDP-MED Location, but we do receive LLDP-MED location, parse it and show it in "show lldp neighbors detail"
* We do not advertise the LLDP-MED Inventory, but we do receive LLDP-MED inventory, parse it and show it in "show lldp neighbors detail"

Arista's EOS supports power negotiation through the IEEE Std 802.3-2015 "Power-via-MDI" TLV.

Lastly,
We do advertise LLDP-MED Network Policy TLV, and there is support for application-type 6-255 but there is no support for application-type voice (type 1) and voice-signaling (type 2). For VoIP cases, we use LLDP classification based on standard LLDP-TLV, which are then validated with AAA server.

The following configuration in Arista's PoE switches will allow for IP Phones to work without any changes to phone or other associated entities.
conf#switchport default phone cos 3 ==> to globally configure phone traffic CoS rewrite

conf# interface eth X
conf-if# switchport trunk native vlan X
conf-if# switchport phone vlan Y
conf-if# switchport mode trunk phone
conf-if# spanning-tree portfast
conf-if# switchport phone trunk untagged ==> enables MAC-based phone VLAN

The "phone plan Y" can be overridden by AAA assigned VLAN. If AAA server doesn't assign any VLAN then VLAN. Y will be used for VoIP traffic.

Let me know how this goes. Take a look at a tcpdump on the interface, review "show lldp neighbors detail" also let me know if you upgraded to the 4.22.1FX-Campus EOS version.

Best regards,
Sarah

Hi Sarah,
Thank you for the explanation.
Just to check if I understood it correctly:
1) The phone is recognized as such by LLDP (no need there for the MED extensions)
2) The switch internally maps the MAC address of the switch it discovered by LLDP to the voice vlan as configured via “switchport phone vlan Y”
3) Frames coming from the phone MAC go to vlan Y
4) Frames coming from the PC MAC go to vlan x
5) and vice versa
So the phone doesn’t need to tag anything and the switch will handle everything?

Unfortunately I don’t have anything to test it yet. Seems like the vmdk version doesn’t support this feature in my lab.

Yes, the parameters you’ve mentioned will work with IP Phones.

Switch configs provided by Sarah Howell is the right config. AAA is optional. If you don’t configure AAA-based AUTH and/or VLAN assignment the phone value Y mentioned above will the VLAN on which VoIP traffic will be mapped to.

PC traffic will be mapped to native VLAN.

As long as phone is enabled to do LLDP (which presumably is needed even in prior configs) we’re good.