CCNP 642-811 BCMSN Exam Certification Guide - Cisco press

440 Chapter 18: IP Telephony

The default condition for every switch port is none, where a trunk is not used. All modes except for none use the special-case 802.1Q trunk. The only difference between the dot1p and untagged modes is the encapsulation of voice traffic. The dot1p mode puts the voice packets on VLAN 0, which requires a VLAN ID (not the native VLAN) but doesn’t require a unique voice VLAN to be created. The untagged mode puts voice packets in the native VLAN, requiring neither a VLAN ID nor a unique voice VLAN.

The most versatile mode uses the vlan-id, as shown in case A in Figure 18-2. Here, voice and user data are carried over separate VLANs. VoIP packets in the voice VLAN also carry the CoS bits in the 802.1p trunk encapsulation field.

Be aware that the special-case 802.1Q trunk is always enabled—even if an IP Phone is not connected to that switch port. Because the user PC data is always carried over the native VLAN, it is always untagged. That also means that if a PC is connected to the switch port without the IP Phone, PC data continues to be carried over the untagged portion of the trunk. The PC has no idea that a trunk is in use; it just sends and receives frames normally.

NOTE The trunk used between an IP Phone and a Catalyst switch port is dynamically created and can contain only two VLANs—a voice VLAN (tagged VVID) and the native VLAN (untagged). When the trunk is active, it is not shown in the trunking mode from any Cisco IOS Software show command.

It does not matter which trunking mode (auto, desirable, on, or off) you configure on the switch port—the special trunk will be negotiated through DTP and CDP.

Spanning Tree Protocol (STP) does run over the trunk, with two instances—one for the native VLAN and one for the voice VLAN. STP PortFast is also enabled automatically, so be careful that only a single host device is connected to the phone’s PC port.

Voice QoS

The most important aspect of transporting voice traffic across a switched campus network is maintaining the proper QoS level. Voice packets must be delivered in the most timely fashion possible, with little jitter, little loss, and little delay. Remember, a user expects to receive a dial tone, a call to go through, and a good-quality audio connection with the far end when an IP Phone is used. Above that, any call that is made could be an emergency “911” call. It is then very important that QoS be properly implemented.

QoS Trust

Recall from Chapter 16, “Quality of Service Overview,” that you must define a trust boundary for QoS information in a network. Inside this boundary, QoS information can be inherently trusted

442 Chapter 18: IP Telephony

The Real-time Transport Protocol (RTP) carries all the voice-bearer traffic (the actual audio payload) using UDP ports negotiated by the call control protocols.

Switches needing to classify voice call control traffic used by Cisco IP Phones should match against the static TCP ports 2000 through 2002. This can be done with an IP access list and a match accessgroup command.

To classify the voice-bearer traffic, a switch must identify the RTP packets that are on negotiated UDP port numbers, which you can accomplish with the match protocol rtp Network-Based Application Recognition (NBAR) command.

A Cisco IP Phone marks its own QoS information, according to the following rules:

■SCCP voice control packets receive CoS 3, IP Precedence 3, and DSCP 26 (AF31).

■RTP voice bearer packets receive CoS 5, IP Precedence 5, and DSCP 46 (EF).

■PC data packets can be marked with a configurable CoS value or left unchanged.

Queuing for Voice Traffic

By default, most Catalyst switch ports are configured to have packets with specific CoS values placed in specific egress queues. For example, packets with CoS 3 are usually placed into the higherthreshold, lower-priority standard queue. Packets with CoS 5 are always placed into the strictpriority queue for premium service.

Notice that these two CoS values correspond to the values assigned to voice traffic by an IP Phone. Therefore, the default switch behavior gives the appropriate QoS to voice traffic—if each switch along the path has QoS properly enabled and configured.

Voice call control packets (Skinny protocol) are always marked with CoS 3 and are scheduled into the egress queues for better service than normal data (CoS 0, 1, or 2). Voice bearer packets (RTP) are always marked with CoS 5 and are always scheduled into the strict-priority queue. This ensures premium QoS treatment for the audio portion of a phone call.

Verifying Inline Power, Voice VLANs, and Voice QoS

Although you might encounter a wide variety of IP Telephony problems, this section details some of the more common issues to check, as covered in this chapter. For more thorough information about troubleshooting IP Telephony, consult the Cisco Press title, Troubleshooting IP Telephony.

Verifying Inline Power, Voice VLANs, and Voice QoS 443

