Home > Articles > Cisco Network Technology > IP Communications/VoIP > Cisco IP Telephony Flash Cards: Weighted Random Early Detection (WRED)

Cisco IP Telephony Flash Cards: Weighted Random Early Detection (WRED)

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Nov 24, 2004.

Chapter Description

This chapter provides an overvew of Weighted Random Early Detection (WRED) for Cisco IP Telephony, including Question & Answer flash cards to help you prepare for the Cisco IP Telephony Exam.

Traffic Classification and Marking

Classification and marking allow QoS-enabled networks to identify traffic types near the source and assign specific markings to those traffic types. This section addresses the need for and various approaches used to perform classification and marking.

Classification and Marking Basics

One of the first QoS mechanisms that you apply to your traffic is classification, which recognizes the types of traffic that are flowing across the network. For example, you might recognize Telnet, FTP, and HTTP traffic and categorize those applications together in a specific class of traffic.

Although classification is great, you probably do not want to configure classification on every router. Therefore, after the traffic is classified, you can “mark” it. At that point, other routers and switches in the network can reference those markings and make decisions (for example, forwarding or dropping decisions) based on those markings.

Some of these markings are Layer 2 (that is, the Data Link Layer) markings, whereas other markings are at Layer 3 (that is, the Network Layer). First, consider the Layer 2 markings.

On an Ethernet trunk, you can mark frames with a class of service (CoS) value. A CoS value can range from 0 through 7, although Cisco recommends that you never use 6 or 7. The bits that create the CoS marking depend on the type of trunk that is being used, as follows:

  • IEEE 802.1Q trunk—Uses 3 bits in a Tag Control byte to mark a CoS value. (Note: This method is referred to as IEEE 802.1p.)

  • ISL trunk—Uses 3 bits in the ISL header to mark a CoS value.

Figure 8Figure 8

Layer 2 markings also can extend to the WAN. Consider a Frame Relay network. Within a Frame Relay header is a bit called the Discard Eligible (DE) bit, which identifies frames that the service provider can drop during periods of congestion. You can leverage that DE bit to identify less important traffic that you send to the Frame Relay service provider. Similarly, you can mark the Cell Loss Priority (CLP) bit in an ATM cell to identify less important ATM traffic.

Service providers often use Multiprotocol Label Switching (MPLS) to forward traffic. Three bits in the MPLS label can be used to identify priority for traffic that is flowing through the service provider’s cloud.

As mentioned earlier, Layer 3 markings are made possible by using bits within an IPv4 header’s ToS byte. These markings are IP Precedence (which uses the 3 leftmost bits in the ToS byte) and DSCP (which uses the 6 leftmost bits in the ToS byte).

A major design issue to keep in mind is that a CoS marking from a trunk does not survive a route processor hop. So, if you are only using CoS markings to identify the priority of your traffic, those CoS markings should be “remarked” to a Layer 3 marking before the traffic passes through a route processor.

Figure 9Figure 9

Although Cisco recommends marking traffic as close to the source as possible, you typically do not want users setting their own priority markings. Therefore, you can use Catalyst switches to create a trust boundary, which is a point in the network that does not trust incoming markings. An exception to having a wiring closet switch acting as a trust boundary would be a Cisco IP Phone that is connected to the switch. Because the Cisco IP Phone performs priority marking, you can extend the trust boundary to the phone.

Modular Classification with MQC

Recall the previous discussion about the Cisco three-step MQC process for configuring QoS mechanisms. You can leverage this MQC approach to do classification and marking. First, consider classification using MQC. In class-map configuration mode, you can use the match command to categorize traffic based on any of the following criteria:

  • Access control lists (ACLs)

  • Existing markings (for example, CoS, IP Precedence, or DSCP)

  • QoS group (a locally significant grouping of packets)

  • Protocol (using NBAR)

  • Traffic matching another class-map

  • Incoming interface

  • MAC address (source or destination)

  • Range of UDP port numbers

In the following example, you are matching traffic based on a variety of the preceding criteria:

Router(config)#class-map match-any INT
Router(config-cmap)#match input-interface ethernet 0/0
Router(config-cmap)#match input-interface ethernet 0/1
Router(config-cmap)#exit
Router(config)#class-map ACL
Router(config-cmap)#match access-group 101
Router(config-cmap)#exit
Router(config)#class-map COS
Router(config-cmap)#match cos 0 1 2 3
Router(config-cmap)#exit
Router(config)#access-list 101 permit tcp any any eq 23

