What is the IEEE standard that governs all forms of Ethernet media and interfaces group of answer choices?

Before configuring standard QoS, you must have a thorough understanding of these items:

• Standard QoS concepts.

• Classic Cisco IOS QoS.

• Modular QoS CLI (MQC).

• Understanding of QoS implementation.

• The types of applications used and the traffic patterns on your network.

• Traffic characteristics and needs of your network. For example, is the traffic on your network bursty? Do you need to reserve bandwidth for voice and video streams?

• Bandwidth requirements and speed of the network.

• Location of congestion points in the network.

Quality of service (QoS) consists of the following key components:

• Classification— Classification is the process of distinguishing one type of traffic from another based upon access control lists (ACLs), Differentiated Services Code Point (DSCP), Class of Service (CoS), and other factors.

• Marking and mutation— Marking is used on traffic to convey specific information to a downstream device in the network, or to carry information from one interface in a device to another. When traffic is marked, QoS operations on that traffic can be applied. This can be accomplished directly using the set command or through a table map, which takes input values and translates them directly to values on output.

• Shaping and policing— Shaping is the process of imposing a maximum rate of traffic, while regulating the traffic rate in such a way that downstream devices are not subjected to congestion. Shaping in the most common form is used to limit the traffic sent from a physical or logical interface. Policing is used to impose a maximum rate on a traffic class. If the rate is exceeded, then a specific action is taken as soon as the event occurs.

• Queuing — Queuing is used to prevent traffic congestion. Traffic is sent to specific queues for servicing and scheduling based upon bandwidth allocation. Traffic is then scheduled or sent out through the port.

• Bandwidth—Bandwidth allocation determines the available capacity for traffic that is subject to QoS policies.

• Trust— Trust enables traffic to pass through the device, and the Differentiated Services Code Point (DSCP), precedence, or CoS values coming in from the end points are retained in the absence of any explicit policy configuration.

The following terms are used interchangeably in this QoS configuration guide:

• Upstream (direction towards the device) is the same as ingress.

• Downstream (direction from the device) is the same as egress.

By configuring the quality of service (QoS), you can provide preferential treatment to specific types of traffic at the expense of other traffic types. Without QoS, the device offers best-effort service for each packet, regardless of the packet contents or size. The device sends the packets without any assurance of reliability, delay bounds, or throughput.

The following are specific features provided by QoS:

• Low latency

• Bandwidth guarantee

• Buffering capabilities and dropping disciplines

• Traffic policing

• Enables the changing of the attribute of the frame or packet header

• Relative services

Typically, networks operate on a best-effort delivery basis, which means that all traffic has equal priority and an equal chance of being delivered in a timely manner. When congestion occurs, all traffic has an equal chance of being dropped.

When you configure the QoS feature, you can select specific network traffic, prioritize it according to its relative importance, and use congestion-management and congestion-avoidance techniques to provide preferential treatment. Implementing QoS in your network makes network performance more predictable and bandwidth utilization more effective.

The QoS implementation is based on the Differentiated Services (Diff-Serv) architecture, a standard from the Internet Engineering Task Force (IETF). This architecture specifies that each packet is classified upon entry into the network.

The classification is carried in the IP packet header, using 6 bits from the deprecated IP type of service (ToS) field to carry the classification (class) information. Classification can also be carried in the Layer 2 frame.

To implement QoS, the device must perform the following tasks:

• Traffic classification—Distinguishes packets or flows from one another.

• Traffic marking and policing—Assigns a label to indicate the given quality of service as the packets move through the device, and then make the packets comply with the configured resource usage limits.

• Queuing and scheduling—Provides different treatment in all situations where resource contention exists.

• Shaping—Ensures that traffic sent from the device meets a specific traffic profile.

Classification is the process of distinguishing one kind of traffic from another by examining the fields in the packet. Classification is enabled only if QoS is enabled on the device. By default, QoS is enabled on the device.

During classification, the device performs a lookup and assigns a QoS label to the packet. The QoS label identifies all QoS actions to be performed on the packet and from which queue the packet is sent.

After a packet is classified and has a DSCP-based, CoS-based, or QoS-group label assigned to it, the policing and marking process can begin.

