I found the most ancient Cisco phone model ebay had to offer for my lab, the old but reliable 7940, plugged just to the right of it on SW1 in port Fa1/0/24!
Quick review of Voice terminology and definitions
I’m going to dive just a bit into Voice terminology here at first, as the word “Jitter” and “Latency” were brought up a bit on ROUTE, so I think it’d be a good idea to know what those are for SWITCH as well:
- Jitter = The variation in delay of received voice packets by measure of a clock source, making voice / video sound or look choppy
- Latency = The round-trip time from transmission to reception of traffic, Jitter is the measurement of delay within this round-trip time measured in ms (milliseconds)
With those definitions, the human ear has a small window up to about 140-150ms sensitivity before we start hearing voice quality issues, QoS configurations on Voice VLAN interfaces are used to avoid issues with both Latency and Jitter by providing priority to Voice traffic.
How IP phones are typically plugged into a network for reference
I don’t have a PC on hand to plug into my Cisco phone unfortunately, so I can only illustrate the point with the diagram above, that the phone is actually considered a mini 3-port switch. 1 port leading to the switch, 1 port leading to the PC, and 1 port leading to the phones CPU.
This is a picture of the back of the phone to illustrate:
The PC sends data to the phone, the phone sends both data and voice frames to the switch, and to keep the traffic separate the Voice VLAN is needed so traffic can be tagged using 802.1q frame-tagging to tag the voice traffic while the data traffic uses the native VLAN (or otherwise configured Data VLAN).
This 802.1q tag is also what is used by the QoS configurations to assign priority for the Voice Frame tagged, but being QoS is a whole can of worms in itself, and will be addressed in another post.
How Cisco, non-Cisco phones, and PC’s learn of their VLANs and use them
For Cisco Voice endpoints, the switch has a CDP exchange with the Phone / Voice endpoint the moment its connected, and CDP tells the phone what its Voice VLAN is depending on how exactly the Voice VLAN is configured as explained below.
For non-Cisco phones, the DHCP server needs to be configured with Option 156, so when the phone announces itself on the Access VLAN its response it gets from the DHCP Server containing the information configured for that phone vendors network segment.
For PC’s sending data, the VLAN that switch interface resides in is the PC’s VLAN, its traffic is sent through the phone untagged until the it gets to the switch and is then tagged with its respective VLAN configured (or the native VLAN if no VLAN configured).
The different options for configuring the interface as a Voice VLAN
First to look at the options for interface Fa1/0/24 which the 7940 is plugged into:
SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#int fa1/0/24
SW1(config-if)#switchport voice vlan ?
<1-4094> Vlan for voice traffic
dot1p Priority tagged on PVID
none Don’t tell telephone about voice vlan
untagged Untagged on PVID
Here is a break down of the 4 different types of Voice VLAN options presented:
- VLAN # = CDP instructs phone to use this # to tag Voice frames, the phone assumes Data is untagged, so sends Voice tagged and Data untagged back to the switch
- Dot1p = CDP instructs phone to use VLAN 0 for Voice Traffic, as the VLAN field in the frame will be zeroed out except for a 3-bit Priority field, if the PC is set with any dot1p tags the phone will not alter them but forward the frames on to the switch
- Untagged = CDP instructs phones to use VLAN 4095, a reserved VLAN with the designation of using no VLAN for Voice or Data, no way for switch to distinguish Voice from Data traffic
- None = CDP instructs phones there is no Voice VLAN configured, essentially turns off the Voice VLAN on an interface
So from these options, you would probably say “Why would anyone use anything other than assigning a Voice VLAN number to an interface?” You would probably be right, as that is the most common configuration I see in production Cisco switching environments, however it is important to know the others exist and how they function.
The real take away from this should be that CDP is the engine behind telling the phones the VLAN # to use, and in 3 of 4 “switchport voice vlan …” options it does assign a number, and the last one it tells the phone there is NO Voice VLAN.
Configuration and Verification of the Voice VLAN on the switch CLI
Here is a demonstration of both putting Fa1/0/24 with the 7940 plugged in into a Voice VLAN, and what happens if no Voice VLAN yet exists:
SW1(config-if)#switchport voice vlan 24
% Voice VLAN does not exist. Creating vlan 24
SW1(config-if)#
It creates the VLAN just like creating any new VLAN from a switch interface, and will display the same in “show vlan brief” as seen in this output:
SW1#sh vlan bri
VLAN Name Status Ports
—- ——————————– ——— ——————————-
1 default active Fa1/0/2, Fa1/0/3, Fa1/0/4
(lots more ports)
24 VLAN0024 active Fa1/0/24
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
SW1#
So it still needs to be named (like any new VLAN configured) to show as “Voice” in the VLAN table, however it can be verified using “show interface (int) switchport” command shown here:
SW1#
SW1#sh int fa1/0/24 switchport
Name: Fa1/0/24
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: static access
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: 24 (VLAN0024)
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk associations: none
Administrative private-vlan trunk mappings: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL
Protected: false
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
Appliance trust: none
SW1#
It shows at the very top that the port is Enabled, in Dynamic Auto (default) Trunking mode, Encapsulation is Negotiate (also default), and most importantly the Voice VLAN # can be verified at the bottom.
Looking at this output, one bit of terminology thats true meaning escaped me for a long time, is referring to the link between a phone and switch a “trunk” as its often called.
Even though this is technically an Access Port, it is also technically a Trunk as it is allowing traffic from multiple VLANs to cross it, though it will not show up as a trunk interface with the command “sh int trunk”:
SW1#sh int trunk
Port Mode Encapsulation Status Native vlan
Fa1/0/1 on 802.1q trunking 1
Port Vlans allowed on trunk
Fa1/0/1 1-4094
Port Vlans allowed and active in management domain
Fa1/0/1 1,24
Port Vlans in spanning tree forwarding state and not pruned
Fa1/0/1 1,24
SW1#
To verify what ports contain phones you can use “sh cdp nei” to view the phone ports, and for more specific information you use “sh cdp nei det” gives a WHOLE LOT of phone information demonstrated here:
SW1#sh cdp nei
Capability Codes: R – Router, T – Trans Bridge, B – Source Route Bridge
S – Switch, H – Host, I – IGMP, r – Repeater, P – Phone,
D – Remote, C – CVTA, M – Two-port Mac Relay
Device ID Local Intrfce Holdtme Capability Platform Port ID
SW2 Fas 1/0/2 164 S I WS-C3750V Fas 1/0/2
SW2 Fas 1/0/1 164 S I WS-C3750V Fas 1/0/1
SIP000D6556F42F Fas 1/0/24 120 H IP Phone Port 1
R2 Fas 1/0/12 172 R S I 2801 Fas 0/1
SW1#
And for MUCH more information:
SW1#sh cdp nei det
…
————————-
Device ID: SIP000D6556F42F
Entry address(es):
IP address: 172.28.0.243
Platform: Cisco IP Phone 7940, Capabilities: Host
Interface: FastEthernet1/0/24, Port ID (outgoing port): Port 1
Holdtime : 163 sec
Version :
P003-08-11-00
advertisement version: 2
Duplex: full
Power drawn: 6.300 Watts
Power Available TLV:
Power request id: 0, Power management id: 0, Power available: 0, Power management level: 0
Management address(es):
————————-
…
I highlighted in blue the MAC address shown in CDP information, however with Cisco Phones they add an “SIP” on the front of their MAC addresses in CDP information, as can be verified in the switches MAC table demonstrated below.
The portions highlighted in red are other good sections of information including the phones IP Address, Power usage, Phone model, Duplex mode, Etc.
Another command covered in the PoE segments to verify Power usage can also be “sh power inline” if you know which port the phone is plugged into.
The MAC table to verify everything after SIP on the Device ID is the MAC Address:
SW1#sh mac address-table dyn
Mac Address Table
——————————————-
Vlan Mac Address Type Ports
—- ———– ——– —–
1 000d.6556.f42f DYNAMIC Fa1/0/24
1 001b.5336.f2cd DYNAMIC Fa1/0/12
1 5897.1eab.c803 DYNAMIC Fa1/0/1
1 5897.1eab.c804 DYNAMIC Fa1/0/2
24 000d.6556.f42f DYNAMIC Fa1/0/24
Total Mac Addresses for this criterion: 5
SW1#
Easy points on exam day!
Some debugging output to wrap things up, what information you can glean from it
This is a big mess of output I didn’t want to slop in the middle of the post, but I wanted to demonstrate what verification information debugging output contains, for this I turned on “debug cdp events” and plugged in the 7940 into Fa1/0/24 configured with “switchport voice vlan 24” :
(CLI debug output normal font for ease of reading)
SW1#debug cdp events
CDP events debugging is on
SW1#
*Mar 1 01:23:30.523: %ILPOWER-7-DETECT: Interface Fa1/0/24: Power Device detected: Cisco PD
*Mar 1 01:23:30.884: %ILPOWER-5-POWER_GRANTED: Interface Fa1/0/24: Power granted
*Mar 1 01:23:34.969: %LINK-3-UPDOWN: Interface FastEthernet1/0/24, changed state to up
*Mar 1 01:23:34.969: CDP-EV: entry cdp_insert_power_request: Intf FastEthernet1/0/24:
*Mar 1 01:23:34.969: CDP-EV: exit cdp_insert_power_available: Intf FastEthernet1/0/24:
*Mar 1 01:23:35.976: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/24, changed state to up
*Mar 1 01:23:37.217: CDP-EV: entry cdp_insert_power_request: Intf FastEthernet1/0/24:
*Mar 1 01:23:37.217: CDP-EV: exit cdp_insert_power_available: Intf FastEthernet1/0/24:
*Mar 1 01:23:38.224: CDP-EV: entry cdp_insert_power_request: Intf FastEthernet1/0/24:
*Mar 1 01:23:38.224: CDP-EV: exit cdp_insert_power_available: Intf FastEthernet1/0/24:
*Mar 1 01:23:38.971: CDP-EV: CDP trigger received on interface FastEthernet1/0/24
*Mar 1 01:23:38.971: CDP-EV: enter cdp_handle_power:
*Mar 1 01:23:38.971: CDP-EV: exit cdp_handle_power:
*Mar 1 01:23:38.971: CDP-EV: Packet Received from SIP000D6556F42F with capability = 10 and Platform string = Cisco IP Phone 7940 on interface FastEthernet1/0/24
*Mar 1 01:23:38.971: CDP-EV: New Neighbor discovered, notified registered clients on interface FastEthernet1/0/24
*Mar 1 01:23:39.231: CDP-EV: entry cdp_insert_power_request: Intf FastEthernet1/0/24:
*Mar 1 01:23:39.231: CDP-EV: exit cdp_insert_power_available: Intf FastEthernet1/0/24:
*Mar 1 01:23:40.237: CDP-EV: entry cdp_insert_power_request: Intf FastEthernet1/0/24:
*Mar 1 01:23:40.237: CDP-EV: exit cdp_insert_power_available: Intf FastEthernet1/0/24:
*Mar 1 01:23:41.244: CDP-EV: entry cdp_insert_power_request: Intf FastEthernet1/0/24:
SW1#u all
All possible debugging has been turned off
(I removed any output not involving Fa1/0/24)
So this does provide MAC Address / Phone Model / Power request upon the phone being plugged in, but after that it just produces PoE management output, so if a phone is already plugged into the switch the only information to be gained from a debug is the power draw from the phone!
CDP debugging DOES NOT show the Voice VLAN #, even though its hammered home that CDP is the engine behind telling the phone its VLAN # – This is a very important note for exam day that debugging CANNOT BE USED TO VERIFY VOICE VLAN #!
That is Voice VLANs in a nut shell, there is a whole QoS aspect to review, but that will be discussed later in more advanced studies!
The DEVNET GRIND! 