In this example, the INT class-map matches traffic that came into the router on any of the specified interfaces. The ACL class-map matches traffic that is matched by access-list 101. Finally, the COS class-map categorizes traffic with a CoS marking of 0, 1, 2, or 3.

Modular Marking with MQC

After you have classified your traffic using class-maps, you can use a policy-map to mark the traffic. Following is a listing of supported markings and the corresponding syntax:

  • IP Precedence (set ip precedence value)

  • DSCP (set ip dscp value)

  • QoS group(set ip precedence value)

  • MPLS experimental bits (set mpls experimental value)

  • CoS value (set cos value)

  • Frame Relay DE bit (set fr-de)

  • ATM CLP bit (set atm-clp)

In the following example, you use MQC to remark CoS values that are entering a router to DSCP values:

Figure 10Figure 10

Router(config)#class-map HI-PRI
Router(config-cmap)#match cos 5 6 7
Router(config-cmap)#exit
Router(config)#class-map MED-PRI
Router(config-cmap)#match cos 2 3 4
Router(config-cmap)#exit
Router(config)#class-map LOW-PRI
Router(config-cmap)#match cos 0 1
Router(config-cmap)#exit
Router(config)#policy-map REMARK
Router(config-pmap)#class HI-PRI
Router(config-pmap-c)#set ip dscp af31
Router(config-pmap-c)#exit
Router(config-pmap)#class MED-PRI
Router(config-pmap-c)#set ip dscp af21
Router(config-pmap-c)#exit
Router(config-pmap)#class-map LOW-PRI
Router(config-pmap-c)#set ip dscp af11
Router(config-pmap-c)#exit
Router(config-pmap)#exit
Router(config)#interface fastethernet 0/1
Router(config-if)#service-policy input REMARK

In this example, traffic marked with CoS values of 5, 6, or 7 is classified in the HI-PRI class-map, whereas traffic with CoS values of 2, 3, or 4 goes into the MED-PRI class-map. Finally, CoS values of 0 and 1 are placed in the LOW-PRI class-map. The REMARK policy-map assigns a DSCP value of AF31 to the HI-PRI traffic, a DSCP value of AF21 to the MED-PRI traffic, and a DSCP value of AF11 to the LOW-PRI traffic. The third step of MQC applies a policy-map to an interface. In this case, you are applying the REMARK policy-map to the FastEthernet 0/1 interface in the inbound direction. It is critical that you apply the policy-map in the inbound direction. By doing so, you are remarking the CoS values before the route processor strips them.

As you learned earlier, to see what policies are applied to your class-maps, use the show policy-map command. Or, to see interface-specific statistics for a policy-map, the show policy-map interface interface-identifier command is appropriate.

Classifying with NBAR

The most powerful and flexible approach to classifying traffic is the Network Based Application Recognition (NBAR) feature. NBAR can look beyond Layer 3 and Layer 4 information, all the way up to Layer 7. Protocols that change port number (that is, stateful protocols) can be tracked, and even URL strings can be matched with NBAR.

Although the IOS comes with multiple NBAR application signatures, a continuing need exists for additional signature recognition. For example, even though your router might be able to recognize KaZaa traffic, it might not be able to recognize e-Donkey traffic. Fortunately, you can install Packet Description Language Modules (PDLMs) into the router’s flash, and these PDLMs extend the IOS’s ability to recognize traffic. PDLMs are available for download from http://www.cisco.com/cgi-bin/tablebuild.pl/pdlm.

Note that this site requires a Cisco.com login. Also, note that the context-sensitive help in the IOS might define the PDLM as Protocol Description Language Module instead of Packet Description Language Module.

Figure 11Figure 11

In addition to NBAR’s usefulness in classifying, it can function as a protocol discovery tool. For example, NBAR protocol discovery could be enabled on an interface to determine the applications that are consuming the most bandwidth on that interface (that is, the “top talkers”).

The following command configures NBAR protocol discovery:

Router(config-if)#ip nbar protocol-discovery

After NBAR has collected traffic statistics for an interface, use the following command to view the statistics:

Router#show ip nbar protocol-discovery

To use NBAR to classify traffic, as part of a class-map, use the keyword protocol in the match command, as follows:

Router(config-cmap)#match protocol protocol

You can reference the previously mentioned PDLM file with the following command:

Router(config)#ip nbar pdlm pdlm-file

In the following example, NBAR classifies KaZaa Version 2 traffic and HTTP traffic:

Figure 12Figure 12

Router(config)#class-map MUSIC
Router(config-cmap)#match protocol kazaa2
Router(config-cmap)#exit
Router(config)#class-map WEB
Router(config-cmap)#match protocol http
Router(config-cmap)#exit
Router(config)#policy-map NBARTEST
Router(config-pmap)#class MUSIC
Router(config-pmap-c)#police 32000
Router(config-pmap-c)#exit
Router(config-pmap)#class-map WEB
Router(config-pmap-c)#bandwidth 128
Router(config-pmap-c)#exit
Router(config-pmap)#exit
Router(config)#interface ethernet 0/1
Router(config-if)#service-policy output NBARTEST

In this example, KaZaa version 2 traffic is classified by the MUSIC class-map, whereas http traffic is classified by the WEB class-map. Then, the NBARTEST policy-map limits the MUSIC class to 32 kbps while allocating 128 kbps of bandwidth for the WEB class. Finally, the policy-map is applied outbound to the ethernet 0/1 interface.

Consider the priority that you should assign to web traffic. If you have an e-commerce site, as an example, web traffic might need varying levels of priority, depending on the content of the web traffic. The good news is that NBAR can recognize the content of web traffic using commands such as the following:

Router(config-cmap)#match protocol http url url-string

(Matches a string that is contained in the URL)

As an example, you could match traffic that contains the word cisco in the URL with the following command:

match protocol http url “*cisco*”

The asterisks are acting as wildcards, matching any characters before or after the word cisco.

QoS over Tunnel Connections

Virtual private networks (VPNs) are gaining tremendous popularity because of their ability to provide secure connectivity through a public network, such as an ISP. VPNs are made possible thanks to tunneling.

The challenge with QoS in a tunnel environment is that the tunnels encapsulate traffic, which hides the original information in a packet’s header. After packets enter a tunnel, they have a tunnel header. Therefore, all packets have the same level of priority, because the classification of encapsulated packets is based on the tunnel header. The Cisco pre-classify feature overcomes this issue by applying QoS features to packets before they enter the tunnel. Pre-classification, however, is only necessary when you are classifying based on a criterion other than a packet’s ToS byte. The IOS automatically copies bits from a packet’s ToS byte into the ToS byte of the tunnel header.

Figure 13Figure 13 ***

To enable the pre-classification feature, in tunnel-interface-configuration mode (or in crypto-map configuration mode for an IPSec tunnel), enter the following command:

qos pre-classify

QoS over BGP Networks

In a service provider environment, you might not want to use access-lists or other classification mechanisms through the service provider’s network. An alternate option is to use QoS Policy Propagation Through BGP (QPPB).

QPPB lets you encode QoS information by assigning BGP attributes such as an autonomous system number, community string, or an IP prefix.

For example, instead of setting the IP Precedence marking to a 4 inside every packet, you could send the traffic with a certain community string. When the far-end autonomous system receives the traffic with that community string, it can mark those packets with an IP Precedence of 4.

In the following example for router R1, the community attribute determines how the IP Precedence value is set. Specifically, traffic with a community string of 20:1 has its IP Precedence set to a 2, and traffic with a community string of 20:2 has its IP Precedence set to a 3. The bgp-policy source command applies this policy to interface Serial 0/1.

Figure 14Figure 14 ***

router bgp 100
  table-map precedence-map
  neighbor 1.1.1.2 remote-as 200
  neighbor 1.1.1.2 send-community
!
route-map precedence-map permit 10
  match community 1
  set ip precedence 2
!
route-map precedence-map permit 20
  match community 2
  set ip precedence 3
!
ip community-list 1 permit 20:1
ip community-list 2 permit 20:2
!
interface serial 0/1
  ip address 1.1.1.1 255.255.255.0
  bgp-policy source ip-prec-map

Catalyst-Based Classification and Marking

You can perform classification and marking functions, not just on router platforms, but also on many Catalyst series switches. Even though QoS is considered primarily a WAN technology, proper QoS configuration in a enterprise network’s infrastructure is also critical. For example, a switch might have interfaces that run at different speeds (for example, 10 Mbps and 1 Gbps). Such a scenario could lead to a switch queue overflowing. Also, traffic can enter a switch marked with a Layer 2 CoS value. These Layer 2 values do not pass through a route processor. Therefore, a Catalyst switch is an excellent place to perform CoS-to-DSCP remarking. So, when the traffic reaches the route processor, it has a Layer 3 marking, which can pass successfully through the route processor.

Applying QoS features at the edge of the network (for example, in a wiring closet) offers the following benefits:

  • Provides immediate traffic classification

  • Reduces congestion within the remainder of the network

  • Eases the processor burden on the distribution and core routers

These Quick Reference Sheets primarily focus on the Catalyst 2950 Series of switches. You can configure the Catalyst 2950 ports to trust CoS or DSCP markings. However, by default, these ports are “untrusted,” meaning that they disregard priority markings on incoming traffic. When a port is untrusted, traffic is assigned the configurable CoS value of the port.

The Catalyst 2950 can place frames in one of four queues. Later in these Quick Reference Sheets, you use these queues for Weighted Round Robin (WRR) queuing. For now, however, you should be familiar with how the switch places frames with various CoS markings into its four queues, as described in the following table.

Default Queue Assignment

 

CoS Value

Queue

0 and 1

1

2 and 3

2

4 and 5

3

6 and 7

4


For internal QoS processing, all traffic (even non-IP traffic) is assigned an internal DSCP number. The default CoS-to-DSCP mappings are shown in the following table.

CoS-to-DSCP Mappings

 

CoS Value

DSCP Value

0

0

1

8

2

16

3

24

4

32

5

40

6

48

7

56


Because the Catalyst 2950 uses CoS values to make queuing decisions, before the queuing process, the internal DSCP value is extrapolated to a CoS value. Although mappings are configurable, the default values are shown in the following table.

DSCP-to-CoS Mappings

 

DSCP Values

CoS Value

0

0

8 and 10

1

16 and 18

2

24 and 26

3

32 and 34

4

40 and 46

5

48

6

56

7


With your understanding of the default switch behavior, you can explore how to manipulate the trust settings and the CoS-to-DSCP mappings. The following command tells a port what to trust:

Switch(config-if)#mls qos trust [cos [pass-through dscp] | device cisco-phone | dscp]

The pass-through dscp option does not modify the DSCP values (that is, remark them based on CoS values).

You can use the following command to assign a default CoS value for a port:

Switch(config-if)#mls qos cos {default-cos | override}

The override option applies the default CoS value to a frame, even though a frame might already have a CoS marking.

The following commands allow you to manipulate the default CoS-to-DSCP and DSCP-to-CoS mappings:

Switch(config)#mls qos map cos-dscp dscpvalue1 dscpvalue2 ... dscpvalue8

(Configures CoS-to-DSCP mapping)

For example:

Switch(config)#mls qos map cos-dscp 0 16 24 32 34 40 48 56

In this example, the eight DSCP values that are entered correspond to CoS values 0 through 7.

Switch(config)#mls qos map dscp-cos dscp-list to cos

(Configures DSCP-to-CoS mapping)

For example:

Switch(config)#mls qos map dscp-cos 16 28 24 26 to 1

Figure 15Figure 15 ***

You can associate up to 13 DSCP values with a single CoS value.

The three-step MQC process can also be used on a Catalyst 2950 to perform classification and marking, without as many “match” options as are available on a router platform. Typically, you create a standard or extended IP access-list (or a Layer 2 MAC ACL for non-IP traffic). That access-list can then serve as the match criterion in a class-map. Note, however, that the extended IP access-lists that are available on the Catalyst 2950 do not have all the options that are available on a router. Specifically, you cannot use the access-list to match a range of port numbers.

In the following example, an extended IP access-list matches traffic that is destined for IP address 192.168.0.101. A policy-map then marks traffic that is destined for that host with a DSCP value of 34. Finally, the policy is applied to interface Gigabit Ethernet 0/3 in the inbound direction. The example is as follows:

Switch(config)#access-list 100 permit ip any host 192.168.0.101
Switch(config)#class-map CATCLASS
Switch(config-cmap)#match access-group 100
Switch(config-cmap)#exit
Switch(config)#policy-map CATPOLICY
Switch(config-pmap)#class CATCLASS
Switch(config-pmap-c)#set ip dscp 34
Switch(config-pmap-c)#interface gig 0/3
Switch(config-if)#service-policy input CATPOLICY

A switch’s QoS interface configuration can be verified with the following command:

Switch#show mls qos interface interface-identifier

Use the following command to see how CoS and DSCP values are mapped to one another:

Switch#show mls qos maps [cos-dscp | dscp-cos]

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.

Overview

Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security

Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children

This site is not directed to children under the age of 13.

Marketing

Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out

Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links

This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020