Policing involves creating a policer that specifies the bandwidth limits for the traffic. Packets that exceed the limits are out of profile or nonconforming. Each policer decides on a packet-by-packet basis whether the packet is in or out of profile and specifies the actions on the packet. These actions, carried out by the marker, include passing through the packet without modification, dropping the packet, or modifying (marking down) the assigned DSCP or CoS value of the packet and allowing the packet to pass through.

To avoid out-of-order packets, both conform and nonconforming traffic typically exit the same queue.

Note	All traffic, regardless of whether it is bridged or routed, is subjected to a policer, if one is configured. As a result, bridged packets might be dropped or might have their DSCP or CoS fields modified when they are policed and marked.

You can only configure policing on a physical port.

After you configure the policy map and policing actions, attach the policy-map to an ingress or egress port by using the service-policy interface configuration command.

Marking is used to convey specific information to a downstream device in the network, or to carry information from one interface in a device to another.

Marking can be used to set certain field/bits in the packet headers, or marking can also be used to set certain fields in the packet structure that is internal to the device. Additionally, the marking feature can be used to define mapping between fields. The following marking methods are available for QoS:

• Packet header

• Device specific information

• Table maps

To support QoS in a network, traffic entering the service provider network needs to be policed on the network boundary routers to ensure that the traffic rate stays within the service limit. Even if a few routers at the network boundary start sending more traffic than what the network core is provisioned to handle, the increased traffic load leads to network congestion. The degraded performance in the network makes it difficult to deliver QoS for all the network traffic.

Traffic policing functions (using the police feature) and shaping functions (using the traffic shaping feature) manage the traffic rate, but differ in how they treat traffic when tokens are exhausted. The concept of tokens comes from the token bucket scheme, a traffic metering function.

Note	When running QoS tests on network traffic, you may see different results for the shaper and policing data. Network traffic data from shaping provides more accurate results.

This table compares the policing and shaping functions.

The device uses both queuing and scheduling to help prevent traffic congestion. The device supports the following queuing and scheduling features:

• Bandwidth

• Weighted Tail Drop

• Priority queues

• Queue buffers

• Weighted Random Early Detection

In a typical network, you connect a Cisco IP Phone to a device port and cascade devices that generate data packets from the back of the telephone. The Cisco IP Phone guarantees the voice quality through a shared data link by marking the CoS level of the voice packets as high priority (CoS = 5) and by marking the data packets as low priority (CoS = 0). Traffic sent from the telephone to the device is typically marked with a tag that uses the 802.1Q header. The header contains the VLAN information and the class of service (CoS) 3-bit field, which is the priority of the packet.

For most Cisco IP Phone configurations, the traffic sent from the telephone to the device should be trusted to ensure that voice traffic is properly prioritized over other types of traffic in the network. By using the trust device interface configuration command, you configure the device port to which the telephone is connected to trust the traffic received on that port.

Note

The trust device device_type command available in interface configuration mode is a stand-alone command on the device. When using this command in an AutoQoS configuration, if the connected peer device is not a corresponding device (defined as a device matching your trust policy), both CoS and DSCP values are set to "0" and any input policy will not take effect. If the connected peer device is a corresponding device, input policy will take effect.

With the trusted setting, you also can use the trusted boundary feature to prevent misuse of a high-priority queue if a user bypasses the telephone and connects the PC directly to the device. Without trusted boundary, the CoS labels generated by the PC are trusted by the device (because of the trusted CoS setting). By contrast, trusted boundary uses CDP to detect the presence of a Cisco IP Phone (such as the Cisco IP Phone 7910, 7935, 7940, and 7960) on a device port. If the telephone is not detected, the trusted boundary feature disables the trusted setting on the device port and prevents misuse of a high-priority queue. Note that the trusted boundary feature is not effective if the PC and Cisco IP Phone are connected to a hub that is connected to the device.

For wired ports that are connected to the device (end points such as IP phones, laptops, cameras, telepresence units, or other devices), their DSCP, precedence, or CoS values coming in from these end points are trusted by the device and therefore are retained in the absence of any explicit policy configuration.

The packets are enqueued to the appropriate queue per the default initial configuration. No priority queuing at the device is done by default. This is true for unicast and multicast packets.