Verifying Inline Power

You can verify the inline power status for a switch port with the following EXEC command:

Switch# show power inline [type mod/num]

Example 18-2 provides some sample output from this command.

Displaying Inline Power Status for a Switch Port

CAUTION A Catalyst switch waits for 4 seconds after inline power is applied to a port to see if an IP Phone does indeed come alive. If not, the power is removed from the port.

Be careful if you plug an IP phone into a switch port, and then remove it and plug in a normal Ethernet device. The inline power could still be applied during the 4-second interval, damaging a nonpowered device. Wait 10 seconds after unplugging an IP Phone before plugging anything back into the same port.

Verifying Voice VLANs

Verifying the operation of the link between a switch port and an IP Phone is not easy. This is because the link can operate as a special-case, two-VLAN 802.1Q trunk, but the link never appears to be trunking according to any IOS show commands.

First, you should determine if the switch and IP Phone are actually communicating. Use the following EXEC command to see if the phone has advertised itself to the switch:

Switch# show cdp neighbors type mod/num detail

Next, verify the access VLAN being used on the switch port, along with the voice VLAN (if any). You can find these values with the following EXEC command:

Switch# show interface type mod/num switchport

444 Chapter 18: IP Telephony

Example 18-3 demonstrates some sample output from the show cdp neighbors detail and show interface switchport commands. Notice that the device is a Cisco IP Phone, a “native” trunk is being used, the native VLAN is 1, and the voice VLAN is 2.

Example 18-3 Determining Switch/IP Phone Communication and Switch Port/Voice VLAN

Switch# show cdp neighbors fast 0/1 detail

-------------------------

Device ID: SEP003094C35E4D

Entry address(es):

Platform: Cisco IP Phone 7960, Capabilities: Host

Interface: FastEthernet0/1, Port ID (outgoing port): Port 1

Holdtime : 144 sec

Version :

P00303020215

advertisement version: 2 Duplex: full

Power drawn: 6.300 Watts

Switch#

Switch# show interface fast 0/1 switchport

Name: Fa0/1

Switchport: Enabled

Administrative Mode: dynamic desirable

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 private-vlan host-association: none

Administrative private-vlan mapping: none

Operational private-vlan: none

Trunking VLANs Enabled: ALL

Pruning VLANs Enabled: 2-1001

Protected: false

Unknown unicast blocked: disabled

Unknown multicast blocked: disabled

Voice VLAN: 2 (VLAN0002)

Appliance trust: none

Switch#

Verifying Voice QoS

A switch port can be configured with a QoS trust state with the connected device. If that device is an IP Phone, the switch can instruct the phone to extend QoS trust to an attached PC or not.

Verifying Inline Power, Voice VLANs, and Voice QoS 445

To verify how QoS trust has been extended to the IP Phone itself, use the following EXEC command:

Switch# show mls qos interface type mod/num

If the port is trusted, all traffic forwarded by the IP Phone is accepted with the QoS information left intact. If the port is not trusted, even the voice packets can have their QoS information overwritten by the switch. Example 18-4 demonstrates some sample output from the show mls qos interface command, where the switch port is trusting CoS information from the attached IP Phone.

Example 18-4 Verifying QoS Trust to the IP Phone

Switch# show mls qos interface fast 0/1

FastEthernet0/1

trust state: trust cos trust mode: trust cos COS override: dis default COS: 0

DSCP Mutation Map: Default DSCP Mutation Map trust device: none

Next, you can verify how the IP Phone has been instructed to treat incoming QoS information from its attached PC or other device. This is shown in the trust device: line in Example 18-4, where the device is the IP Phone’s device. You can also use the following EXEC command:

Switch# show interface type mod/num switchport

Here, the device trust is called appliance trust, as shown in Example 18-5.

Example 18-5 An Alternate Method for Verifying QoS Trust to an IP Phone

Switch# show interface fast 0/1 switchport

Name: Fa0/1

Switchport: Enabled

[output deleted...]

Voice VLAN: 2 (VLAN0002)

Appliance trust: none

To see the queuing strategies for a switch port, use the following EXEC command:

Switch# show interface type mod/num capabilities

Example 18-6 shows some sample output from this command. Notice that this switch port has an egress queue type of 1p3q0t, hinting that there is one strict-priority queue (1p), three standard queues (3q), and no Weighted Random Early Detection (WRED) thresholds (0t).