The LAN Edge: L2 Configurations


Framing this in the context of a sample configuration, the switch device at the edge of the network has the following policy applied:

Depending on the switch model, it may be necessary to first activate QoS using this command:

switch(config)#mls qos


This command is required on both the Catalyst 3550 and the Catalyst 6500. The Catalyst 2950 has QoS enabled by default.

The trust is configured on the switch port using this command:

switch(config-if)#mls qos trust dscp


Any ISL or 802.1Q/p frames that enter the switch port have their CoS passed (untouched) through the switch. If an untagged frame arrives at the switch port, the switch assigns a default CoS to the frame before forwarding it. By default, untagged frames are assigned a CoS of 0. This can be changed using this interface configuration command:

switch(config-if)#mls qos cos default-cos


where default-cos is a number between 0 and 7.

The syntax to configure QoS trust switch-wide for IP phone endpoints is all that is required in typical installations:

Switch(config-if)#mls qos trust device ciscoipphone


Here's the legacy syntax that was required on a per-VLAN basis:

Switch(config-if)#switchport voice vlan {vlan-id | dot1p | none | untagged}


To instruct the Cisco IP Phone to forward all voice traffic through a specified VLAN, use this command:

Switch(config-if)#switchport voice vlan vlan-id


By default, the Cisco IP Phone forwards the voice traffic with an 802.1Q priority of 5. Valid VLAN IDs are from 1 to 4096.

An alternative to specifying a particular voice VLAN on the switch is to instruct the switch port to use 802.1P priority tagging for voice traffic and to use the default native VLAN (VLAN 0) to carry all traffic. By default, if enabled, the Cisco IP Phone forwards the voice traffic with an 802.1P priority of 5.

Switch(config-if)#switchport voice vlan dot1p


In some cases, it may be desirableindeed, highly recommendednot to trust edge CoS for nonvoice/video endpoints and not to trust any CoS value that may be present in frames sourced from an edge device. For example, an office PC used for general applications, such as web browsing, e-mail, and file and print services, may not require special QoS treatment. Allowing it to request higher levels of QoS may adversely affect applications such as voice and video, which require guarantees of bandwidth and latency.

Note

This may not hold true for data center or server-based systems, which need to be given individual consideration based on the prioritization needs of any application they serve.


For this reason, it is possible to use the override parameter to tell the switch to ignore any existing CoS value that may be in the frame and apply the default value. This effectively disables any trust configuration that may have previously been applied to the port.

The CoS value assigned by the switch can be changed on a port-by-port basis using this interface configuration command:

Switch(config-if)#mls qos cos override


After this command is applied, the switch rewrites the CoS value for all incoming frames to the configured default value, regardless of any existing CoS value.

Other platforms, such as those that employ CatOS, vary. You should always verify such a reference to the correct procedure by reviewing the relevant documentation at http://www.cisco.com. For example, the following is an overview of configuring prioritization, with a 6500 platform running CatOS between Cisco CallManager and IP phones and gateways using TCP ports 2000 to 2002. The sample commands classify all Skinny Protocol traffic from IP phones and gateways (VLAN 110) and Cisco CallManager (4/2) as DSCP AF31, which is backward-compatible with IPP 3.

With older implementations, several steps need to be performed (see Example 5-1):

Step 1.

Enable switch-wide QoS.

Step 2.

Create an ACL (ACL_IP-PHONES), marking all Skinny Client and Gateway Protocol traffic from the IP phones and from Skinny Protocol gateways with a DSCP value of AF31.

Step 3.

Add to the ACL_IP-PHONE access list, trusting all DSCP markings from the IP phone so that the IP Prec = 5 RTP traffic is not rewritten.

Step 4.

Create an ACL (ACL_VOIP_CONTROL), marking all Skinny Client and Gateway Protocol traffic from Cisco CallManager with a DSCP value of AF31.

Step 5.

Accept incoming Layer 2 CoS classification.

Step 6.

Inform the port that all QoS associated with the port will be done on a VLAN basis to simplify configuration.

Step 7.

Instruct the IP phone to rewrite CoS from the PC to CoS=0 within the IP phone Ethernet ASIC.

Step 8.

Inform Cisco CallManager port (4/2) that all QoS associated with the port will be done on a port basis.

Step 9.

Write the ACL to hardware.

Step 10.

Map the ACL_IP-PHONE ACL to the auxiliary VLAN.

Step 11.

Map the ACL_VOIP_CONTROL ACL to the Cisco CallManager port.

Example 5-1. Setup of a Catalyst Edge Switch (L2 Only)

cat6k-access> (enable) set qos enable cat6k-access> (enable) set qos acl ip ACL_IP-PHONES dscp 26 tcp any any range 2000   2002 cat6k-access> (enable) set qos acl ip ACL_IP-PHONES trust-cos ip any any cat6k-access> (enable) set qos acl ip ACL_VOIP_CONTROL dscp 26 tcp any any range   2000 2002 cat6k-access> (enable) set port qos 5/1-48 trust trust-cos cat6k-access> (enable) set port qos 5/1-48 vlan-based cat6k-access> (enable) set port qos 5/1-48 trust-ext untrusted cat6k-access> (enable) set port qos 4/2 port-based cat6k-access> (enable) commit qos acl all cat6k-access> (enable) set qos acl map ACL_IP-PHONES 110 cat6k-access> (enable) set qos acl map ACL_VOIP_CONTROL 4/2

Classifying Voice on the WAN Edge

A basic configuration of a WAN edge (CE) router is shown in Example 5-2 and defined further in this section. This applies the principles in base configuration terms, as discussed previously.

In this case, you apply a simple LLQ and CBWFQ policy to the router to support voice traffic. Voice traffic needs to be assigned to the LLQ, and voice-control traffic needs a minimum bandwidth guarantee.

Example 5-2. Matching Voice and Voice Control

ip cef ! class-map match-all VOICE   match ip dscp ef ! class-map match-all VOICE-CONTROL   match ip dscp cs3   match ip dscp af31 ! ! policy-map WAN-EDGE   class VOICE     priority percent 33   class VOICE-CONTROL    bandwidth percent 5   class class-default    fair-queue ! interface Serial0/0  description WAN Link to CCT ID : 1234 :: SP-PE-1  bandwidth 2048  ip address 10.1.1.1 255.255.255.252  service-policy output WAN-EDGE

The class map applied to VOICE and VOICE-CONTROL provides an example of matching against DSCP markings, which in this case are for the voice-bearer traffic and the voice signaling and control traffic. In this basic policy, you assume that no marking of traffic needs to happen directly on this box. Rather, it deals only with the outbound classification of the traffic.

In the policy map itself, in effect you assign three elementsthose of prioritization for voice and specified as a percentage of the link bandwidth. This is an example of applying LLQ. Voice control specifies the allocation of 5 percent of link bandwidth for voice control, with the final classification being performed as class default, which uses the fair-queuing algorithm on the remaining traffic. In this case, it is assumed to be the default class.

The key to activating this policy is to attach the service-policy output to an interfacein this case, the output interface facing the SP PE. Thus, applying the classification actions as defined in the policy map WAN-EDGE to the output of the WAN serial interface provides this activation.

Classifying Video on the WAN Edge

In Example 5-3, videoconferencing traffic is assigned LLQ, and all nonvideo traffic is assigned to a default queue for WFQ.

Example 5-3. Matching Video

ip cef ! class-map match-all VIDEO   match ip dscp af41 ! ! policy-map WAN-EDGE   class VIDEO-CONF     priority 460   class class-default    fair-queue ! interface Serial0/0  description WAN Link to CCT ID : 1234 :: SP-PE-1  bandwidth 2048  ip address 10.1.1.1 255.255.255.252  service-policy output WAN-EDGE

On the WAN edge, videoconferencing traffic should be assigned to an LLQ. The video stream minimum bandwidth guarantee should be the size of the stream plus 20 percent.

As before, this policy doesn't take effect until it is bound to an interface with a service-policy statement.

Classifying Data on the WAN Edge

Most enterprises have many applications that can be considered mission-critical (transactional). However, if too many applications are classified as mission-critical, they will contend among themselves for bandwidth, with the result of dampening QoS effectiveness. Taken to the extreme, a regular FIFO link (no QoS) is scheduled in the exact same manner as a link where every application is provisioned as mission-critical. Therefore, it is recommended that you classify no more than three applications as mission-critical (transactional).

These applications should be marked with different AF drop-preference values to distinguish them from each other. Such distinctions provide more granular visibility in managing and monitoring application traffic and aid in provisioning for future requirements. Similar arguments are made for having no more than three applications in a guaranteed bandwidth (bulk data) class of applications and, likewise, marking these applications with different AF drop-preference values.

Default traffic is automatically marked as best-effort (DSCP 0). However, noncritical bandwidth-intensive traffic could (optionally) be marked as different so that adverse policies could be applied to control such traffic. These types of traffic can be described as "less-than-best-effort" or "scavenger" traffic.

It is imperative that DSCP classification be performed on all packets before they arrive at the WAN edges. In this manner, queuing and congestion avoidance can be performed at the WAN edge based strictly on DSCP markings.

Note

It's important to keep in mind that the default class map match setting is match-all. Therefore, when you attempt to classify mutually exclusive traffic flows (such as differing DSCP values), it is important to explicitly use the match-any qualifier when defining the class map. Another example could be through the use of multiple DSCPs on a single command line:

match ip dscp af11 af12 af13


The advantage of using multiple lines is that this triggers a separate counter in the class-based QoS Management Information Base (MIB) for each DSCP. (If they are matched all on the same line, only a single counter is triggered for all DSCPs.)


The Eight-Class Model introduces a dual-LLQ design: one for voice and another for interactive video. As pointed out earlier in this chapter, the LLQ has an implicit policer that allows for time-division multiplexing of the single priority queue. This implicit policer abstracts the fact that there is essentially a single LLQ within the algorithm and thus allows for the "provisioning" of multiple LLQs.

Interactive video (or IP videoconferencing, also called IP/VC) is recommended to be marked AF41 (which can be marked down to AF42 in the case of dual-rate policing at the campus access edge). It is recommended that you overprovision the LLQ by 20 percent of the IP/VC rate. This takes into account IP/UDP/RTP headers as well as Layer 2 overhead. Additionally, Cisco IOS Software automatically includes a 200-ms burst parameter (defined in bytes) as part of the priority command. On dual-T1 links, this has proven sufficient for protecting a single 384-kbps IP/VC stream. On higher-speed links (such as triple T1s), the default burst parameter has shown to be insufficient for protecting multiple IP/VC streams.

However, multiple-stream IP/VC quality tested well with the burst set to 30,000 bytes (for example, priority 920 30000). Our testing did not arrive at a clean formula for predicting the required size of the burst parameters as IP/VC streams continually were added. However, given the variable packet sizes and rates of these interactive-video streams, this is not surprising. The main point is that the default LLQ burst parameter might require tuning as multiple IP/VC streams are added (which likely will be a trial-and-error process).

Optionally, DSCP-based WRED can be enabled on the Interactive-Video class, but testing has shown negligible performance difference in doing so (because, as has been noted, WRED is more effective on TCP-based flows than UDP-based flows, such as interactive video). In these designs, WRED is not enabled on classes such as Call-Signaling, IP Routing, and Network-Management because WRED would take effect only if such classes were filling their queues nearly to their limits. Such conditions would indicate a provisioning problem that would be better addressed by increasing the class's minimum bandwidth allocation than by enabling WRED.

Additionally, the Eight-Class Model subdivides the preferential data class to separate control plane traffic (IP routing and network-management applications) from business-critical data traffic. IGP packets (such as RIP, EIGRP, OSPF, and IS-IS) are protected through the PAK_priority mechanism within the router. However, EGP protocols, such as BGP, do not get PAK_priority treatment and might need explicit bandwidth guarantees to ensure that peering sessions do not reset during periods of congestion. Additionally, administrators might want to protect network-management access to devices during periods of congestion.

The other class added to this model is for bulk traffic (the Bulk Data class), which is spun off of the Critical Data class. Because TCP continually increases its window sizes, which is especially noticeable in long sessions (such as large file transfers), constraining bulk data to its own class alleviates other data classes from being dominated by such large file transfers. Bulk data is identified by DSCP AF11 (or AF12 in the case of dual-rate policing at the campus access edges). DSCP-based WRED can be enabled on the Bulk Data class (and also on the Critical Data class). Example 5-4 shows the implementation of the Eight-Class Model for the WAN edge.

Example 5-4. Eight-Class Model

! class-map match-all Voice  match ip dscp ef ! IP Phones mark Voice to EF class-map match-all Interactive Video  match ip dscp af41 af42 ! Recommended markings for IP/VC class-map match-any Call Signaling  match ip dscp cs3 ! Future Call-Signaling marking  match ip dscp af31 ! Current Call-Signaling marking class-map match-any Network Control  match ip dscp cs6 ! Routers mark Routing traffic to CS6  match ip dscp cs2 ! Recommended marking for Network Management class-map match-all Critical Data  match ip dscp af21 af22 ! Recommended markings for Transactional-Data class-map match-all Bulk Data  match ip dscp af11 af12 ! Recommended markings for Bulk-Data class-map match-all Scavenger    match ip dscp cs1 ! Scavenger marking ! policy-map WAN-EDGE  class Voice   priority percent 18 ! Voice gets 552 kbps of LLQ  class Interactive Video   priority percent 15 ! 384 kbps IP/VC needs 460 kbps of LLQ  class Call Signaling   bandwidth percent 5 ! BW guarantee for Call-Signaling  class Network Control   bandwidth percent 5 ! Routing and Network Management get min 5% Bandwidth  class Critical Data   bandwidth percent 27 ! Critical Data gets min 27% BW   random-detect dscp-based ! Enables DSCP-WRED for Critical-Data class  class Bulk Data   bandwidth percent 4 ! Bulk Data gets min 4% BW guarantee   random-detect dscp-based ! Enables DSCP-WRED for Bulk-Data class  class Scavenger   bandwidth percent 1 ! Scavenger class is throttled to 1% of bandwidth  class class-default   bandwidth percent 25 ! Fair-queuing is sacrificed for Bandwidth guarantee   random-detect ! Enables WRED on class-default !

This design is more efficient than strict policing, because these bandwidth-intensive noncritical applications can use additional bandwidth if it is available while ensuring protection for critical transactional data classes and real-time voice and video applications.

The development of this model is attributed to Tim Szigeti from the Cisco Enterprise Solutions Engineering Group.

For more information on this approach, go to http://www.cisco.com/application/pdf/en/us/guest/netsol/ns432/c649/ccmigration_09186a008049b062.pdf.




Selecting MPLS VPN Services
Selecting MPLS VPN Services
ISBN: 1587051915
EAN: 2147483647
Year: 2004
Pages: 136

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net