In scenarios where the incoming packet type differs from the outgoing packet type, the trust behavior and the queuing behavior are explained in the following table. Note that the default trust mode for a port is DSCP based. The trust mode ‘falls back’ to CoS if the incoming packet is a pure Layer 2 packet. You can also change the trust setting from DSCP to CoS. This setting change is accomplished by using an MQC policy that has a class default with a 'set cos cos table default default-cos' action, where default-cos is the name of the table map created (which only performs a default copy).

There are two queues configured by default on each wired interface on the device. All control traffic traverses and is processed through queue 0. All other traffic traverses and is processed through queue 1.

A target is an entity where a policy is applied. A wired target can be either a port or VLAN.

The following are restrictions for applying QoS features on the device for the wired target:

• A maximum of 8 queuing classes are supported on the device port for the wired target.

• A maximum of 63 policers are supported per policy on the wired port for the wired target, in the ingress or egress directions.

• A maximum of 1599 policy-maps can be created.

• No more than two levels are supported in a QoS hierarchy.

• In a hierarchical policy, overlapping actions between parent and child are not allowed, except when a policy has the port shaper in the parent and queuing features in the child policy.

• A QoS policy cannot be attached to any EtherChannel interface.

• Policing in both the parent and child is not supported in a QoS hierarchy.

• Marking in both the parent and child is not supported in a QoS hierarchy.

• With shaping, there is an IPG overhead of 20Bytes for every packet that is accounted internally in the hardware. Shaping accuracy will be effected by this, specially for packets of small size.

• Class-maps with empty actions are not supported. If there are two policies with the same order of class-maps and if there are class-maps with no action in one of the policies, there may be traffic drops. As a workaround, allocate minimal bandwidth for all the classes in PRIORITY_QUEUE.

• A maximum of 256 classes are supported per policy on the wired port for the wired target.

• Based on the Cisco UADP architecture, traffic is subjected to QoS lookup and the corresponding configured actions even if this traffic is later dropped in the Egress Global Resolution block and is never transmitted out of the actual interface.

• The actions under a policer within a policy map have the following restrictions:

  • The conform action must be transmit.

  • The exceed/violate action for markdown type can only be cos2cos, prec2prec, dscp2dscp.

  • The markdown types must be the same within a policy.

• Only marking policy is supported on SVI.

• A port-level input marking policy takes precedence over an SVI policy; however, if no port policy is configured, the SVI policy takes precedence. For a port policy to take precedence, define a port-level policy; so that the SVI policy is overwritten.

• Classification counters have the following specific restrictions:

  • Classification counters count packets instead of bytes.

  • Filter-based classification counters are not supported

  • Only QoS configurations with marking or policing trigger the classification counter.

  • As long as there is policing or marking action in the policy, the class will have classification counters.

  • Classification counters are not supported on pure queuing policies under any class-map.

  • When there are multiple match statements in a class, the traffic counter is cumulative for all the match statements in the class.

• The device supports a total of eight table maps for policer exceed markdown and eight table maps for policer violate markdown.

• Hierarchical policies are required for the following:

  • Port-shapers

  • Aggregate policers

  • PV policy

  • Parent shaping and child marking/policing

• In a HQoS policy with parent shaping and child policy having priority level queuing and priority level policing, the statistics for policing are not updated. Only QoS shaper statistics are updated. To view the QoS shaper statistics, use the show policy-map interface command in global configuration mode.

• For ports with wired targets, these are the only supported hierarchical policies:

  • Police chaining in the same policy is unsupported.

  • Hierarchical queuing is unsupported in the same policy (port shaper is the exception).

  • In a parent class, all filters must have the same type. The child filter type must match the parent filter type with the following exceptions:

    • If the parent class is configured to match IP, then the child class can be configured to match the ACL.

    • If the parent class is configured to match CoS, then the child class can be configured to match the ACL.

• The trust device device_type command available in interface configuration mode is a stand-alone command on the device. When using this command in an AutoQoS configuration, if the connected peer device is not a corresponding device (defined as a device matching your trust policy), both CoS and DSCP values are set to "0" and any input policy will not take effect. If the connected peer device is a corresponding device, input policy will take effect.

The following are restrictions for applying QoS features on the VLAN to the wired target:

• For a flat or nonhierarchical policy, only marking or a table map is supported.

The following are restrictions and considerations for applying QoS features on EtherChannel and channel member interfaces:

• QoS is not supported on an EtherChannel interface.

• QoS is supported on EtherChannel member interfaces in both ingress and egression directions. All EtherChannel members must have the same QoS policy applied. If the QoS policy is not the same, each individual policy on the different link acts independently.

• On attaching a service policy to channel members, the following warning message appears to remind the user to make sure the same policy is attached to all ports in the EtherChannel: ' Warning: add service policy will cause inconsistency with port xxx in ether channel xxx. '.

• Auto QoS is not supported on EtherChannel members.

Note

On attaching a service policy to an EtherChannel, the following message appears on the console: ' Warning: add service policy will cause inconsistency with port xxx in ether channel xxx. '. This warning message should be expected. This warning message is a reminder to attach the same policy to other ports in the same EtherChannel. The same message will be seen during boot up. This message does not mean there is a discrepancy between the EtherChannel member ports.

Depending on the complexity of your network and your QoS solution, you may need to perform all of the procedures in this section. You need to make decisions about these characteristics:

• Which packets are mapped by DSCP, CoS, or QoS group value to each queue and threshold ID?

• What drop percentage thresholds apply to the queues, and how much reserved and maximum memory is needed for the traffic type?

• How much of the fixed buffer space is allocated to the queues?

• Does the bandwidth of the port need to be rate limited?

• How often should the egress queues be serviced and which technique (shaped, shared, or both) should be used?

Note	You can only configure the egress queues on the device.

The following commands can be used to monitor QoS on the .

This example shows how to classify packets for QoS by using access control lists (ACLs):

After creating a class map by using an ACL, you then create a policy map for the class, and apply the policy map to an interface for QoS.

This example shows how to classify packets for QoS using a class of service Layer 2 classification:

After creating a class map by using a CoS Layer 2 classification, you then create a policy map for the class, and apply the policy map to an interface for QoS.

This example shows how to classify packets for QoS using a class of service DSCP classification:

After creating a class map by using a DSCP classification, you then create a policy map for the class, and apply the policy map to an interface for QoS.

This example shows how to classify for QoS using a VLAN ID Layer 2 classification:

After creating a class map by using a VLAN Layer 2 classification, you then create a policy map for the class, and apply the policy map to an interface for QoS.

This example shows how to classify packets by using DSCP or precedence values:

After creating a class map by using a DSCP or precedence values, you then create a policy map for the class, and apply the policy map to an interface for QoS.

The following is an example of a hierarchical classification, where a class named parent is created, which matches another class named child. The class named child matches based on the IP precedence being set to 2.

After creating the parent class map, you then create a policy map for the class, and apply the policy map to an interface for QoS.

The following is an example of a configuration using hierarchical polices:

This example describes how to classify packet streams for voice and video using device specific information.

In this example, voice and video are coming in from end-point A into GigabitEthernet1/0/1 on the device and have precedence values of 5 and 6, respectively. Additionally, voice and video are also coming from end-point B into GigabitEthernet1/0/2 on the device with DSCP values of EF and AF11, respectively.

Assume that all the packets from the both the interfaces are sent on the uplink interface, and there is a requirement to police voice to 100 Mbps and video to 150 Mbps.

To classify per the above requirements, a class to match voice packets coming in on GigabitEthernet1/0/1 is created, named voice-interface-1, which matches precedence 5. Similarly another class for voice is created, named voice-interface-2, which will match voice packets in GigabitEthernet1/0/2. These classes are associated to two separate policies named input-interface-1, which is attached to GigabitEthernet1/0/1, and input-interface-2, which is attached to GigabitEthernet1/0/2. The action for this class is to mark the qos-group to 10. To match packets with QoS-group 10 on the output interface, a class named voice is created which matches on QoS-group 10. This is then associated to another policy named output-interface, which is associated to the uplink interface. Video is handled in the same way, but matches on QoS-group 20.

The following example shows how classify using the above device specific information:

The following example shows how to configure average rate shaping:

After configuring the class maps, policy map, and shape averages for your configuration, proceed to then apply the policy map to the interface for QoS.

The following example shows how to configure a queue-limit policy based upon DSCP values and percentages:

After finishing with the above policy map queue-limit configuration, you can then proceed to apply the policy map to an interface for QoS.

The following example shows how configure a queue buffer policy and then apply it to an interface for QoS:

The following example displays the various policing actions that can be associated to the policer. These actions are accomplished using the conforming, exceeding, or violating packet configurations. You have the flexibility to drop, mark and transmit, or transmit packets that have exceeded or violated a traffic profile.

For example, a common deployment scenario is one where the enterprise customer polices traffic exiting the network towards the service provider and marks the conforming, exceeding and violating packets with different DSCP values. The service provider could then choose to drop the packets marked with the exceeded and violated DSCP values under cases of congestion, but may choose to transmit them when bandwidth is available.

Note	The Layer 2 fields can be marked to include the CoS fields, and the Layer 3 fields can be marked to include the precedence and the DSCP fields.

One useful feature is the ability to associate multiple actions with an event. For example, you could set the precedence bit and the CoS for all conforming packets. A submode for an action configuration could then be provided by the policing feature.

This is an example of a policing action configuration:

In this example, the exceed-markdown-table and violate-mark-down-table are table maps.

Note	Policer-based markdown actions are only supported using table maps. Only one markdown table map is allowed for each marking field in the device.

The following example displays a VLAN policer configuration. At the end of this configuration, the VLAN policy map is applied to an interface for QoS.

The policing unit is the basis on which the token bucket works. CIR and PIR are specified in bits per second. The burst parameters are specified in bytes. This is the default mode; it is the unit that is assumed when no units are specified. The CIR and PIR can also be configured in percent, in which case the burst parameters have to be configured in milliseconds.

The following is an example of a policer configuration in bits per second. In this configuration, a dual-rate three-color policer is configured where the units of measurement is bits. The burst and peak burst are all specified in bits.

The following example shows how to configure a single-rate two-color policer:

The following example shows how to configure a dual-rate three-color policer:

In this example, the exceed-markdown-table and violate-mark-down-table are table maps.

Note	Policer based markdown actions are only supported using table maps. Only one markdown table map is allowed for each marking field in the device.

The following steps and examples show how to use table map marking for your QoS configuration:

1. Define the table map.

   Define the table-map using the table-map command and indicate the mapping of the values. This table does not know of the policies or classes within which it will be used. The default command in the table map indicates the value to be copied into the ‘to’ field when there is no matching ‘from’ field. In the example, a table map named table-map1 is created. The mapping defined is to convert the value from 0 to 1 and from 2 to 3, while setting the default value to 4.

   (config)# table-map table-map1 (config-tablemap)# map from 0 to 1 (config-tablemap)# map from 2 to 3 (config-tablemap)# default 4 (config-tablemap)# exit

2. Define the policy map where the table map will be used.

   In the example, the incoming CoS is mapped to the DSCP based on the mapping specified in the table table-map1. For this example, if the incoming packet has a DSCP of 0, the CoS in the packet is set 1. If no table map name is specified the command assumes a default behavior where the value is copied as is from the ‘from’ field (DSCP in this case) to the ‘to’ field (CoS in this case). Note however, that while the CoS is a 3-bit field, the DSCP is a 6-bit field, which implies that the CoS is copied to the first three bits in the DSCP.

   (config)# policy map policy1 (config-pmap)# class class-default (config-pmap-c)# set cos dscp table table-map1 (config-pmap-c)# exit

3. Associate the policy to an interface.

   (config)# interface GigabitEthernet1/0/1 (config-if)# service-policy output policy1 (config-if)# exit

The following example shows how to use table maps to retain CoS markings on an interface for your QoS configuration.

The cos-trust-policy policy (configured in the example) is enabled in the ingress direction to retain the CoS marking coming into the interface. If the policy is not enabled, only the DSCP is trusted by default. If a pure Layer 2 packet arrives at the interface, then the CoS value will be rewritten to 0 when there is no such policy in the ingress port for CoS.

Review the auto-QoS documentation to see if you can use these automated capabilities for your QoS configuration.

This table provides release and related information for features explained in this module.

These features are available on all releases subsequent to the one they were introduced in, unless noted otherwise.

Use Cisco Feature Navigator to find information about platform and software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn.