7.2 Accommodating Voice Traffic on Campus Switches
7.2.1 QoS and Voice Traffic in the Campus Module
Regardless of the speed of individual switches or links, speed mismatches, many-to-one switching fabrics, and aggregation can cause congestion and latency. If congestion management features are not in place, some packets will be dropped, causing retransmissions that inevitably increase network load even more. QoS can mitigate latency caused by congestion on campus devices. 
QoS classifies and marks traffic at one device. Other devices can then prioritize or queue the traffic according to the marks applied to individual frames or packets.
Figure 
describes how QoS is applied in the campus network.
7.2.2 LAN-Based Classification and Marking
Classification and marking identifies traffic for proper prioritization as the traffic traverses the network. Traffic is classified by examining information at different layers of the Open Systems Interconnection (OSI) model. The classified traffic receives a mark or QoS value. IP traffic can be classified according to any values configurable in an access control list (ACL) or any of the following criteria :
Layer 2 parameters: MAC address, Multiprotocol Label Switching (MPLS), ATM cell loss priority (CLP) bit, Frame Relay discard eligible (DE) bit, or ingress interface
Layer 3 parameters: IP precedence, differentiated services code point (DSCP), QoS group, IP address, or ingress interface
Layer 4 parameters: TCP or UDP ports, or ingress interface
Layer 7 parameters: Application signatures or ingress interface
All traffic classified or grouped according to these criteria will be marked according to that classification. QoS marks establish priority levels or priority classes of service for network traffic as it is processed by each switch. Once traffic is marked with a QoS value, QoS policies on switches and interfaces handle traffic according to the values contained in the individual frames and packets. As a result of classification and marking, traffic is prioritized accordingly at each switch to ensure that delay-sensitive traffic receives priority processing as the switch manages congestion, delay, and bandwidth allocation.
QoS Layer 2 classification examines information in the Ethernet or 802.1Q header, such as the destination MAC address or VLAN ID. QoS Layer 2 marking occurs in the Priority field of the 802.1Q header. LAN Layer 2 headers have no means of carrying a QoS value, so 802.1Q encapsulation is required if Layer 2 QoS marking is to occur. The Priority field is 3 bits long and is also known as the 802.1p User Priority or Class of Service (CoS) value.
This 3-bit field supports CoS values from 1 to 7, with 1 being associated with delay tolerant traffic such as TCP/IP. Voice traffic, which by nature is not delay tolerant, receives higher default CoS values. A CoS value of 5 is given to Voice Bearer traffic, which is the phone conversation itself, so voice quality is impaired if packets are dropped or delayed. Call signaling to create, maintain, and tear down a voice call receives a CoS of 3.
As a result of Layer 2 classification and marking, the following QoS operations can occur:
Input queue scheduling: When a frame enters a port, it can be assigned to a port-based queue prior to being scheduled for switching to an egress port. Typically, multiple queues are used where traffic requires different service levels.
Policing: Frames are inspected to see if a predefined rate of traffic within a certain timeframe has been exceeded. The timeframe is typically a fixed number internal to the switch. If a frame has exceeded the rate limit, it can either be dropped or the CoS value can be marked down.
Output queue scheduling: The switch places the frame into an appropriate outbound (egress) queue for switching. The switch ensures that the buffer does not overflow on the queue.
QoS Layer 3 classification examines header values, such as the destination IP address or protocol. QoS Layer 3 marking occurs in the Type of Service (ToS) byte in the IP header. The first three bits of the ToS byte are occupied by IP Precedence, which correlates to the three CoS bits carried in the Layer 2 header. 
The ToS byte can also be used for DSCP marking. DSCP allows prioritization hop by hop as packets are processed on each switch and interface. Figure 
shows how DSCP uses ToS bits. The first three DSCP bits, correlating to Precedence and CoS, identify the DSCP CoS for the packet.
The next three DSCP bits establish a drop precedence for the packet. Packets with a high DSCP drop precedence value are dropped before those with a low value if a device or queue becomes overloaded. Voice traffic is marked with a low value to minimize voice packet drop.
Each 6-bit DSCP value is also given a DSCP name. DSCP classes 1-4 are Assured Forwarding (AF) classes. If the DSCP class value is 3 and the drop precedence is 1, the DSCP would be AF31.
7.2.3 Describing QoS Trust Boundaries
Trust boundaries establish a border for traffic entering the campus network. As traffic traverses the switches of the campus network, it is handled and prioritized according to the marks received or trusted when the traffic originally entered the network at the trust boundary.
At the trust boundary device, QoS values are trusted if they accurately represent the type of traffic and precedence processing the traffic should receive as it enters the campus network. If untrusted, the traffic is marked with a new QoS value appropriate for the policy in place at the point where the traffic entered the campus network. Ideally, the trust boundary exists at the first switch receiving traffic from a device or IP phone. It is also acceptable to establish the trust boundary where all the traffic from an access switch enters a Building Distribution layer port.
Note:
Best practices suggest classifying and marking traffic as close to the traffic source as possible.
7.2.4 Configuring a Switch for the Attachment of a Cisco Phone
Figure illustrates a typical switch-phone-PC topology. Several commands are used to configure and verify basic features for managing voice traffic on Cisco Catalyst switch ports. Figure provides descriptions for the commands used to manage voice traffic.
7.2.5 Basic Switch Commands to Support Attachment of a Cisco IP Phone
Several commands are used to configure and verify the basic required functions on a switch port connected to an IP phone with a PC connected to that phone. An example configuration is illustrated in Figure .
7.2.6 What is AutoQoS VoIP?
AutoQoS gives customers the ability to deploy QoS features for converged IP telephony and data networks much faster and more efficiently. AutoQoS simplifies and automates the Modular QoS CLI (MQC) definition of traffic classes and the creation and configuration of traffic policies. AutoQoS generates traffic classes and policy map CLI templates. When AutoQoS is configured at the interface, the traffic receives the required QoS treatment automatically. In-depth knowledge of the underlying technologies, service policies, link efficiency mechanisms, and Cisco QoS best practice recommendations for voice requirements is not required to configure AutoQoS.
AutoQoS can be extremely beneficial for the following scenarios:
Small- to medium-sized businesses that must deploy IP telephony quickly but lack the experience and staffing to plan and deploy IP QoS services
Large customer enterprises that need to deploy Cisco telephony solutions on a large scale, while reducing the costs, complexity, and timeframe for deployment, and ensuring that the appropriate QoS for voice applications is being set in a consistent fashion
International enterprises or service providers requiring QoS for VoIP where little expertise exists in different regions of the world and where provisioning QoS remotely and across different time zones is difficult
Service providers requiring a template-driven approach to delivering managed services and QoS for voice traffic to large numbers of customer premise devices
Cisco AutoQoS simplifies and shortens the QoS deployment cycle. AutoQoS helps in all five major aspects of successful QoS deployments :
Application classification: AutoQoS leverages intelligent classification on routers using Cisco network-based application recognition (NBAR) to provide stateful packet inspection. AutoQoS relies on CDP to ensure that the device attached to the LAN is really a Cisco IP phone. Once an IP phone is identified, the voice traffic is automatically classified and QoS policies are applied.
Policy generation: AutoQoS evaluates the network environment and generates an initial policy. It automatically generates interface configurations, policy maps, class maps, and ACLs. AutoQoS VoIP automatically employs Cisco NBAR to classify voice traffic, and mark the traffic with the appropriate DSCP value. It can be instructed to rely on, or trust, the DSCP markings previously applied to the packets.
Configuration: With one command, AutoQoS configures the port to prioritize voice traffic without affecting other network traffic, while still offering the flexibility to adjust QoS settings for unique network requirements. It also disables QoS settings when a Cisco IP Phone is relocated or moved to prevent malicious activity.
Monitoring and reporting: AutoQoS provides visibility into the classes of service deployed via system logging and Simple Network Management Protocol (SNMP) traps, with notification of abnormal events (that is, VoIP packet drops).
Consistency: Deployed QoS configurations are consistent among router and switch platforms, ensuring seamless QoS operation and interoperability within the network.
7.2.7 Configuring AutoQoS VoIP on a Cisco Catalyst Switch
When the AutoQoS feature is enabled on the first interface, QoS is globally enabled (mls qos global configuration command).
When the auto qos voip trust interface configuration command is entered, the ingress classification on the interface is set to trust the CoS QoS label received in the packet, and the egress queues on the interface are reconfigured. QoS labels in ingress packets are trusted.
When the auto qos voip cisco-phone interface configuration command is entered, the trusted boundary feature is enabled. The trusted boundary feature uses CDP to detect the presence or absence of a Cisco IP Phone. When a Cisco IP Phone is detected, the ingress classification on the interface is set to trust the QoS label received in the packet. When a Cisco IP Phone is absent, the ingress classification is set to not trust the QoS label in the packet. The egress queues on the interface are also reconfigured. This command extends the trust boundary if an IP Phone is detected.
To display the initial AutoQoS configuration, use the show auto qos [interface [interface-id]] privileged EXEC command. To display any user changes to that configuration, use the show running-config privileged EXEC command. You can compare the output of the show auto qos and show running-config commands to identify the user-defined QoS settings.
AutoQoS performs the following functions in a LAN :
Enforces the trust boundary on Cisco Catalyst switch access ports, and uplinks and downlinks
Enables Cisco Catalyst strict priority queuing (also known as expedited queuing) with weighted round robin (WRR) scheduling for voice and data traffic, where appropriate
Configures queue admission criteria (maps CoS values in incoming packets to the appropriate queues)
Modifies queue sizes and weights where required
7.3 Voice Support Lab Exercises
7.3.1 Lab 7-1 Configuring Switches for IP Telephony Support Lab Activity
Lab Exercise: Lab 7-1 Configuring Switches for IP Telephony Support
Configure auto QoS to support IP phones
Configure CoS override for data frames
Configure the distribution layer to trust access layer QoS measures
Manually configure CoS for devices that cannot specify CoS (camera)
Configure HSRP for voice and data VLANS to ensure redundancy
Configure 802.1Q trunks and EtherChannels for Layer 2 redundancy and load balancing
Summary
When you are implementing a VoIP network, you must address quality of service (QoS), power, and capacity planning considerations. One of the easiest ways to deal with QoS is to implement the AutoQoS features. In addition, using auxiliary VLANs and inline power eases the implementation of the VoIP network. This module highlighted the issues related to implementing a VoIP network, and the initial steps to take to ensure that the VoIP network works correctly.
No hay comentarios:
Publicar un comentario