CCNP Switch - IP Telephony (PoE, Voice VLAN, QoS)

 - COS (Class of service) - CoS is a 3-bit (CS0 through CS7) field that is present in an Ethernet frame header when 802.1Q VLAN tagging is present. Layer2 only
 - DSCP (Differentiated Services Code Point) - modern QoS in IP header. Layer 3 QoS
 - TOS (Type of service) - deprecated mechanism used with IP header for QoS

 - In addition to carrying regular data, switched campus networks can carry packets that are related to telephone calls.
 - Voice over IP (VoIP), otherwise known as IP telephony(IPT), uses IP Phones that are connected to switched Ethernet ports.
- Catalyst switches can provide power to IP Phones, form trunk links with IP Phones, and provide the proper level of QoS for voice packet delivery.

Power over Ethernet
A Cisco IP Phone is like any other node on the network—it must have power to operate.
Power can come from two sources:
■ An external AC adapter (AC 48V adapters, commonly called wall warts)
■ Power over Ethernet (DC) over the network data cable

A more elegant solution is available as inline power (ILP) or Power over Ethernet (PoE).
 - Here, the same 48V DC supply is provided to an IP Phone over the same unshielded twistedpair cable that is used for Ethernet connectivity.
 - The DC power’s source is the Catalyst switch itself. No other power source is needed, unless an AC adapter is required as a redundant source.
 - any device that can request and use inline power in a compatible manner can be used. Otherwise, if a nonpowered device such as a normal PC is plugged into the same switch port, the switch will not offer power to it.
 - Catalyst switch should be connected to an uninterruptible power supply (UPS) so that it continues to receive and offer power even if the regular AC source fails. This allows an IP Phone or other powered device to be available for use even across a power failure.

Two methods provide PoE to connected devices:
■ Cisco Inline Power (ILP)—A Cisco-proprietary method developed before the IEEE 802.3af standard
■ IEEE 802.3af—A standards-based method that offers vendor interoperability

Detecting a Powered Device
 - The switch always keeps the power disabled when a switch port is down.
 - However, the switch must continually try to detect whether a powered device is connected to a port and request PoE.
 - Switch must begin providing power if needed, so that the device can initialize and become operational. Only then will the Ethernet link be established.
 - Because there are two PoE methods, a Catalyst switch tries both to detect a powered device.
 - The switch also can apply several predetermined voltages to test for corresponding resistance values. 

IEEE 802.3af Power Classes
Power Class  Maximum Power Offered at 48V DC     Notes
0            15.4 W                                Default class
1              4.0 W                              Optional class
2              7.0 W                              Optional class
3             15.4 W                              Optional class
4         Up to 50 W                              Optional class (802.3at) aka PoE Plus

The default class 0 is used if either the switch or the powered device does not support or doesn’t attempt the optional power class discovery.
Cisco inline power device discovery takes a totally different approach than IEEE 802.3af.
Instead of offering voltage and checking resistance, the switch sends out a 340 kHz test tone on the transmit pair of the twisted-pair Ethernet cable. A tone is transmitted instead of DC power because the switch first must detect an inline power-capable device before offering it power. Otherwise, other types of devices (normal PCs, for example) could be damaged.

Supplying Power to a Device
 - A switch first offers a default power allocation to the powered device.
 - On a Catalyst 3750-24-PWR, for example, an IP Phone first receives 15.4 W (0.32 amps at 48 V DC).
 - The power budget offered to the device can be changed from the default to a more appropriate value.
 - With IEEE 802.3af, the power budget can be changed by detecting the device’s power class.
 - For Cisco ILP, the switch can attempt a Cisco Discovery Protocol (CDP) message exchange with the device.
debug ilpower controller
debug cdp packets
Configuring PoE
 - Each switch port can automatically detect the presence of an inline power-capable device before applying power, or the feature can be disabled to ensure that the port can never detect or offer inline power.
 - By default, every switch port attempts to discover an inline-powered device.
 - By default, every switch interface is configured for auto mode, where the device and power budget automatically is discovered.
 - By default, power budget is 15.4 W
 - You can change the maximum power offered as max <milli-watts> (4000 to 15400).
 - never keyword - disable PoE on a switch port. Power never will be offered and powered devices never will be detected on that port.
Switch(config)# interface <type mod/num>
Switch(config-if)# power inline {auto [max <milli-watts>] | static [max <milli-watts>] | never }
Switch(config-if)# power inline auto
Verifying PoE
Switch# show power inline [<type mod/num>]
Switch# show power inline module 3
Available:677(w)  Used:117(w)  Remaining:560(w)
Interface Admin  Oper            Power(Watts)     Device              Class
                            From PS    To Device                   
--------- ------ ---------- ---------- ---------- ------------------- -----
Fa3/1     auto   on         17.3       15.4       Ieee PD             0   
Fa3/2     auto   on         4.5        4.0        Ieee PD             1   
Fa3/3     auto   on         7.1        6.3        Cisco IP Phone 7960 0   
Fa3/4     auto   on         7.1        6.3        Cisco IP Phone 7960 n/a 
Fa3/5     auto   on         17.3       15.4       Ieee PD             0   
Fa3/8     auto   on         7.9        7.0        Ieee PD             2   
Fa3/10    auto   on         17.3       15.4       Ieee PD             4   
Fa3/12    auto   off        0          0          n/a                 n/a 

Voice VLANs
 - Cisco IP Phone provides a data connection for a user’s PC, in addition to its own voice data stream.
 - The IP Phone also can control some aspects of how the packets (both voice and user data) are presented to the switch.
 - Most Cisco IP Phone models contain a three-port switch, connecting to the upstream switch, the user’s PC, and the internal VoIP data stream.
 - The link mode between the IP Phone and the switch is negotiated.

Cisco IP Phone Connected to a Switch
IEEE P802.1p - QoS technique, also known as class of service (CoS), is a 3-bit field called the Priority Code Point (PCP) within an Ethernet frame header when using VLAN tagged frames as defined by IEEE 802.1Q. It specifies a priority value of between 0 and 7 inclusive that can be used by QoS disciplines to differentiate traffic.
802.1Q Header

The way traffic is treated when assigned to any particular class is undefined and left to the implementation.
The IEEE has made some broad recommendations:
PCP     Priority     Acronym     Traffic Types
1         0 (lowest)    BK         Background
0         1             BE          Best Effort
2         2             EE          Excellent Effort
3         3             CA          Critical Applications
4         4             VI          Video, < 100 ms latency and jitter
5         5             VO          Voice, < 10 ms latency and jitter
6         6             IC          Internetwork Control
7         7 (highest) NC          Network Control
VLAN 0 (zero)
 - The VLAN ID 0 is used when a device needs to send priority-tagged frames but does not know in which particular VLAN it resides.
 - The basic Ethernet frame does not have any priority field. The priority bits, also called CoS bits (Class of Service) are a part of 802.1Q VLAN tag.
 - Therefore, a device needing to add a CoS marking to its frames has to insert a 802.1Q tag into each frame. However, even though this device may be capable of adding 802.1Q tags into its frames, it may not know in what VLAN it currently resides.

The frames transmitted with the 802.1Q VLAN tag set to zero and the 802.1P priority bits configured as per the priority with which the frames are to be processed. When these frames are received at the far end, the header is stripped off and the frame is processed as per the configuration of the 802.1P priority bits. If the VLAN ID has a nonzero value, the header is retained and the frame is transmitted to the specified VLAN subinterface. 

Voice VLAN Configuration
 - IP Phone uplink can be a trunk or nontrunk, but the real consideration is how the voice traffic will be encapsulated.
 - The voice packets must be carried over a unique voice VLAN (known as the voice VLAN IDor VVID) or  over the regular data VLAN (known as the native VLAN or the port VLAN ID, PVID).
 - The QoS information from the voice packets also must be carried.
 - To configure the IP Phone uplink, just configure the switch port where it connects.
 - The switch instructs the phone to follow the mode that is selected. In addition, the switch port does not need any special trunking configuration commands if a trunk is wanted
Switch(config-if)# switchport voice vlan {<vlan-id> | dot1p | untagged | none}
Switch(config-if)# switchport voice vlan 9   <---configures an IP Phone to use VLAN 9 for voice traffic
 - 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.
 - If an IP Phone is removed and a PC is connected to the same switch port, the PC still will be capable of operating because the data VLAN still will appear as the access VLAN.

Voice VLAN Configuration Guidelines
 - You should configure voice VLAN on switch access ports.
 - The PortFast feature is automatically enabled when voice VLAN is configured. When you disable voice VLAN, the Port Fast feature is not automatically disabled.
 - When you enable port-security on an interface that is also configured with a voice VLAN, you must set the maximum allowed secure addresses on the port to at least two.
 - If any type of port-security is enabled on the access VLAN, dynamic port security is automatically enabled on the voice VLAN. You cannot configure port security on a per-VLAN basis.
 - You cannot configure static secure or sticky secure MAC addresses on a voice VLAN.
 - Voice VLAN ports can also be these port types:
    --Dynamic access port.
    --Secure port.
    --802.1X authenticated port.
    --Protected port.

Verifying Voice VLAN Operation
 - When the IP Phone trunk is active, it is not shown in the trunking mode from any Cisco IOS Software show command.
 - STP runs with two instances—one for the voice VLAN and one for the data VLAN, which can be seen with the show spanning-tree interface
Switch# show interfaces fastEthernet 1/0/1 switchport
Name: Fa1/0/1
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: 10 (VLAN0010)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: 110 (VoIP)
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Switch# show running-config interface fastethernet 1/0/1
interface FastEthernet1/0/1
switchport trunk native vlan 99
switchport access vlan 10    <---VLAN that carry PC Data
switchport voice vlan 110    <---VLAN that carry Voice
switchport mode access

Switch# show spanning-tree interface fastethernet 1/0/1
Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
VLAN0010 Desg FWD 19 128.51 P2p
VLAN0110 Desg FWD 19 128.51 P2p

Voice QoS
 - On a quiet, underutilized network, a switch generally can forward packets as soon as they are received.
 - Traditionally, network congestion has been handled by increasing link bandwidths and switching hardware performance.
 - Quality of service (QoS) is the overall method used in a network to protect and prioritize time-critical or important traffic.
 - The most important aspect of transporting voice traffic across a switched campus network is maintaining the proper QoS level.

QoS Overview
Different types of applications have different requirements for how their data should be sent end to end.

Three basic things can happen to packets as they are sent from one host to another across a network:
■ Delay— a packet delivery is delayed by some amount of time (caused by the time required to send the packet serially across a wire, the time required for a router or switch to perform table lookups or make decisions, the time required for the data to travel over a geographically long path, and so on).
The total delay from start to finish is called the latency.
This is seen most easily as the time from when a user presses a key until the time the character is echoed and displayed in a terminal session.
■ Jitter—As packets are delivered, variations can occur in the amount of delay so that they do not all arrive at predictable times.
The variation in delay is called jitter. Audio streams are particularly susceptible to jitter; if the audio data is not played back at a constant rate.
■ Loss—In extreme cases, packets that enter a congested or error-prone part of the network are simply dropped without delivery.
 - Some amount of packet loss is acceptable and recoverable by applications that use a reliable, connection-oriented protocol such as TCP.
 - Other application protocols are not as tolerant, and dropped packets mean data is missing.

The network can employ three basic types of QoS:
1) Best-Effort Delivery
 - A network that just forwards packets in the order they were received has no real QoS.
 - Switches and routers then make their “best effort” to deliver packets as quickly as possible, with no regard for the type of traffic or the need for priority service.

2) Integrated Services Model
 - Prearrange a path for priority data along the complete path, from source to destination.
 - RFC 1633, the Resource Reservation Protocol (RSVP) was developed as the mechanism for scheduling and reserving adequate path bandwidth for an application.
 - Each network device along the way must check to see whether it can support the request.
 - When a complete path meeting the minimum requirements is made, the source is signaled with a confirmation. Then the source application can begin using the path.
 - does not scale very well when many sources are trying to compete with each other to reserve end-to-end bandwidth.
 - applies QoS on a per-flow basis.

3) Differentiated Services Model
 - permits each network device to handle packets on an individual basis.
 - Each router or switch can be configured with QoS policies to follow, and forwarding decisions are made accordingly.
 - requires no advance reservations; QoS is handled dynamically, in a distributed fashion.
 - bases its QoS decisions on information contained in each packet header.
 - applies it on a per-hop basis to a whole group of similar flows.
 - Giving premium service to voice traffic focuses almost entirely on the DiffServ model.

DiffServ QoS

Layer 2 QoS Classification
Layer 2 frames themselves have no mechanism to indicate the priority or importance of their contents.
 - One frame looks just as important as another. Therefore, a Layer 2 switch can forward frames only according to a best-effort delivery.
 - When frames are carried from switch to switch, however, an opportunity for classification occurs.
 - Using VLAN trunks, the encapsulation also includes a field that can mark the class of service (CoS) of each frame.

IEEE 802.1Q
 - Each frame is tagged with a 12-bit VLAN ID and a User field.
 - The User field contains three 802.1p priority bits that indicate the frame CoS, a unitless value ranging from 0 (lowest-priority delivery) to 7 (highest-priority delivery).
 - Frames from the native VLAN are not tagged (no VLAN ID or User field), so they receive a default CoS that is configured on the receiving switch.

Inter-Switch Link (ISL)
 - Each frame is tagged with a 15-bit VLAN ID.
 - In addition, next to the frame Type field is a 4-bit User field. The lower 3 bits of the User field are used as a CoS value.
 - Although ISL is not standards-based, Catalyst switches make CoS seamless by copying the 802.1p CoS bits from an 802.1Q trunk into the User CoS bits of an ISL trunk. This allows CoS information to propagate along trunks of differing encapsulations.

Layer 3 QoS Classification with DSCP
From the beginning, IP packets have always had a type of service (ToS) byte that can be used to mark packets.
This byte is divided into a 3-bit IP Precedence value and a 4-bit ToS value.
This offers a rather limited mechanism for QoS because only the 3 bits of IP Precedence are used to describe the per-hop QoS behavior.

History for IP Precedence, TOS & DSCP
TOS (8bits = 3 bits IP Precedence+5bits for delay, throughput, reliability) - The Type of Service field in the IP header was originally defined in RFC 791
 - It defined a mechanism for assigning a priority to each IP packet as well as a mechanism to request specific treatment such as high throughput, high reliability or low latence,
 - In practice, only the IP Precedence part of the field was ever used.
 - At its simplest, the higher the value of the IP Precedence field, the higher the priority of the IP packet.
0 1 2 3 4 5 6 7
Precedence Type of Service

 - In the update version: RFC 2474 the definition of this entire field was changed.
 - It is now called the "DS" (Differentiated Services) field and the upper 6 bits contain a value called the DSCP" (Differentiated Services Code Point).
        0   1   2   3   4   5   6   7
      |         DSCP          |  CU   |

        DSCP: differentiated services codepoint
        CU:   currently unused

 - Since RFC 3168, the remaining two bits (the two least siginficant bits) are used for Explicit Congestion Notification.
 - allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that is only used when both endpoints support it and are willing to use it. It is only effective when supported by the underlying network.
 - While Differentiated Services is somewhat backwards compatible with ToS, ECN is not.
 - The Explicit Congestion Notification-Capable Transport (ECT)
 - When both endpoints support ECN they mark their packets with ECT(0) or ECT(1)
 - Many modern implementations of the TCP/IP protocol suite have some support for ECN; however, they usually ship with ECN disabled.
         0     1     2     3     4     5     6     7
      |          DS FIELD, DSCP           | ECN FIELD |

        DSCP: differentiated services codepoint
        ECN:  Explicit Congestion Notification

      | ECN FIELD |
        ECT   CE         [Obsolete] RFC 2481 names for the ECN bits.
         0     0         Not-ECT  - a packet that is not using ECN.
         0     1         ECT(1)
         1     0         ECT(0)
         1     1         CE       - is set by a router to indicate congestion tothe end nodes. page 6
Routers treat the ECT(0) and ECT(1) codepoints
   as equivalent.  Senders are free to use either the ECT(0) or the
   ECT(1) codepoint to indicate ECT, on a packet-by-packet basis.

 - The 6-bit DS value is known as the differentiated service codepoint (DSCP) and is the one value that is examined by any DiffServ network device.
 - The DSCP value is divided into a 3-bit class selector and a 3-bit Drop Precedence value.
         0     1     2     3     4     5     6     7
TOS   |  P2   P1    P0  | T3    T2    T1    T0  |  0  |   old format
DS    | DS5    DS4  DS3   DS2    DS1  DS0 | ECN FIELD |   new format
      | Class Selector  | Drop Precedence | ECN FIELD |

DSCP <=> IP Precedence Conversion Table
 - Class 0, the default class, offers only best-effort forwarding.
 - Cclass 1-4 - Packets in the AF classes can be dropped, if necessary, with the lower-class numbers the most likely to be dropped.
 - Class 5 - EF packets - premium service. EF is the least likely to be dropped, so it always is reserved for time-critical data such as voice traffic.
 - Class 6 - internetwork control.
 - Class 7 - network control.

Class 6,7 - Usually, routers and switches use these classes for things such as the Spanning Tree Protocol and routing protocols. This ensures timely delivery of the packets that keep the network stable and operational.

Each class represented in the DSCP also has three levels of drop precedence
■ Low (1)
■ Medium (2)
■ High (3)   - potential for being dropped before those with a lower value

DSCP Name DS Field Value (Dec) IP Precedence (Description)
CS0 0 0 : Best Effort
CS1,AF11-13 8,10,12,14 1 :Priority
CS2,AF21-23   16,18,20,22 2 :Immediate
CS3,AF31-33 24,26,28,30 3 :Flash - mainly used for voice signaling
CS4,AF41-43 32,34,36,38 4 :Flash Override
CS5,EF 40,46 5 :Critical - mainly used for voice RTP
CS6 48 6 :Internet
CS7 56 7 :Network

Description of DSCP Name
CS  : Class Selector (RFC 2474)
 AFxy : Assured Forwarding (x=class, y=drop precedence) (RFC2597)
EF  : Expedited Forwarding (RFC 3246)

Implementing QoS for Voice

  - Process to manipulate packets according to QoS policies, a switch somehow must identify which level of service each packet should receive.
  - IP packets carry a ToS or DSCP value within their headers as they travel around a network,
  - Frames on a trunk also can have CoS values associated with them.
  - A switch then can decide whether to trust the ToS, DSCP, or CoS values already assigned to inbound packets. If it trusts any of these values, the values are carried over and used to make QoS decisions inside the switch.
  - If the QoS values are not trusted, they can be reassigned or overruled.
  - Every switch must decide whether to trust incoming QoS values.
  - The perimeter formed by switches that do not trust incoming QoS is called the trust boundary.

Configuring a Trust Boundary
- When a Cisco IP Phone is connected to a switch port, think of the phone as another switch (which it is), you probably can trust the QoS information relayed by the phone.
- IP Phone also has two sources of data: VoIP packets native to the phone and user PC data switch port.

1) Enable QoS on the switch
Switch(config)# mls qos
  ! By default, QoS is disabled globally on a switch and all QoS information is allowed to pass from one switch port to another.
  ! When you enable QoS, all switch ports are configured as untrusted, by default.
2) Define the QoS parameter that will be trusted:
Switch(config)# interface <type mod/num>
Switch(config-if)# mls qos trust {cos | ip-precedence | dscp}
 ! Only one of these parameters can be selected.
 ! Generally, for Cisco IP Phones, you should use the cos
3) Make (optional) the trust conditional:
Switch(config-if)# mls qos trust device cisco-phone
! If used, the QoS parameter defined in Step 2 is trusted only if a Cisco IP Phone is detected through CDP.
! If a phone is not detected, the QoS parameter is not trusted.
4) Instruct the IP Phone on how to extend the trust boundary:
Switch(config-if)# switchport priority extend {cos <value> | trust}
 ! QoS information from a PC connected to an IP Phone should not be trusted
 ! If CoS values from the PC cannot be trusted, they should be overwritten to a value of 0.|

Switch(config-if)# switchport priority extend cos 1   <---IP Phone should mark all incoming traffic from an attached PC to have CoS 1
5) Switch uplinks always should be considered as trusted ports—as long as they connect to other trusted devices that are within the QoS boundary.
Switch(config)# interface <type mod/num>
Switch(config-if)# mls qos trust cos
! the trust is not conditional
 - To reduce the complexity of QoS configuration, Cisco introduced the Auto-QoS feature on most switch platforms.
 - By entering only a couple of configuration commands, you can enable the switch to automatically configure a variety of QoS parameters.
 - Auto-QoS is actually handled by a macro command, which in turn enters many other configuration commands as if they were entered from the command-line interface.

Select an interface at the QoS boundary:
Switch(config)# interface <type mod/num>
Enable Auto-QoS with the appropriate trust:
Switch(config-if)# auto qos voip {cisco-phone | cisco-softphone | trust}
! If the switch port is connected to a Cisco IP Phone, you should use the cisco-phone
! If no phone is connected, the port is considered untrusted.
! If a PC running the Cisco SoftPhone application is connected, choose the cisco-softphone
! On a switch port acting as an uplink to another switch or router, you should use the trust
Verifying Voice QoS
To verify how QoS trust has been extended to the IP Phone itself
Switch# show mls qos interface <type mod/num>
Switch# show mls qos interface fastethernet 0/1
trust state: trust cos
trust mode: trust cos
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none     <--verify how the IP Phone has been instructed to treat incoming QoS information from its attached PC or other device
Another command:
Switch# show interface <type mod/num> switchport
Switch# show interface fastethernet 0/1 switchport
Name: Fa0/1
Switchport: Enabled
[output deleted...]
Voice VLAN: 2 (VLAN0002)
Appliance trust: none <---IP Phone’s device is not being trusted
If the switch port were configured with the switchport priority extend trust command, the appliance trust would show trusted

If the IP Phone is not connected to the switch port, it is not detected and the trust parameter is not enabled
Switch# show mls qos interface fastethernet 0/1
trust state: not trusted
trust mode: trust cos
trust enabled flag: dis
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: cisco-phone
When a Cisco IP Phone is connected, power is applied and the phone is detected. Then the conditional QoS trust (CoS, in this case) is enabled
Switch# show mls qos interface fastethernet 1/0/1
trust state: trust cos
trust mode: trust cos
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: cisco-phone