mpls experimental qos

• Artificial Intelligence
• Generative AI
• Cloud Computing
• CPUs and Processors
• Data Center
• Edge Computing
• Enterprise Storage
• Virtualization
• Enterprise Buyer’s Guides
• Internet of Things
• Network Management Software
• Network Security
• United States
• Newsletters
• Foundry Careers
• Terms of Service
• Privacy Policy
• Cookie Policy
• Copyright Notice
• Member Preferences
• About AdChoices
• E-commerce Links
• Your California Privacy Rights

Our Network

• Computerworld

Business cases for MPLS and quality of service (QoS)

Cisco press.

A good example where QoS is needed is VoIP traffic. VoIP traffic needs to be delivered within a certain time to the destination, or it becomes obsolete. Therefore, QoS should prioritize the VoIP traffic to ensure that it is delivered within a certain time constraint. To achieve this, it is possible within Cisco IOS to queue VoIP with a higher priority than FTP or HTTP traffic and to make sure that if congestion occurs, FTP or HTTP traffic is dropped ahead of the VoIP traffic. Cisco IOS has several mechanisms to do this on a router. Refer to Table 12-1 for examples of QoS functions and features in Cisco IOS.

Table 12-1 QoS Functions and Corresponding Cisco IOS-Enabling Features

You can set the priority of an IP packet either in the IP Precedence field (three bits) or in the six bits of the DiffServ Codepoint field (DSCP). Originally, only three bits of the Type of Service field (TOS) in the IP header were reserved for QoS. The number of bits in the IP header that could be used for QoS was later increased to six with the introduction of DiffServ QoS.

DiffServ with IP Packets

Refer to Figure 12-1 to refresh your memory about what the IP header looks like.

Figure 12-1

IP Header Fields

Figure 12-2 shows you how the TOS field is divided.

Figure 12-2

The TOS Byte of the IP Header Defining the Precedence Bits

The usage of the precedence bits for QoS is now widely used throughout the world for many networks. The drawback of the precedence bits, however, is that only three exist, which means you can have only eight levels of service. Therefore, the IETF decided to dedicate more bits for QoS. The four TOS bits were deprecated, and three of them were assigned to DiffServ QoS, in addition to the three precedence bits. DiffServ ended up with six bits, providing more than enough levels of QoS. Figure 12-3 shows you which bits of the TOS byte are used for DiffServ.

Figure 12-3

The TOS Byte of the IP Header Defining the DSCP per RFC 2474

Two types of forwarding classes within the DiffServ model are defined: expedited forwarding (EF) and assured forwarding (AF). EF is a low loss, low latency, low jitter, assured bandwidth, end-to-end service through a DiffServ domain. AF defines different services of forwarding assurances through a DiffServ domain. Four classes of AF are defined, each with three drop precedence. AF classes are noted as AFij, with i being 1 to 4 for the class and j being 1 to 3 for the drop precedence. The first three bits of the six-bit DSCP field define the class, the next two bits define the drop precedence, and the last bit is reserved. The higher the drop precedence inside a class, the more likely the packet is to be dropped, relative to the other packets with lower drop precedence when congestion occurs. Four classes exist for the traffic, and three levels exist for drop precedence. AF23, for example, denotes class 2 and drop precedence 3. Table 12-2 shows the recommended values for the four assured forwarding classes.

Table 12-2 Recommended Values for the Four AF Classes

Table 12-3 shows you the four AF classes, each with three drop precedence.

Table 12-3 Four AF Classes and Three Drop Precedence

If you are using EF, the recommended DiffServ field is 101110 (decimal 46). The default class is 0 or 000000 in binary. In Cisco IOS, you can find all these values when configuring QoS with the Modular QoS Command Line Interface (MQC). Example 12-1 shows how to configure the router to match a certain DSCP in a class map on a router.

Example 12-1 Matching DSCP in a Class Map

You can match any of the 64 DSCP values (0–63) just by configuring that DSCP value. You can also match the AF classes, the Class Selector (CS)—if you only want to match the first three bits of the DSCP—, the default class, and the EF class.

DiffServ with MPLS Packets

Remember the syntax of a label from Chapter 2, “MPLS Architecture”? Figure 12-4 is a refresher.

Figure 12-4

Syntax of an MPLS Label

As you can see, there are three EXP, or experimental, bits. They are called experimental, but they are really used only for QoS. You can use these bits in the same way that you use the three precedence bits in the IP header. If you use these three bits for QoS, you can call the label switched path (LSP) an E-LSP, indicating that the label switching router (LSR) will use the EXP bits to schedule the packet and decide on the drop precedence. However, when you are using MPLS, you have another option for implementing QoS for the labeled packets. An LSP is a signaled path through the network between two routers. You can use the label on top of the packet to imply part of the QoS for that packet. However, then you need one label per class for each flow of traffic between the two endpoints of the LSP. Therefore, the signaling protocol has to be able to signal a different label for the same LSP or prefix. Such an LSP is called an L-LSP, indicating that the label implicitly holds part of the QoS information. With an L-LSP, the EXP bits still hold part of the QoS, but only the drop precedence, whereas the label indicates the class. With an E-LSP, the EXP bits hold both the class and the drop precedence information. Because Cisco IOS implements only E-LSPs, this chapter looks only at E-LSPs when describing how to implement QoS in MPLS networks.

When an LSR forwards a labeled packet, it needs only to look up the top label in its label forwarding table (LFIB) to decide where to forward the packet. The same is true for the QoS treatment. The LSR needs only to look at the EXP bits of the top label to determine how to treat this packet. Remember that QoS constitutes traffic marking, congestion management, congestion avoidance, and traffic conditioning and that you can use low-latency queuing (LLQ), class-based weighted fair queueing (CBWFQ), weighted random early detection (WRED), policing, and shaping to implement this for IP packets. You can use the same features to implement QoS based on the EXP bits for labeled packets. For example, WRED has been modified to look at the EXP bits to determine the drop precedence of labeled packets when being queued. The preferred way to configure MPLS QoS in Cisco IOS is by means of the Modular Quality of Service Command Line Interface (MQC). MQC is an easy, straightforward way of configuring the different QoS building blocks on the router.

Default MPLS QoS Behavior in Cisco IOS

In Cisco IOS, the default behavior when imposing one or more labels on an IP packet is to copy the precedence value to the EXP bits of all imposed labels. This is called TOS reflection, because nothing regarding QoS changes by default. If, however, the six bits of the DSCP field are used, only the first three bits of DSCP are copied to the EXP bits of the labels. This leads to the first MPLS QoS rule.

MPLS QoS Rule 1: By default, in Cisco IOS, the precedence bits or the first three bits of the DSCP field in the IP header are copied to the EXP bits of all imposed labels at the ingress LSR.

Forwarding a labeled packet is a bit more complicated. You have to distinguish two cases: swapping a label, and possibly imposing one or more labels on the one hand and disposing one or more labels on the other hand. In the case of swapping an incoming label with an outgoing label on the LSR, the EXP bits are copied from the incoming label to the outgoing label. The same is true when swapping a label and then imposing one or more labels. The value of the EXP bits is copied from the incoming label to the swapped outgoing label and also to the labels that are then pushed on top of the swapped label. However, forwarding a labeled packet in the disposition mode, meaning that a label is popped, is quite different. When the router forwards a labeled packet and issues a pop, the value of the EXP bits is not copied to the newly exposed label or to the IP Precedence field (or possibly the DSCP field) of the IP header, if the packet becomes unlabeled. This means that, by default, in Cisco IOS, the EXP bits of the newly exposed label or the IP precedence/DSCP field of the newly exposed IP header remains unchanged and dictate the new QoS of the packet. This leads to the second, third, and fourth MPLS QoS rule.

MPLS QoS Rule 2: By default, in Cisco IOS, the EXP bits of the incoming top label are copied to the swapped outgoing label and to any label pushed onto that.

MPLS QoS Rule 3: By default, in Cisco IOS, the EXP bits of the incoming top label are not copied to the newly exposed label when the incoming label is popped.

MPLS QoS Rule 4: By default, in Cisco IOS, the EXP bits of the incoming top label are not copied to the precedence bits or DSCP bits when the label stack is removed and the IP header becomes exposed.

Furthermore, when you use MQC to change the QoS of the labeled packet, only the top label and possible pushed labels receive the new value for the EXP bits. The labels underneath the top label in the label stack do not receive the new value for the EXP bits. The precedence bits or DSCP bits do not change either. This means that when you manually change the QoS of a labeled packet on a certain LSR, that packet changes its QoS value sometime later in the network. Namely, when the label is popped off, the value of the EXP bits of the incoming top label is not copied to the newly exposed label, following MPLS QoS Rule 3. That means that the old QoS value of the packet is now active again. This actually happens frequently, because penultimate hop popping (PHP) is the default behavior in Cisco IOS. It happens by default in many MPLS networks and is something to watch out for. If you want to keep the new QoS value of the packet, you need to configure Cisco IOS commands to make sure that the QoS is copied down at disposition time. You will read more about that later in this chapter. This leads to the fifth MPLS QoS rule.

MPLS QoS Rule 5: When you change the EXP bits value through configuration, the value of the EXP bits in labels other than the top label, the swapped label, or the imposed labels and the precedence bits or DSCP bits in the IP header remain unchanged.

MPLS QoS Rules 4 and 5 lead to the fact that QoS tunneling becomes available. This means that the QoS value of the IP packet is transported through the MPLS network without change.

Look at Figure 12-5 . You can see a Label Switch Router (LSR) with two interfaces. The left interface is the ingress interface, and the right is the egress interface. An IP packet or labeled packet comes in on the left interface and leaves the router on the right interface. This chapter uses this simple drawing throughout to clearly show the behavior of the EXP bits when a packet goes through the router. In each figure, the IP packet is the rectangle in the clear, and a label is one gray rectangle on top of the IP packet. In the IP packet, the QoS information is shown as the DSCP value. Each label also shows the EXP bits value.

Figure 12-5

Sample LSR Drawing with an Ingress and an Egress Interface

Figure 12-6 shows you the default treatment by Cisco IOS of the EXP bits in the label(s) when imposing, swapping, or disposing of labels. When you imply the five MPLS QoS rules, you get the default forwarding treatment that is shown in Figure 12-6 .

Figure 12-6

Default Treatment by Cisco IOS of the EXP Bits When Imposing, Swapping, and Disposing of MPLS Labels

The first two pictures show you TOS reflection. By default, the IP precedence (or first three bits of DSCP) is copied to the imposed labels. This is MPLS QoS Rule 1. The third picture shows you that the EXP bits of the top label of the incoming packet are copied to the swapped label and the pushed label(s). This is MPLS QoS Rule 2. The fourth and fifth pictures are again examples of MPLS QoS Rule 2, but now they show that the EXP bits of the labels, which are below the top label at the ingress interface, are not changed (MPLS QoS Rule 5). The sixth picture shows you an example of MPLS QoS Rule 3, and the seventh picture is an example of MPLS QoS Rule 4.

DiffServ Tunneling Models

MPLS QoS Rule 4 causes an interesting behavior: Regardless of what the MPLS EXP value was changed to at the ingress LSR or any other LSR, that value is not copied to the exposed IP packet at the egress LSR of the MPLS network. In effect, this enables the operator of the MPLS cloud to carry the QoS value of the IP packet transparently through the MPLS network. No matter how many times the EXP bits are changed, by default, the IP precedence or DSCP bits of the IP packet are preserved; the value at the egress LSR is the same as when the IP packet entered the MPLS network. You can now tunnel the DiffServ value of the IP packet through the MPLS network (hence the name DiffServ Tunneling). The obvious advantage is that the MPLS network can have a different QoS scheme than the customers who connect to it, because the MPLS QoS scheme can be independent from the IP QoS scheme of the customers. The IETF has defined three models to tunnel the DiffServ information. All three models are distinct and have their own merits. Furthermore, the distinction between the three models is only at the edge LSRs. The P routers do not come into play with regard to the different DiffServ tunneling models.

Consider Figure 12-7 .

Figure 12-7

General Operation of the MPLS DiffServ Tunneling Models

The Tunneled Diffserv information is the QoS of the labeled packets or the precedence/DSCP of the IP packets coming into the ingress LSR of the MPLS network. The LSP DiffServ information is the QoS (the value of the EXP bits) of the MPLS packets transported on the LSP from the ingress LSR to the egress LSR. The Tunneled DiffServ information is the QoS information that needs to get across the MPLS network transparently, whereas the LSP DiffServ information is the QoS information that all LSRs in this MPLS network use when forwarding the labeled packet.

In the Pipe model, the following rules apply:

The LSP DiffServ information is not necessarily (but might be) derived from the Tunneled DiffServ information on the ingress LSR.

On an intermediate LSR (a P router), the LSP DiffServ information of the outgoing label is derived from the LSP DiffServ information of the incoming label.

On the egress LSR, the forwarding treatment of the packet is based on the LSP DiffServ information, and the LSP DiffServ information is not propagated to the Tunneled DiffServ information.

Note – Forwarding treatment here means classifying the packet for scheduling and discarding behavior at the output interface.

If the MPLS network is receiving IP packets on the ingress LSR and the MPLS network is using E-LSPs only, the Pipe model becomes a bit easier to explain. The Tunneled DiffServ information is the precedence bits or the DSCP of the IP packet. The LSP DiffServ information is the EXP bits value of the labels in the MPLS network. The forwarding treatment (classifying and discard behavior) of IP packets is based on the precedence bits or DSCP in the IP header. This is called the IP PHB (per-hop behavior) hereafter. The forwarding treatment op MPLS packets is based on the EXP bits. This is called the MPLS PHB (per-hop behavior) hereafter.

The rules for the Pipe model now translate into the following:

The EXP bits can be copied from the IP precedence or set through configuration on the ingress LSR.

On a P router, the EXP bits are propagated from incoming label to outgoing label.

On the egress LSR, the forwarding treatment of the packet is based on the MPLS PHB (EXP bits), and the EXP bits are not propagated to the IP precedence.

Short Pipe Model

The Short Pipe model is similar to the Pipe model, with one difference. The forwarding treatment on the egress LSR is different for the Short Pipe model. Therefore, the third bullet becomes this:

On the egress LSR, the forwarding treatment of the packet is based on the Tunneled DiffServ information , and the LSP DiffServ information is not propagated to the Tunneled DiffServ information.

If the MPLS network is receiving IP packets on the ingress LSR, that third bullet becomes this:

On the egress LSR, the forwarding treatment of the packet is based on the IP PHB (IP precedence) , and the EXP bits are not propagated to the IP precedence.

Uniform Model

The Uniform model is quite different from the Pipe or Short Pipe model. In the Uniform model, the following rules apply:

The LSP DiffServ information must be derived from the Tunneled DiffServ information on the ingress LSR.

On the egress LSR, the LSP DiffServ information must be propagated to the Tunneled DiffServ information.

Notice the change in the first bullet: The LSP DiffServ information must be derived from the Tunneled DiffServ information on the ingress LSR. On the egress LSR, the Tunneled DiffServ information is derived from the LSP DiffServ information. This means that a packet belongs to the same QoS class at any time. The QoS information is always present in the topmost label or in the IP header if the packet is not labeled. The MPLS network does not have an impact on the QoS information, but it does switch the packets through the MPLS network, of course.

You can instruct the router to change the EXP bits of the top label(s) through configuration (by using MQC in Cisco IOS) anywhere in the MPLS cloud. This only changes the outer QoS information, or the LSP DiffServ information. This change in the LSP DiffServ information is not propagated down to the Tunneled DiffServ information in the Pipe model and Short Pipe model on the egress LSR. It is, however, propagated on the egress LSR when you are using the Uniform model.

In Cisco IOS, the configuration that you need to enable one of the three DiffServ Tunneling models is MQC. MQC is configurable per interface. Therefore, you can choose the DiffServ Tunneling model per interface—hence, per customer connecting to the MPLS network. The only LSRs where this configuration is needed are the ingress and egress LSRs. On those routers, the specific DiffServ Tunneling model is determined.

Figure 12-8 shows you the three tunneling models in the case of an MPLS virtual private network (VPN). The packets that are entering and exiting the MPLS VPNs are IP packets. Therefore, the Tunneled DiffServ information translates to the DSCP bits in the IP header, and the LSP DiffServ information translates to the EXP bits in the MPLS labels.

Figure 12-8

Three DiffServ Tunneling Models for MPLS VPN

Note – The MPLS DiffServ Tunneling models are described in RFC 3270, “Multi-Protocol Label Switching (MPLS) Support of Differentiated Services.”

Advantages of the DiffServ Tunneling Models

The usefulness of the Uniform model is that there is only one DiffServ information for a packet. This is the DiffServ information encoded in the top label. Whether this is different from the underlying DiffServ information is not important, because the top DiffServ information is propagated down at the egress LSR of the LSP.

The advantage for both the Short Pipe model and the Pipe model is that the original Tunneled DiffServ information is preserved when the packet leaves the MPLS network. That means that the IP DiffServ information or the tunneled MPLS DiffServ information remains unchanged. When customers connect to the MPLS network, their QoS information is tunneled transparently through the MPLS network. Furthermore, if customers have their own rules for QoS, the MPLS service provider, who imposes his own rules on the packets at the ingress LSR without changing the original QoS of the packet, can ignore the customers’ rules. This is a lot more scalable than catering for the QoS of each customer. Because a label has only three EXP bits, the MPLS service provider has to fit each QoS level of every customer into one of a maximum of eight levels of QoS in the MPLS network.

The difference between the Short Pipe model and the Pipe model is visible only at the egress LSR. The egress LSR forwards packets according to the LSP DiffServ information when you have the Pipe model and according to the Tunneled DiffServ information when you have the Short Pipe model. This means that in the Short Pipe model, the packets are forwarded on the egress LSR according to some QoS that is different for each customer. In the Pipe model, the packets are forwarded on the egress LSR according to the QoS of the LSP of the MPLS network. This latter model greatly reduces the QoS configuration because it is the same for all traffic. In contrast, with the Short Pipe model, you need a different QoS configuration for each customer (or for each outgoing link).

The Pipe model does have one requirement for it to work. The egress LSR must forward the packets based on the LSP DiffServ information. That means that the implicit NULL label cannot be used in the case of plain IP-over-MPLS (in this case the labeled packets have only one label in the label stack), as explained in the paragraphs that follow. In Figure 12-9 , you can see a plain IP-over-MPLS network with the implicit NULL label.

Figure 12-9

Plain IP-over-MPLS with Implicit NULL Label

From Chapter 3, “Forwarding Labeled Packets,” you know that using the implicit NULL label is called PHP and that it causes the penultimate LSR to forward the packets with one label fewer, because of a pop operation. If this is a plain IP-over-MPLS network, only one label is on top of the incoming packets on that LSR, so the packets are then forwarded to the last LSR as IP packets. If you are running the Pipe model, the egress LSR cannot forward the packet based on the MPLS EXP bits (the LSP DiffServ information) because the packet no longer has a label. Furthermore, if you are running the Uniform model, you can no longer copy the EXP bits value from the label into the IP precedence or DSCP bits on the egress LSR. The obvious solution for this problem is to use the explicit NULL label instead of the implicit NULL label, which Cisco IOS uses by default. Then the egress LSR signals an explicit NULL label toward the penultimate LSR. As you have seen already, both LDP and RSVP (for traffic engineering) can signal the explicit NULL label. The only function of the explicit NULL label is to carry the QoS information in the EXP bits. Figure 12-10 shows the same network as Figure 12-9 , but now with the explicit NULL label.

Figure 12-10

Plain IP-over-MPLS with Explicit NULL Label

The problem is not present only with plain IP-over-MPLS. What if you have an MPLS VPN network? By default, it also has PHP. What if someone alters the EXP bits on a P router? The result will be that the top label will have a different value for the EXP bits than the label underneath. That is okay as long as no labels are popped off. However, when a label is popped off at the penultimate LSR, the value of the EXP bits is not copied to the newly exposed label. Therefore, in the case of MPLS VPN and PHP, the label on top of the packet on the egress LSR is the VPN label, and it has the EXP bits that were set on the ingress PE. That means the alteration of the EXP bits on a P router is lost. Also, in the case of MPLS VPN, the solution is to have the egress PE advertise the explicit NULL label. In that instance, the packet arrives at the egress PE with two labels. The top label is the explicit NULL label that holds the MPLS QoS information.

How to Implement the Three DiffServ Tunneling Models

The distinction between the three models is made only on the ingress and egress LSR. For the three models, no configuration is needed on the ingress LSR assuming that the service provider is willing to accept the DiffServ information set by the customer as the LSP DiffServ information in the MPLS core. The reason for that is MPLS QoS Rules 1 and 2. However, for the Uniform model, this is a requirement, whereas for the Pipe and Short Pipe models, the ingress LSR could set other values for the EXP bits. Because the customer connecting to the MPLS service provider could set the DiffServ information of the packets to anything, the service provider would most likely choose to set the EXP bits at the ingress LSR to values he has chosen.

On the egress LSR, all three models are distinct. For the Uniform model, the LSP DiffServ information must be propagated to the Tunneled DiffServ information. This is not done by default in Cisco IOS. Therefore, you have to configure qos-group on the router by using MQC. You can match the EXP bits on the ingress interface of the egress LSR and set the qos-group respectively. In contrast, on the egress interface of the egress LSR, you match the qos-group and set the EXP bits of the outgoing labeled packet or the IP precedence/DSCP of the outgoing IP packet. This propagation of the EXP bits must also be done on P routers in the case of a pop label operation if the EXP bits were changed somewhere upstream. The propagation on the egress LSR cannot be done for the Pipe and Short Pipe models because then the original Tunneled DiffServ information would be overwritten by the LSP DiffServ information.

For the Pipe model, make sure that the egress LSR forwards the packets based on the LSP DiffServ information. That means you can either use the explicit NULL label in order to avoid PHP; or, if you do use the implicit NULL label, use qos-group on the penultimate LSR to copy the EXP bits of the incoming label to the exposed label after the pop operation. This is needed when the EXP bits were changed somewhere upstream. In the case of plain IP-over-MPLS, there is only one label in the label stack, and therefore you must avoid PHP.

For the Short Pipe model, the egress LSR forwards the packet based on the Tunneled DiffServ information. In that case, you can use implicit NULL, because the egress LSR no longer needs the LSP DiffServ information to forward the packet.

Recoloring the Packet

The MPLS network can encounter congestion, so the operator might want to recolor some packets. This recoloring means the router configuration is used to change the LSP DiffServ information of the packet on any LSR. In effect, the top label gets a new value for the EXP bits. This is allowed, but make sure that this change in QoS is propagated when a label is popped off. A label is popped off when using implicit NULL for PHP. PHP does not happen only at the egress LSR of the MPLS network. A label can also be popped at the tail LSR of a TE tunnel, which is not necessarily the egress LSR of the MPLS network. In the case of popping a label at an LSR, you can configure qos-group to propagate the QoS information. You need to do this for all three models if the pop operation is on an intermediate LSR.

In addition, for the Uniform model, make sure that at the egress LSR, you copy the QoS information to the labeled or IP packet that is leaving the egress LSR.

Figures 12-11 and 12-12 show examples of a packet being recolored on a P router in an MPLS VPN network.

Figure 12-11

Recoloring a Packet in an MPLS VPN Network for the Pipe and Short Pipe Models

Figure 12-12

Recoloring a Packet in an MPLS VPN Network for the Uniform Model

The Uniform model needs extra configuration on the egress PE. The EXP bits of the top label of the received packet must be propagated to the IP precedence or DSCP bits. You can accomplish this by configuring qos-group on the egress PE.

Table 12-4 shows an overview of the three Tunneling models regarding the label operation for plain IP-over-MPLS, MPLS traffic engineering, and MPLS VPN. Consider these three cases:

IP-to-Label —The packet is received as an IP packet and forwarded labeled (ingress PE).

Label-to-Label —The packet is received labeled and forwarded labeled (P router).

Label-to-IP —The packet is received labeled and forwarded as an IP packet (egress PE).

Table 12-4 Overview of the Three Tunneling Models for Plain IP-over-MPLS, MPLS Traffic Engineering, and MPLS VPN

With plain IP-over-MPLS, MPLS traffic engineering, and MPLS VPN, the incoming packet is an IP packet. However, in the case of Carrier’s Carrier (CsC) and Inter-Autonomous MPLS VPN, the incoming packet on the ingress LSR is already labeled. Then both the Tunneled and the LSP DiffServ information are MPLS EXP bits, but in different labels in the label stack. Thus, it is possible to have hierarchical levels of MPLS DiffServ tunnels.

MQC Commands for MPLS QoS

Cisco IOS lets you change the EXP bits to a new value or implement the behavior of copying the EXP bits to the exposed IP precedence/DSCP bits on the egress LSR. In Cisco IOS, you can use the Modular QoS Command Line Interface (MQC) or Committed Access Rate (CAR) for this. However, MQC is the newest implemented feature and the one with the most capabilities, so it is the only one mentioned here.

You can use two commands in MQC to change the EXP bits of labels. The following command sets the EXP bits in the topmost label:

You can use it in an input or an output service policy.

The next command sets the EXP bits in the pushed label(s):

You can use it only in an input service policy.

The value for both commands is between 0 and 7.

To make the impact of these two commands easier to understand, Figures 12-13 , 12-14 , 12-15 , 12-16 , and 12-17 show you the result of these commands when you apply them to the input or output interface of a router. The LSP is left to right, so the input interface is the left interface and the output interface is the right interface. The examples demonstrate the impact of the commands in terms of imposition, swapping labels, or disposition of labels. Pay close attention to when the EXP bits of a certain label change.

Figure 12-13

Set MPLS Experimental Commands with Imposition

Remember MPLS QoS Rule 2 for the imposition case.

Figure 12-14

Set MPLS Experimental Commands When Swapping Labels

Remember MPLS QoS Rule 2 for the swap case.

Figure 12-15

Set MPLS Experimental Commands with Disposition

Remember MPLS QoS Rule 3 in the case of pop.

Figure 12-16 shows an interesting use of the set MPLS experimental commands. You can use the commands on the incoming and outgoing interface at the same time. The top illustration shows you that this gives you an interesting possibility—namely, to recolor the EXP bits of the two labels to a different value. The incoming EXP bits are changed to four by the MQC command on the swapped and pushed labels is on the input interface, and the EXP bits are changed to five only on the top label on the output interface. The bottom illustration in Figure 12-16 is not a very useful one, because you can change the EXP bits by one command on the input or output interface. You do not need to have both commands here, except to show what happens if you do configure both. Clearly, the command on the input or the output interface suffices.

Figure 12-16

Set MPLS Experimental Commands on Input and Output Interfaces

Figure 12-17 shows the commands in the case of IP-to-Label imposition.

Figure 12-17

Set MPLS Experimental Commands with IP-to-Label Imposition

Remember MPLS QoS Rule 1 for the IP-to-Label case.

Moving MPLS QoS from the PE to the CE Router

These DiffServ Tunneling models are popular for MPLS VPN networks. However, the PE routers have some work to do, including running BGP, labeling packets, running LDP, running routing protocols over the virtual routing/forwarding (VRF) interfaces to the customer CE routers, and so on. If the MPLS VPN network also does one of the DiffServ models, the PE must have some MQC configuration. To make matters worse, the DiffServ models are configurable per interface—hence, per customer connecting to the MPLS VPN network. This considerably increases the needed amount of QoS configuration on the PE. One solution is to move the MPLS QoS to the CE routers. That means at a minimum that the CE routers will be the first routers encapsulating the IP packets with labels. You can use CsC for this. However, this entails running LDP between the PE and CE router—when the PE-CE routing protocol is an IGP, which is not always wanted.

If the only thing you need on the CE routers is to have the EXP bits conveying the MPLS QoS from CE to PE, you can use the explicit NULL label. A new interface command was invented to do just that: mpls ip encapsulate explicit-null . You need to configure this command on the interface of the CE router toward the PE. It encapsulates all IP packets, leaving the interface with one explicit NULL label. The PE router receives the explicit NULL-labeled packet on the VRF interface and forwards the packet in the normal manner into the MPLS network to the remote PE router. However, the PE router must have mpls ip configured on that VRF interface; otherwise, the explicit NULL-labeled packets are dropped. The PE router automatically copies the EXP bits from the incoming explicit NULL label to the EXP bits of all outgoing labels (without changing the precedence/DSCP of the IP packet). If you want to use MQC to implement one of the three DiffServ models, you can configure it now on the CE router. Thus, the QoS configuration per customer on the PE router is no longer needed. This greatly increases the scalability of the design. However, you do need to run newer Cisco IOS software (minimum 12.2[13]T) on the PE router so that the PE can automatically copy the EXP bits from the incoming explicit NULL label to the outgoing labels. If this is not possible, you can use the qos-group feature.

Figure 12-18 shows an example of using the explicit NULL label on the CE router toward the PE.

Figure 12-18

Explicit NULL Label on CE Router

As already mentioned, you can also move the MPLS QoS from the PE to the CE by using CsC. This does involve using the signalling protocol LDP between the PE and the CE. An alternative to LDP is eBGP as the signalling protocol. External BGP is the preferred protocol anyway between different autonomous systems today. However, using the explicit NULL label between the PE and CE implies that LDP is not needed when the PE-CE routing protocol is an IGP.

Implementing the DiffServ Tunneling Models in Cisco IOS

This section gives an overview of implementing the different MPLS DiffServ Tunneling models in Cisco IOS. The sample network used here is an MPLS VPN network, because this is the MPLS application used most often today. The configuration shown pertains to only one or two values of the MPLS experimental bits or the IP precedence bits to keep the configuration small. In a real-world network, this configuration might need to be expanded to cover all EXP and precedence bits (DSCP levels).

Example 12-2 shows how to implement the MPLS DiffServ Uniform model in Cisco IOS and demonstrates the configuration needed on the ingress PE. Only precedence 4 is being matched. Precedence 4 is mapped to EXP bits value 4 by the policer, unless the bandwidth is exceeded, in which case the EXP bits are recolored to the value 2. The egress interface configuration is not needed for the MPLS DiffServ Uniform model, but it is added to show how to perform QoS on the EXP bits.

Example 12-2 Ingress PE: MPLS DiffServ Uniform Model

For the Uniform model, you must copy the precedence bits to the EXP bits on the ingress PE.

Example 12-3 shows the configuration of an intermediate P router.

Example 12-3 P Router: MPLS DiffServ Uniform Model

Example 12-4 shows the configuration of the PHP P router.

Example 12-4 PHP P Router: MPLS DiffServ Uniform Model

On the PHP router, qos-group ensures that the EXP bit values 2 and 4 are copied to the exposed outgoing top label after popping the incoming label.

Example 12-5 shows the configuration of the egress PE.

Example 12-5 Egress PE: MPLS DiffServ Uniform Model

On the egress PE, copy the EXP bits to the precedence bits by using qos-group.

The following configuration is an example of how to implement the MPLS DiffServ Pipe model in Cisco IOS. Only the egress PE is shown, because this LSR has a different configuration from the previous example. For the Pipe and Short Pipe DiffServ model, however, the ingress PE can change the EXP bits according to the policy of the service provider. In Example 12-6, the egress LSR does not copy the EXP bits to the precedence bits of the outgoing IP packet. The scheduling of the packets on the egress interface is still done indirectly on the EXP bits as qos-group is being used. Example 12-6 shows the configuration of the egress PE for the MPLS DiffServ Pipe model.

Example 12-6 Egress PE: MPLS DiffServ Pipe Model

The following configuration is an example of how to implement the MPLS DiffServ Short Pipe model in Cisco IOS. Only the egress PE is shown, because this LSR has a different configuration from the previous example. Namely, the egress LSR forwards the packet based on the precedence or DSCP bits of the IP packet after removing the labels. The egress LSR does not copy the EXP bits to the precedence bits of the outgoing IP packet.

Example 12-7 shows the configuration of the egress PE for the MPLS DiffServ Short Pipe model.

Example 12-7 Egress PE: MPLS DiffServ Short Pipe Model

Example 12-8 shows another configuration you can use for the egress PE in the Pipe model. In this configuration, the experimental bits 0 and 1 are mapped into qos-group 1, but with a different discard-class, discard-class 1 and 2, respectively. The different discard-class provides a different drop precedence. The experimental bits 2 and 3 are mapped to qos-group 2, with discard-class 1 and 2, respectively. On the egress interface, the packets from one qos-group go into one queue, but in that queue are packets that have two different drop precedence levels.

Example 12-8 Egress PE: MPLS DiffServ Pipe Model

The table-map feature.

The table-map is a conversion table between the different types of QoS that a packet can have. It allows you to map IP precedence, DSCP, MPLS EXP bits, qos-group, and Layer 2 cos information (the 802.1Q priority bits) via an MQC command. For example, you can map the IP precedence in the incoming IP packet to the EXP bits value of the outgoing labeled packet by using this table instead of specifying an MQC command for each value to be mapped. Table 12-5 shows the categories of QoS information that you can map and their values.

Table 12-5 Categories of QoS Information for Table-Map

Table 12-6 shows the To and From types that you can use in a table-map.

Table 12-6 To and From Packet-Marking Types

The commands in Example 12-9 show the set commands that you can use to apply a table-map. The first argument is the To type, and the second is the From type. You can also apply the set commands without a table-map. The command set mpls experimental topmost qos-group , for example, means that the qos-group packet-marking category is used to set the MPLS EXP value in the top label.

Example 12-9 set Commands to Apply a Table-Map

The global command to configure the table-map in Cisco IOS is table-map table-map-name map from from-value to to-value [default default-action-or-value]. The default keyword and default-action-or-value argument sets the default value (or action) to be used if a value is not explicitly designated.

Example 12-10 shows an example of a table-map. The qos-group is set via an input policy on the incoming interface according to the precedence value. The EXP bits are set on the outgoing topmost label—derived from the qos-group—via the table-map command that specifies that the values 0 and 3 are swapped and sets all other values to 7. So, for example, precedence 0 is copied to qos-group 0, and qos-group 0 is copied to MPLS EXP bits 3 through the table map-out .

Example 12-10Å@Example of a Table-Map

The use of mpls qos for ethernet over mpls.

So far in this chapter, the packet for which the QoS was set was an IP packet or a labeled packet. However, in the case of Ethernet over MPLS (EoMPLS), the forwarded packet is actually an Ethernet frame. If the frame is a non-VLAN Ethernet frame, it does not have QoS information embedded. If the frame is an 802.1Q frame, though, the Priority bits (P bits) in the 802.1Q header designate a QoS value. If a service provider carries the 802.1Q Ethernet frames over an MPLS network as in the case of point-to-point EoMPLS or VPLS, it would be nice if he could police the traffic and recolor it, if needed. You can do this in Cisco IOS. You can match the 802.1Q Priority bits in MQC by matching cos values in the class map. In Example 12-11, the EXP bits are set to 1 on the tunnel and VC label on the ingress PE, if the 802.1Q P bits are 1, 2, or 3.

Example 12-11 MPLS QoS for EoMPLS

As you can see, the service provider can use traffic shaping to limit the rate of transmitted data to an average rate or committed information rate (CIR). This is useful in the EoMPLS application where the service provider limits the amount of traffic that a customer can send over the Ethernet interface toward the MPLS network.

Today the usage of quality of service (QoS) has become widespread. Most networks use some kind of QoS at some routers. MPLS networks could not stay behind for long. Most MPLS networks already have QoS, or the network administrators have started to implement QoS. The propagation of QoS in MPLS networks is done through the usage of the experimental bits in the labels.

The Experimental (EXP) bits in the top label in the label stack determine the QoS of the packet and how it will be treated when a label switching router (LSR) forwards it. This chapter explained how the propagation of the QoS information works for labeled packets. It also explained what happens to the EXP bits value when a label is popped, swapped, or pushed. This chapter continued by describing how this QoS behavior by LSRs can be used to implement one of the three MPLS DiffServ Tunneling models in Cisco IOS.

You saw how to make your MPLS network more scalable by moving the MPLS QoS from the PE to the CE router. You also saw how to use MQC to change the MPLS QoS information on an LSR and how this affects the propagation of the MPLS QoS information on the LSRs that are downstream of this router.

Chapter Review Questions

How many bits in the IP header can be used for QoS?

How many AF classes exist?

Name the three MPLS DiffServ models.

What is the difference between the Pipe and Short Pipe models?

What is the interface command to encapsulate all IP packets with an explicit NULL label?

What is TOS reflection?

What feature is used in Cisco IOS to alter the EXP bits?

What is the problem with PHP and QoS?

What is the solution to the problem in question 8?

On which labels can you change the EXP bits value?

Copyright © 2007 Pearson Education. All rights reserved.

Related content

Network jobs watch: hiring, skills and certification trends, top network and data center events 2024, main line health readies networks for 'at home' hospitals, juniper offers ai pricing incentives, education programs, newsletter promo module test, show me more, google cloud run now allows ai inferencing on nvidia gpus.

3 takeaways from AMD’s ZT Systems grab

Highway 9 Networks launches partner program to boost private 5G

Has the hype around ‘Internet of Things’ paid off? | Ep. 145

Episode 1: Understanding Cisco’s Converged SDN Transport

Episode 2: Pluggable Optics and the Internet for the Future

How to see how many days passed since the beginning of the Linux epoch

How to use the pv command

How to use the stat command

This post will look at how QoS works in an MPLS environment. The default behaviour of MPLS QoS is shown. Next, I’ll explain and demontrate the three MPLS QoS DiffServ Models - Uniform, Pipe, and Short Pipe. As usual expect both configuration examples and wireshark captures. Do not expect fancy QoS policies as this post’s goal is to reveal the concepts of the technology rather than focus on QoS in itself. I will not discuss how policing, shaping, or queuing works, for example.

This topology is used throughout the post:

Eve-ng file if you want to follow along: EVE-NG - MPLS QoS - zartmann

Default QoS Behaviour in MPLS Networks

Without any policies anywhere, let’s try to send traffic from CE1 to CE2 with a marking of CS6. We can use telnet or SSH as IOS marks this traffic with CS6 by default.

To better see what is what in the wireshark captures, let’s have a look at the MAC addresses of CE1 and CE2:

The MAC addresses of the SP routers have this format:

So, it can easily be seen where the packet is sent from/to. The first octet after the OUI contains the router number and the last octet the interface identifier where Gi1 == 0 and Gi2 == 1.

Let’s SSH to CE2 from CE1:

Now, if we look at the markings of the SSH traffic as it leaves CE1, we do see the CS6 in the IP header:

And as the traffic is received on CE2:

So, with no policies anywhere customers keep their markings end-to-end.

What about the markings within the SP network? For the same traffic, if we look at the ingress PE (PE3) as traffic is sent into the MPLS core:

As this is a L3VPN we impose a label stack of two labels. One (topmost label) for transport to the egress PE (PE6) and the bottom (VPN label) for identifying the VRF, outgoing interface, and next hop for the destination. Both labels contain the EXP 6 value.

So, when we impose labels, the default behaviour is to copy the IP Precedence or three most significant (left most) bits of the DiffServ markings from IP into MPLS EXP in ALL imposed labels.

If we change the EXP value of the topmost label at imposition on PE3, what happens at the PHP router where we have implicit null (we pop the top label)? To demonstrate this a simple policy in PE3 is created:

Now, let’s SSH and look at the traffic on PE3 as it leaves Gi1 towards the core:

We see out policy working as the top label now has EXP 3 for the SSH traffic as it is sent to the core.

And on our PHP router, P5, what happens when traffic is sent to the egress PE (PE6) on Gi2? Let’s look:

The top label is removed and the bottom (VPN label) is left as is, meaning it carries the IP mapped value in the EXP field - EXP 6.

If we want to keep the changed EXP value when traffic is sent to the egress PE, we need to do a label swap and not a pop. To do this we can use the explicit null label instead of the implicit null. This is signaled via LDP by the egress PE (PE6):

Now when we SSH to CE2 from CE1, what happens at the PHP router, P5?

With the explicit null label we can carry on the markings in our top label.

Behaviours Learned

With the above scenarios we now know this about QoS for MPLS Networks:

• Customer’s markings are left untouched
• At label swap the top label keeps it’s changed value
• At PHP the EXP value is not copied down to the VPN label’s EXP value
• If explicit null is used then PHP router transfers top label EXP value to an exp-null label to keep markings when sending traffic to egress PE

Uniform Mode

This mode is typically for customers that have their own MPLS network. The essence of this mode is that on the egress PE we copy down the MPLS EXP value to the IP header before sending traffic to the CE. In other words, we reflect the MPLS core markings to the unlabeled IP packet. This gives us a uniform end-to-end QoS policy which is desired when you own the entire network.

With this model the egress PE’s policy is based on MPLS EXP values.

Let’s look at how this is done:

If we implement this policy show above, we should see CS3 marking in the IP header as the packet is sent from PE6 to CE2.

First P4 has a policer that marks down EXP 6 traffic that exceeds 8kbps to EXP 3. Our egress PE, PE6, does explicit-null to receive the changed EXP value of 3 from P5, our PHP router. Now, to be able to propagate the EXP value into the IP packet before it egresses towards the CE2 router, we need a placeholder. This is because PE6 will do its lookup on the received VPN label, expose all labels, and forward the unlabeled IP packet out Gi2 towards the CE. If we were to configure a policy that says to copy the EXP value to the IP header out Gi2, we’re not able to match on the EXP value as no labels exist now. So, an internal value or placeholder is created. This is what the QoS Group does. As traffic is received we match on EXP 3 and set QoS Group 3. As traffic leaves PE6, we match on the QoS Group 3 and set IP prec 3. The final result is this:

How we have a uniform policy where markings in the core gets copied down to the IP packet as it is sent towards the CE. With uniform mode we usually just copy the IP markings into the EXP value at label imposition thereby not changing anything at ingress to the SP network. Of course it is up to the administrator what is done with the markings.

Pipe mode is the next QoS model we’ll look at. Here the SP doesn’t touch the markings of the customer. Policy is based solely on the SP markings throughout the SP network. Even the policy on the edge towards the customer is based on the EXP bits like with uniform mode. With pipe mode we enforce policy ingress on the PE and set EXP value - typically on all imposed labels. The customer is told how to mark its traffic and this will then be mapped correctly into the classes offered by the SP.

The key point with pipe mode is that we configure the policy at egress of the SP network based on EXP values. This means that we must ensure that the marking set on ingress are transferred to the egress PE. Again, the exp-null label can be used.

The policy configuration:

Here we’re re-marking the customer’s CS6 value to EXP 3 at ingress on PE3. This should give us a label stack where all imposed labels will have EXP 3 set. At egress we still have exp-null configured, although this arguably could be the default imp-null depending on whether we change the top most label EXP value in the core of the SP network. If we do, we most likely will want to carry on this change to the egress PE for policy towards the customer. For demonstration purposes I’ve configured CBWFQ to guarantee 15% bandwidth for this class when traffic is sent to the customer on PE6. Notice that because we remove all labels the QoS Group is used as a place holder. Optionally we could also configure a discard class for congestion avoidance.

Let’s have a look at what actually happens in the packets. Starting with looking at what the packet’s EXP markings are when they leave the ingress PE, PE3:

Both labels have EXP 3 as we told the router to impose.

What about on the egress PE? Let’s have a look at the packet as it both enters PE6 and leaves PE6:

Here we have both the explicit null label and the VPN label. Both with EXP 3 as we set on the ingress PE. And when we send the packet towards CE2:

The cutomer’s marking is left intact, but the QoS policy at egress is based on our EXP marking.

The last flavour of QoS DiffServ models for MPLS Networks we’ll look at is another variant of the pipe model shown above. With short pipe, the SP configures the egress policy based on the customer’s marking, so the L3 markings in the IP header. Because of this, we no longer have a need to carry on the top label’s EXP markings towards the egress PE and we can safely disable explicit null and just use the default of implicit null, meaning that we have PHP enabled.

Notice in the above topology that now we only have a VPN label when sending the packets towards the egress PE. Also, the policy is based on the customer’s markings.

A somewhat more simple policy without QoS Group. Just to verify that imp-null is in effect, we can have a look at P5:

And if we look at the packets as they enter PE6, we should only see one label - the VPN label:

Just one label as expected. We can look at PE3 just to see if this was in fact the label imposed as the bottom label:

Sure enough, label 21 is the VPN label imposed by PE3.

Explicit Null

If no services are configured, but you just label switch IP packets in global, for example, you’ll need to configure exp-null on the egress PE, if you wan’t to be able to configure policies based on MPLS EXP at the egress. Otherwise a native IP packet will be received on the egress PE.

This concludes the QoS DiffServ models for MPLS Networks. We saw how the default behaviour of routers is and how the three models can be used to provide QoS policies in an SP environment. The Uniform model is usually based on the customers markings ingress and if markings are changed anywhere in the path we copy down these new values to the IP packet before sending it to the CE. The pipe model is based on the SP markings. Policy on the egress PE towards the customer is also based on the SP’s EXP marking. The customer’s markings are keep intact for pipe models - including short pipe. With short pipe the policy towards the customer is based on the customer’s markings. Here we can have implicit-null as we do not need EXP values on the egress PE for policy.

Please note that lots of documentation will show that the top label’s EXP value is copied down to the VPN label at PHP. This is by far the case. Nothing happens automatically execpt for the things we saw as default bahaviours. You can copy the value of the top most label down to the VPN label, but a policy will have to be configured on the PHP router for this to happen. And with explicit null configured on the egress PE, such policy wouldn’t make sense.

Explicit null is required for MPLS switched packets with just one label, as PHP would otherwise remove the only label, thereby only giving the egress PE the possiblity to do QoS on the markings in the IP header.

As a final comment regarding DiffServ QoS, all policies are based on an administrators configured PHB. Nothing is magically happening. So, the three models shown in this post are not implemented features of any platform, meaning it isn’t something you turn on and you get x model as a result. You must manually configure what happens at each hop. The three models are there to coarsely reference which policy you use in your network.

MPLS QoS Basics

The EXP (Experimental) bits in the MPLS header are used for QoS. The EXP field is 3 bits long, which is the same length as the IPP field. (The IPP field is deprecated but the first three bits of the DSCP value map directly to an IPP value).

When an ingress PE does label imposition, it automatically copies the IP Precedence value in the IP header to the MPLS header EXP value. This is true for both IOS-XE and IOS-XR.

QoS for MPLS is very similar to regular QoS on IP traffic, except you match on the MPLS EXP value instead of DSCP, IPP, CoS, etc.

You should also be aware of the QoS Group feature, which is used to map an EXP value to a QoS Group, which is an internal “tag” put on the packet. This is used on the egress PE in order to apply policy to traffic without needing to classify IP traffic.

The problem that QoS group solves, is that the MPLS label has been popped off already when preforming shaping on the egress interface of the egress PE, so you can’t match the EXP value any longer. The solution is to map the EXP value to a QoS Group on ingress, and then shape the traffic on egress based on the QoS Group. The QoS Group is basically an internal placeholder. It is not a literal marking on the packet itself, but instead an internal marking associated with the packet and held in memory on the router. In the lab below we’ll use the QoS Group feature to solve the problem of shaping on the egress interface on the egress PE.

We’ll use a regular L3VPN topology, with an extra C router at each site (C1 and C2). Here are the startup configs:

If you’ve setup the inital lab correctly, you should be able to telnet from C1 to C2.

The customer has purchased QoS service from the SP. The SLA gaurantees that voice traffic will have 5mb and low latency, while data traffic will have 20mb and no latency gaurantee. The SP tells the customer that the voice traffic must be marked with IPP 5 or DSCP 46 (EF) in order to receive this treatment.

For this lab, we’ll use icmp as a substitute for voice traffic, and telnet as a substitute for general data traffic.

On the C routers, we’ll create an input policy that simply lets us count the IP Precedence markings on received traffic. We’ll use this to validate the markings on received traffic.

From C1, ping C2 and telnet to C2. Then check the counters on the class maps on the policy-map applied to Gi1.

Telnet automatically uses IP Precedence 6. This is because telnet is considered as network traffic. Network traffic is given the highest preference, IPP 6 and 7. We’ll need to re-mark this on the CEs in order to substitute telnet as voice traffic in our lab.

On CE1 and CE2, create an input service policy which matches IPP 6 and re-marks it as IPP 5.

Telnet from C1 to C2 again, and this time you should see the IPP_5 counters climb.

If we take a pcap at any point in the SP network, we can see that the IP Precedence is automatically mapped to the EXP field in all MPLS labels. Both the transport and service label reflect the IP Precedence value.

We’ll now configure the SP QoS policy which will reserve bandwidth and minimize delay for voice traffic.

Initiate telnet traffic between the C routers again. If you check any core routers, you should see the VOICE class counters incrementing. (XRv does not appear to work - it tells me that the service policy is not installed. I believe this is just a limitation of the virtual image. You can apply the policy in the config but it doesn’t actually take effect.)

The problem right now is that we are not applying the policy to the egress interfaces on PE1 and PE2 when they act as the egress PE. The router cannot look up the MPLS EXP field in this case, because the MPLS labels are already gone. Instead of classifying the traffic on egress, we can use the qos-group to classify the traffic on ingress and map it to a qos-group. We can then use the qos-group in the policy that is applied to the egress interface facing the CE.

The commit fails for me on XRv, however we can verify that this policy is working on PE1. Initiate the telnet traffic again and check the counters on both the input policy on Gi2 and output policy on Gi1.

This was a simple lab exercise to get some familiarity with how QoS works in a service provider’s MPLS network. We see that we can only have a maximum of 8 different queues or classes in the MPLS network, as the EXP field is only 3 bits long. By default the IP Precedence value on an IP packet is mapped to the EXP field when MPLS labels are imposed on an IP packet.

We can also use the QoS-Group feature to mark received packets which will have their labels popped off by the time they egress the other interface. This prevents us from having to classify the IP traffic on egress.

As you can see, the QoS tools we use for MPLS on IOS-XE and IOS-XR are extremely similar to QoS in the enterprise world.

Last updated 1 year ago

• Network infrastructure

Enterprises and organizations have adopted SD-WAN as a cost-effective way to connect branch offices to their own data centers and to SaaS- and cloud-based applications. SD-WAN provides automation, centralization and flexibility, which creates a more agile WAN environment for midsize and large businesses. This comprehensive guide explores the benefits and challenges of SD-WAN, use cases, deployment strategies and how to buy the technology.

Multiprotocol label switching (mpls).

• Robert Sturt, Netify
• Linda Rosencrance
• Jessica Scarpati

What is Multiprotocol Label Switching (MPLS)?

Multiprotocol Label Switching (MPLS) is a switching mechanism used in wide area networks ( WANs ).

MPLS uses labels instead of network addresses to route traffic optimally via shorter pathways. MPLS is protocol-agnostic and can speed up and shape traffic flows across WANs and service provider networks. By optimizing traffic, MPLS reduces downtime and improves speed and quality of service (QoS).

History of MPLS

As the internet grew in popularity, organizations looked for an efficient way to perform packet forwarding. Bandwidth demands increased, but label-switching mechanisms struggled to handle the load. Traditional methods, such as IP switching and tag switching, require each router to independently determine a packet's next hop by inspecting its destination IP address before consulting its routing table . This slow process involves hardware resources and introduces the potential of degraded performance for real-time applications, such as voice and video. Traditional routers needed to scale more effectively to meet the bandwidth needs of the modern internet and avoid slow speeds, jitter and packet loss.

In 1997, the Internet Engineering Task Force (IETF) Multiprotocol Label Switching working group formed to create standards to help fix the issues around internet traffic routing. MPLS was developed as an alternative to multilayer switching and IP over asynchronous transfer mode (ATM). MPLS routers don't look up routes in routing tables, which helps boost the speed of network traffic. As MPLS techniques were developed and adopted throughout the early 2000s, the protocol became widely adopted.

MPLS can work in a multiprotocol environment, such as ATM, frame relay , Synchronous Optical Network and Ethernet. MPLS continues to evolve as backbone network technologies evolve, and the IETF working group still works on MPLS protocols and mechanisms. MPLS also played a significant role in the support of legacy network technologies, as well as newer technology based on IP networks.

This article is part of

What is SD-WAN (software-defined WAN)? Ultimate guide

• Which also includes:
• SD-WAN comparison chart: 10 vendors to assess
• The role of automation in SD-WAN
• 3 important SD-WAN security considerations and features

Components of MPLS

MPLS is defined by its use of labels instead of network addresses. This factor drives the flexibility and efficiency of MPLS.

A label is a four-byte -- 32-bit -- identifier that conveys the packet's predetermined forwarding path in an MPLS network. While a network address specifies an endpoint, a label specifies paths between endpoints. This latter capability enables MPLS to decide the optimal pathway route of a given packet. Labels can also contain information about QoS and a packet's priority level.

MPLS labels consist of the following four parts:

• Label value: 20 bits.
• Experimental: 3 bits.
• Bottom of stack: 1 bit.
• Time to live: 8 bits.

MPLS is multiprotocol, which means it can handle multiple network protocols. MPLS is highly versatile and unifying, as it provides mechanisms to carry a multitude of traffic, including Ethernet traffic. One of the key differentiators between MPLS and traditional routers is it doesn't need specialized or additional hardware.

Below is an overview of MPLS:

• It forwards using labels, as opposed to network addresses.
• The label contains the service class, as well as the destination, of the packet.
• It operates between Layers 2 and 3 of the Open Systems Interconnection ( OSI ) model.
• It guarantees the bandwidth of paths.
• ATM switches can act as routers, so no additional hardware is needed.

How an MPLS network works

In an MPLS network, packets are labeled by an ingress router -- a label edge router (LER) -- as they enter a service provider's network. The first router to receive a packet calculates the packet's entire path upfront. It also conveys a unique identifier to subsequent routers using a label in the packet header.

Every prefix in a routing table receives a unique identifier, and the MPLS service tells routers exactly where to look in the routing table for a specific prefix. This mechanism speeds up communication and traffic hopping.

MPLS works between the following OSI model layers:

• Layer 2. The data-link layer, or switching level, which uses protocols such as Ethernet.
• Layer 3. The routing layer, which covers traffic routing.

MPLS label traffic is sent via a label-switched path (LSP) inserted between the Layer 2 and Layer 3 headers. Label switch routers (LSRs) interpret the MPLS labels -- not the full IP address of any traffic. MPLS forwards data packets to Layer 2 of the OSI model, rather than passing to Layer 3. For this reason, MPLS is informally described as operating at Layer 2.5.

MPLS routing terminology

Label edge routers. LERs are the ingress or egress routers or nodes when an LSR is the first or last router in the path, respectively. LSRs label incoming data -- the ingress node -- or pop the label off the packet.

Label-switched paths. LSPs are the pathways through which packets are routed. An LSP enables service providers to decide the best way to flow certain types of traffic within a private or public network.

Label switch routers. LSRs read the labels and send labeled data on identified pathways. Intermediate LSRs are available if a packet data link needs to be corrected.

Pop. This mechanism removes a label and is usually performed by the egress router.

Push. This mechanism adds a label and is typically performed by the ingress router.

Swap. This mechanism replaces a label and is usually performed by LSRs between the ingress and egress routers.

Steps of an MPLS network traffic pathway

Here is an example of how a packet travels through an MPLS network:

• A packet enters the network through an LER.
• The packet is assigned to a forwarding equivalence class (FEC). The FEC assignment depends on the type of data and the destination. FECs are used to identify packets with similar or identical characteristics.
• The LER -- or ingress node -- applies a label to the packet and pushes it inside an LSP. The LER decides on which LSP the packet takes until it reaches its destination address.
• The packet moves through the network across LSRs.
• When an LSR receives a packet, it carries out the Push, Swap and Pop actions.
• In the final step, the LSR -- or egress router -- removes the labels and then forwards the original IP packet toward its destination.

Benefits of MPLS

Router hardware has improved significantly since the development of MPLS, but MPLS still offers important benefits.

QoS controls and reliability

Services need to be able to meet service-level agreements that cover traffic latency, jitter, packet loss and downtime. Service providers and enterprises use MPLS to implement QoS by defining LSPs that can meet the specific needs of a service. For example, a network might offer three service levels, each prioritizing different types of traffic -- e.g., one level for voice, one for time-sensitive traffic and one for best-effort traffic.

MPLS supports traffic separation and the creation of virtual private networks ( VPNs ), virtual private local area network services and virtual leased lines.

Agnostic protocol support

MPLS is not tied to any specific protocol or transport medium. MPLS supports transport over IP, Ethernet, ATM and frame relay. An LSP can be created using any protocol. Generalized MPLS extends MPLS, which manages time-division multiplexing, and other classes of switching technologies beyond packet switching.

Reduced latency and improved performance

MPLS is ideal for latency-sensitive applications, such as those handling videos, voice and mission-critical data. In addition, MPLS reduces latency by routing data more quickly using shorter path labels.

To optimize performance, different types of data can be preprogrammed with other priorities and classes of service. Organizations can assign different bandwidth percentages for various kinds of data to ensure optimal delivery and access.

Scalability

MPLS networks are scalable. Companies can provision and pay for only the bandwidth they need until their requirements change.

MPLS and security

If MPLS is correctly configured, the security is comprehensive. In addition, MPLS connections are over a private, dedicated network, which creates customer isolation and helps ensure privacy.

MPLS traffic isn't usually encrypted, but packets' labeling improves security through unique identifiers and isolation.

Organizations should use additional security measures to ensure MPLS networks are secured. Extra security best practices should include a defense-in-depth approach that uses measures such as denial-of-service prevention, firewalls to filter out malicious packets and authentication protocols to limit access. A best practice is to use a VPN tunnel between the provider edge routers and customer edge routers.

MPLS vs. SD-WAN

Many experts have debated the relevance of MPLS with the rise of software-defined WAN ( SD-WAN ) technology. SD-WAN enables organizations to use cheaper WAN connectivity options, such as broadband, sometimes replacing more expensive MPLS links.

SD-WAN offers several advantages over traditional MPLS networks.

No bandwidth penalties

SD-WAN does not have bandwidth penalties. Consequently, SD-WAN clients can easily upgrade by teams adding new links without making changes to the network or infrastructure.

Less costly

MPLS can be more expensive than SD-WAN. Many companies connect retail locations and branch offices to the central data centers via hub-and-spoke WAN models that depend on individual MPLS connections. Consequently, all data, workflows and transactions, including internet or cloud services access, must backhaul to the data center to be processed and redistributed.

SD-WAN cuts costs by offering optimized, multipoint connectivity through distributed, private data traffic exchange and control points. This gives users local and secure access to the services they need from the network or the cloud, while securing direct access to the internet and cloud resources.

Encrypted traffic

While MPLS networks are typically safe, MPLS does not use end-to-end encryption, making it vulnerable to cyber attacks. In addition, SD-WAN is a component of Secure Access Service Edge security , which offers significant benefits, including zero trust and endpoint protection.

But MPLS has some benefits over SD-WAN, including the following:

• Packet control. MPLS provides more granular control than SD-WAN, and packets always follow the defined path.
• Excellent isolation capabilities. This isolation enhanced privacy and security.

Hybrid MPLS and SD-WAN

Organizations can use a hybrid combination of SD-WAN and MPLS to provide a comprehensive WAN strategy.

SD-WAN enables real-time application traffic steering over any link, including MPLS. A hybrid SD-WAN-MPLS strategy uses a mix of traditional MPLS with internet connectivity from an SD-WAN.

Typical hybrid use cases employ a single MPLS line with an SD-WAN connection per site. Each instance is monitored for packet loss and jitter, and failover is automatically used if a line fails.

The future of MPLS

The future of networking is about reducing complexity, minimizing risk and optimizing spend. While many experts speculated about the demise of MPLS, saying SD-WAN will overtake it, MPLS has persisted, albeit at lower uptake levels. According to Market Growth Reports, the managed MPLS market is expected to grow until 2027 at a CAGR of 6.73%. One of the main reasons MPLS will see continued growth as a managed service is the guaranteed optimized performance of apps, such as voice over IP, through better QoS via a managed service provider (MSP).

SD-WAN is the proposed alternative to MPLS, as it offers some benefits above and beyond MPLS. SD-WAN security is enhanced using a framework of integrated security services. Gartner predicted that, by 2024, 80% of SD-WAN deployments will incorporate security service edge requirements. This security framework requires expertise and skills to implement and manage. For SMBs, this will most likely be achieved using an MSP.

In the next few years, most analysts expect that MPLS will continue to be a viable option, especially for connecting regional offices. However, the hybrid model of MPLS and SD-WAN is likely to see traction, especially as a managed service.

Continue Reading About Multiprotocol Label Switching (MPLS)

• 5 steps to migrate from MPLS to SD-WAN
• 12 common network protocols and their functions explained
• What is the difference between SD-WAN vs. MPLS?
• SD-WAN vs. VPN: How do they compare?

Related Terms

Dig deeper on network infrastructure.

quality of service (QoS)

Follow these 9 steps for SD-WAN testing before deployment

software-defined networking (SDN)

Cloud Application Acceleration

Microsoft 365 Copilot, an AI assistant, offers several promising features. Find out how to configure Copilot with Teams workflows...

With its AI capabilities, Microsoft Copilot provides several enhancements to Microsoft Teams functionality, including meeting ...

Organizations have ramped up their use of communications platform as a service and APIs to expand communication channels between ...

To keep corporate and user data safe, IT must continuously ensure mobile app security. Mobile application security audits are a ...

Dell continues to cut its workforce to become 'leaner,' as it repositions for changes in the enterprise PC market that are ...

Tap to Pay makes it possible to accept customer payments from an iPhone with no additional hardware. Find out the best use cases ...

AMD plans to acquire AI systems designer and manufacturer ZT Systems for $5 billion. AMD CEO Lisa Su said hyperscalers want more ...

Data center modernization offers a competitive advantage to organizations, along with maximizing hyperscale infrastructure. ...

Configuration files are vital for system deployment and management. Consider improving file management with proper planning, ...

Popular pricing models for managed service providers include monitoring only, per device, per user, all-you-can-eat or ...

Global IT consultancies take a multilayered approach to GenAI training by developing in-house programs, partnering with tech ...

IT service providers are upskilling a large portion of their workforces on the emerging technology. The campaign seeks to boost ...

MPLS and QoS DiffServ

We know from the 5-Day QoS bootcamp that Differentiated Services is one of the three major overall approaches to providing Quality of Service in an enterprise. The other options are Integrated Services and Best Effort.

When we studied Differentiated Services, we saw that the primary marking technology approach was the Differentiated Services Code Point (DSCP) concept. These are the high order 6 bits in the IP packet ToS Byte. But how can MPLS use these markings in order to provide QoS treatment (Per Hop Behaviors (PHBs)) to various traffic forms?

The first major issue to solve is the fact that Label Switch Routers (LSRs) rely solely on the MPLS header when making forwarding decisions. These devices will no longer analyze the IP Header information, thus negating the use of the ToS Byte. This was solved through the creation of the Experimental Bits field  in the MPLS header. The IETF has now renamed the field to the Traffic Class field.  See RFC 5462 .

But now there is another issue. There are 6 bits used for DSCP (providing 64 classifications), while there are only 3 Traffic Class bits (providing a mere 8 classifications).

It turns out there are two approaches to dealing with this issue. If you should happen to require less than 8 Per Hop Behaviours, just use the EXP Bits (Traffic Class). In fact, these bits are mapped to IP Precedence by default in Cisco's implementation, so they should be populated appropriately for QoS classification by default. This approach is called E-LSPs in official MPLS terminology. E stands for EXP-inferred in this case.

The second option is when we need more than 8 classifications in our network. Obviously, the three EXP bits fall far short of providing the necessary markings. In this case, the label itself is used to help mark traffic! In this approach, both the EXP bits and the label are used for the PHB. Typically the marking in the label will assign the congestion management treatment, while the EXP bits will control drop priority. This approach is called L-LSP . Here the L stands for label-inferred.

Thanks for reading this blog supplement to the QoS course, and you can expect many more over the coming months. Happy studies!

• Generative AI
• Office Suites
• Collaboration Software
• Productivity Software
• Augmented Reality
• Emerging Technology
• Remote Work
• Artificial Intelligence
• Operating Systems
• IT Leadership
• IT Management
• IT Operations
• Cloud Computing
• Computers and Peripherals
• Data Center
• Enterprise Applications
• Vendors and Providers
• Enterprise Buyer’s Guides
• United States
• Netherlands
• United Kingdom
• New Zealand
• Newsletters
• Foundry Careers
• Terms of Service
• Privacy Policy
• Cookie Policy
• Copyright Notice
• Member Preferences
• About AdChoices
• E-commerce Affiliate Relationships
• Your California Privacy Rights

Our Network

• Network World

MPLS QoS – Uniform Mode

http://ipexpert.ccieblog.com/ – In this post we look at an MPLS QoS mode often used when the SP manages the CE devices and therefore controls the QoS settings between them. Uniform mode is considered end-to-end because the EXP value is copied from the IP Precedence (IPP) value on ingress, and vice versa on egress. Any changes made to the EXP value may result in the IPP value being different when it exits the cloud than it was entering it.

CE2 is sending icmp echos with an IPP value of 5. PE2 copies this to the EXP value by default (ToS Reflection) so no configuration is necessary. P2 is policing EXP 5 packets, and when traffic exceeds 16k, they are marked down to EXP3. This can be done a couple of ways, but here it is done as follows:

class-map match-all EXP5

match mpls experimental topmost 5

policy-map POLICER

police 16000 conform-action transmit exceed-action set-mpls-exp-topmost-transmit 3

interface Serial1/1

description Connection to P1

service-policy output POLICER

Another way of doing this would be to match EXP 5 on inbound from P3, then set a qos group in the input policy. Then we could match the qos group and police as we do towards P1.

Next we need to use explicit null labels otherwise P1 pops off the label with the topmost EXP value when sending packets to PE1. This would cause packets that were labeled with EXP 3 to be seen as EXP 5 (PE2 sets EXP to 5 on both labels)…not good! This command is required on PE1 but can be used on all routers for completeness:

mpls ldp explicit-null

Finally, we have to copy the topmost EXP value as it enters PE1 to the IPP value as it transmitted toward CE1. This is done using qos groups. We will match the EXP value then set a qos group.

class-map match-all EXP3

match mpls experimental topmost 3

policy-map SETQ

set qos-group 5

set qos-group 3

interface Serial1/0

service-policy input SETQ

Next we match the qos group then set the IPP value accordingly:

class-map match-all GROUP5

match qos-group 5

class-map match-all GROUP3

match qos-group 3

policy-map SETP

class GROUP3

set ip precedence 3

class GROUP5

set ip precedence 5

description Connection to CE1

ip vrf forwarding VPNA

service-policy output SETP

On CE1, I have created this tracker that we can use to make sure values are getting set properly.

class-map match-all PREC5

match ip precedence 5

class-map match-all PREC3

match ip precedence 3

policy-map TRACKER

class PREC3

class PREC5

service-policy input TRACKER

Send enough pings from CE2 to generate more than 16k of traffic (pretty easy!) and verify on CE1:

CE2#ping 192.168.1.1 source lo 0 re 40 size 1400

Type escape sequence to abort.

Sending 40, 1400-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:

Packet sent with a source address of 192.168.2.1

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (40/40), round-trip min/avg/max = 44/59/112 ms

CE1#sho policy-map interface

Service-policy input: TRACKER

Class-map: PREC3 (match-all)

36 packets, 50544 bytes

30 second offered rate 0 bps

Match: ip precedence 3

Class-map: PREC5 (match-all)

4 packets, 5616 bytes

Match: ip precedence 5

Class-map: class-default (match-any)

0 packets, 0 bytes

30 second offered rate 0 bps, drop rate 0 bps

Doesn’t take much too get policed down in this network! MPLS QoS is a topic probably only seen on the SP Lab Exam, but nevertheless can provide hours of enjoyment for anyone.

Regards, Bryan (Post by Bryan Bartik)

Related content

Nerdio enables remote work across the canadian wilderness for the government of alberta, digital nomads just got huge screens and fast internet, mcdonald's serves up a master class in how not to explain a system outage, meta services begin recovering from major disruption, from our editors straight to your inbox, show me more, download our remote it support tools enterprise buyer’s guide.

Microsoft to release AI feature Recall in October for Windows Insiders

Generative AI is sliding into the ‘trough of disillusionment’

Podcast: End users need to switch their data security strategy

Podcast: Is the gold rush for AI talent slowing down?

Podcast: Google loses antitrust, and the world yawns

Why the AI money spigot is slowing down

Tech news roundup: The hackers are winning, it's time to switch security strategy

Is there still a gold rush for AI talent?

THE 10 CLOSEST Hotels to The Lenina Square, Novosibirsk

Hotels near the lenina square, property types, distance from, traveler rating, hotel class.

• Best Value Properties ranked using exclusive Tripadvisor data, including traveler ratings, confirmed availability from our partners, prices, booking popularity and location, as well as personal user preferences and recently viewed hotels.
• Traveler Ranked Highest rated hotels on Tripadvisor, based on traveler reviews.
• Distance from The Lenina Square See properties located closest to the place of interest first with confirmed availability for your dates from our partners.

1. Grand Autograph Hotel Novosibirsk

2. Domina Hotel

3. DoubleTree by Hilton Hotel Novosibirsk

4. azimut hotel novosibirsk, 5. cosmos novosibirsk hotel, 6. marins park hotel novosibirsk, 8. resident, 9. apartment in rc olimp and apartment with terrace, 10. hotel globus, 11. river park hotel, 12. hotel deluxe, 13. club puteshestvennikov, 14. avanta hotel-centre, 15. hotel metelitsa, 16. dynasty, 17. gorskiy city hotel, 18. aterrasuite hotel, 19. city hotel, 20. hotel chernyshevsky, 21. travellers' club, 22. ramada hotel & suites by wyndham novosibirsk zhukovka, 23. hotel imperator, 24. hotel severnaya, 25. tsentralnaya hotel, 26. vostok s hotel, 27. gostiny dvor, 28. garden apple hotel, 29. maxrooms global sky, 30. street adriena lejeune, hotels near the lenina square information.

37 Facts About Novosibirsk

Written by Adelice Lindemann

Modified & Updated: 25 Jun 2024

Reviewed by Sherman Smith

Novosibirsk, often referred to as the “Capital of Siberia,” is a vibrant and dynamic city located in southwestern Russia. With a population exceeding 1.5 million residents, it is the third most populous city in Russia and serves as the administrative center of the Novosibirsk Oblast.

Nestled along the banks of the Ob River, Novosibirsk is renowned for its rich cultural heritage, scientific advancements, and picturesque landscapes. As the largest city in Siberia, it offers a perfect blend of modern and traditional attractions, making it a fascinating destination for both locals and tourists.

In this article, we will delve into 37 interesting facts about Novosibirsk, shedding light on its history, architecture, natural wonders, and cultural significance. Whether you are planning a visit or simply curious about this intriguing city, these facts will give you a deeper understanding of what Novosibirsk has to offer.

Key Takeaways:

• Novosibirsk, the “Capital of Siberia,” is a vibrant city with a rich cultural scene, stunning natural landscapes, and a strong sense of community, offering a high quality of life for its residents.
• From being a major industrial and transportation hub to hosting world-class cultural institutions and scientific research centers, Novosibirsk is a dynamic city with a diverse culinary scene and a thriving IT and tech industry.

Novosibirsk is the third-largest city in Russia.

Situated in southwestern Siberia, Novosibirsk has a population of over 1.6 million people, making it one of the largest and most vibrant cities in the country.

The city was founded in 1893.

Novosibirsk was established as a railway junction on the Trans-Siberian Railway, playing a significant role in the development of Siberia.

It is known as the “Capital of Siberia”.

Due to its economic and cultural significance, Novosibirsk is often referred to as the capital of Siberia.

Novosibirsk is a major industrial center.

The city is home to a wide range of industries, including machinery manufacturing, chemical production, energy, and metallurgy .

It is famous for its scientific and research institutions.

Novosibirsk hosts several renowned scientific and research institutions, contributing to advancements in various fields including nuclear physics, chemistry, and biotechnology.

The Novosibirsk Opera and Ballet Theatre is one of the largest in Russia.

This iconic cultural institution showcases world-class ballet and opera performances and is a must-visit for art enthusiasts visiting the city .

The city has a vibrant theater scene.

Novosibirsk boasts numerous theaters, showcasing a wide variety of performances from traditional plays to experimental productions.

Novosibirsk is a major transportation hub.

Thanks to its strategic location on the Trans-Siberian Railway, the city serves as a crucial transportation hub connecting Siberia with other regions of Russia .

The Ob River flows through Novosibirsk.

The majestic Ob River adds to the city’s natural beauty and provides opportunities for recreational activities such as boating and fishing.

Novosibirsk is known for its harsh winter climate.

With temperatures dropping well below freezing in winter, the city experiences a true Siberian winter with snowy landscapes.

The Novosibirsk Zoo is one of the largest and oldest in Russia.

Home to a wide variety of animal species, including rare and endangered ones, the Novosibirsk Zoo attracts visitors from near and far.

Novosibirsk is a center for academic excellence.

The city is home to Novosibirsk State University, one of the top universities in Russia, renowned for its research and education programs.

The Novosibirsk Metro is the newest metro system in Russia.

Opened in 1985, the Novosibirsk Metro provides efficient transportation for residents and visitors alike.

Novosibirsk is surrounded by picturesque nature.

Surrounded by stunning landscapes, including the Altai Mountains and the Novosibirsk Reservoir, the city offers numerous opportunities for outdoor activities.

The Novosibirsk State Circus is famous for its performances.

Showcasing talented acrobats , clowns, and animal acts, the Novosibirsk State Circus offers entertaining shows for all ages.

Novosibirsk is home to a thriving art scene.

The city is dotted with art galleries, showcasing the works of local and international artists .

Novosibirsk has a diverse culinary scene.

From traditional Russian cuisine to international flavors, the city offers a wide range of dining options to satisfy all taste buds.

The Novosibirsk State Museum of Local History is a treasure trove of historical artifacts.

Exploring the museum gives visitors an insight into the rich history and culture of the region.

Novosibirsk is known for its vibrant nightlife.

The city is home to numerous bars, clubs, and entertainment venues, ensuring a lively atmosphere after dark.

Novosibirsk has a strong ice hockey tradition.

Ice hockey is a popular sport in the city, with local teams competing in national and international tournaments.

The Novosibirsk State Philharmonic Hall hosts world-class musical performances.

Music lovers can enjoy classical concerts and symphony orchestra performances in this renowned venue.

Novosibirsk is home to the Akademgorodok, a scientific research town.

Akademgorodok is a unique scientific community located near Novosibirsk, housing numerous research institutes and academic organizations.

Novosibirsk has a unique blend of architectural styles.

The city features a mix of Soviet-era buildings, modern skyscrapers, and historic structures, creating an eclectic cityscape.

Novosibirsk is an important center for ballet training and education.

The city’s ballet schools and academies attract aspiring dancers from across Russia and abroad.

Novosibirsk is a gateway to the stunning Altai Mountains.

Located nearby, the Altai Mountains offer breathtaking landscapes, hiking trails, and opportunities for outdoor adventures.

Novosibirsk hosts various cultural festivals throughout the year.

From music and theater festivals to art exhibitions, the city’s cultural calendar is always packed with exciting events.

Novosibirsk is a green city with numerous parks and gardens.

Residents and visitors can enjoy the beauty of nature in the city’s well-maintained parks and botanical gardens.

Novosibirsk is a center for technology and innovation.

The city is home to several technology parks and innovation centers, fostering the development of cutting-edge technologies.

Novosibirsk has a strong sense of community.

The residents of Novosibirsk are known for their hospitality and friendly nature, making visitors feel welcome.

Novosibirsk is a paradise for shopping enthusiasts.

The city is dotted with shopping malls, boutiques, and markets, offering a wide range of shopping options.

Novosibirsk has a rich literary heritage.

The city has been home to many famous Russian writers and poets, and their works are celebrated in literary circles.

Novosibirsk is a popular destination for medical tourism.

The city is known for its advanced medical facilities and expertise, attracting patients from around the world.

Novosibirsk has a well-developed public transportation system.

With buses, trams, trolleybuses, and the metro, getting around the city is convenient and efficient.

Novosibirsk is a city of sport.

The city has a strong sports culture, with numerous sports facilities and opportunities for athletic activities .

Novosibirsk has a thriving IT and tech industry.

The city is home to numerous IT companies and startups, contributing to the development of the digital economy.

Novosibirsk celebrates its anniversary every year on July 12th.

The city comes alive with festivities, including concerts, fireworks, and cultural events, to commemorate its foundation.

Novosibirsk offers a high quality of life.

With its excellent educational and healthcare systems, cultural amenities, and vibrant community, Novosibirsk provides a great living environment for its residents.

Novosibirsk is a fascinating city filled with rich history, stunning architecture, and a vibrant cultural scene. From its origins as a small village to becoming the third-largest city in Russia, Novosibirsk has emerged as a major economic and cultural hub in Siberia . With its world-class universities, theaters, museums, and natural attractions, Novosibirsk offers a myriad of experiences for visitors.

Whether you’re exploring the impressive Novosibirsk Opera and Ballet Theater, strolling along the picturesque banks of the Ob River, or immersing yourself in the city’s scientific and technological achievements at the Akademgorodok, Novosibirsk has something for everyone.

From its iconic landmarks such as the Alexander Nevsky Cathedral to its vibrant festivals like the International Jazz Festival , Novosibirsk has a unique charm that will captivate any traveler. So, make sure to include Novosibirsk in your travel itinerary and discover the hidden gems of this remarkable city.

Q: What is the population of Novosibirsk?

A: As of 2021, the estimated population of Novosibirsk is around 1.6 million people.

Q: Is Novosibirsk a safe city to visit?

A: Novosibirsk is generally considered a safe city for tourists. However, it is always recommended to take standard precautions such as avoiding unfamiliar areas at night and keeping your belongings secure.

Q: What is the best time to visit Novosibirsk?

A: The best time to visit Novosibirsk is during the summer months of June to September when the weather is pleasant and suitable for outdoor activities. However, if you enjoy the winter chill and snow, visiting during the winter season can also be a unique experience.

Q: Are there any interesting cultural events in Novosibirsk?

A: Yes, Novosibirsk is known for its vibrant cultural scene. The city hosts various festivals throughout the year, including the International Jazz Festival, Novosibirsk International Film Festival, and the Siberian Ice March Festival.

Q: Can I visit Novosibirsk without knowing Russian?

A: While knowing some basic Russian phrases can be helpful, many establishments in Novosibirsk, especially tourist areas, have English signage and staff who can communicate in English. However, learning a few essential Russian phrases can enhance your travel experience.

Novosibirsk's captivating history and vibrant culture make it a must-visit destination for any traveler. From its humble beginnings as a small settlement to its current status as Russia's third-largest city, Novosibirsk has a story worth exploring. If you're a sports enthusiast, don't miss the opportunity to learn more about the city's beloved football club , FC Sibir Novosibirsk. With its rich heritage and passionate fan base, the club has become an integral part of Novosibirsk's identity.

Was this page helpful?

Our commitment to delivering trustworthy and engaging content is at the heart of what we do. Each fact on our site is contributed by real users like you, bringing a wealth of diverse insights and information. To ensure the highest standards of accuracy and reliability, our dedicated editors meticulously review each submission. This process guarantees that the facts we share are not only fascinating but also credible. Trust in our commitment to quality and authenticity as you explore and learn with us.

Share this Fact:

• Visit Our Blog about Russia to know more about Russian sights, history
• Check out our Russian cities and regions guides
• Follow us on Twitter and Facebook to better understand Russia
• Info about getting Russian visa , the main airports , how to rent an apartment
• Our Expert answers your questions about Russia, some tips about sending flowers

Russian regions

• Altay republic
• Irkutsk oblast
• Kemerovo oblast
• Khakassia republic
• Krasnoyarsk krai
• Novosibirsk oblast
• Omsk oblast
• Tomsk oblast
• Tuva republic
• Map of Russia
• All cities and regions
• Blog about Russia
• News from Russia
• How to get a visa
• Flights to Russia
• Russian hotels
• Renting apartments
• Russian currency
• FIFA World Cup 2018
• Submit an article
• Flowers to Russia
• Ask our Expert

Novosibirsk Oblast, Russia

The capital city of Novosibirsk oblast: Novosibirsk .

Novosibirsk Oblast - Overview

Novosibirsk Oblast is a federal subject of Russia, part of the Siberian Federal District. Novosibirsk is the capital city of the region.

The population of Novosibirsk Oblast is about 2,780,000 (2022), the area - 177,756 sq. km.

Novosibirsk oblast flag

Novosibirsk oblast coat of arms.

Novosibirsk oblast map, Russia

Novosibirsk oblast latest news and posts from our blog:.

29 November, 2020 / Novosibirsk Akademgorodok - the scientific center of Siberia .

25 December, 2018 / Chuya Highway - the Most Picturesque Road in Russia .

18 September, 2018 / Novosibirsk - the view from above .

10 December, 2014 / The night views of Novosibirsk .

17 July, 2014 / Novosibirsk hit by a heavy hailstorm .

More posts..

History of Novosibirsk Oblast

Over thousands of years, the territory of the Novosibirsk region, due to its location on the border of natural zones and cultural regions (the Siberian taiga and the Eurasian steppe), played the role of a buffer zone or border zone of different peoples.

In the 13th-15th centuries, this land was the eastern outskirts of the Golden Horde. Later, until the end of the 16th century, it was part of the Siberian Khanate. In the 18th century, the territory of the present Novosibirsk region became part of the Russian Empire.

Despite the relatively favorable climate, the Russians began to settle here relatively late. The Barabin Tatars were the indigenous people. Today, their total population is about 10,000 people living mainly in the western parts of the region.

The Barabin Tatars were subjected to constant attacks of the Kalmyks (the Oyrates and Teleuts). Russian villages were also under the threat. That’s why people preferred to settle in the north, near Tomsk. Only at the end of the 17th century, Novosibirsk province became attractive to settlers.

More Historical Facts…

The first settlement was founded by the boyar son Alexey Kruglik in 1695. Later, this settlement became the village of Kruglikovo. Today, it is located in Bolotninsky district. In the early 18th century, Berdsky stockaded town was built. Over time, the threat from the nomads decreased and the number of settlers increased.

In 1722, the Siberian line of fortresses along the Irtysh River was constructed. The locals were mainly engaged in soil tilling, fishing and hunting. In the early 19th century, the famous Ural manufacturer Akinfiy Demidov constructed two copper melting plants here - Kolyvansky and Barnaulsky.

In 1893, due to the construction of the Trans-Siberian Railway and the railway bridge across the Ob River, Alexandrovsky settlement was built (from 1895 - Novonikolayevsky). Thanks to its convenient geographical location (the Trans-Siberian Railway crossing the Ob River, transportation ways connecting Siberia with the European part of the Russian Empire), its trade importance grew rapidly. In 1909, Novonikolayevsk became a town. In 1925, it was renamed in Novosibirsk.

Before 1921, the territory of Novosibirsk oblast was part of Tomsk gubernia, from 1921 to 1925 - of Novonikolayevsk gubernia, from 1925 to 1930 - of Siberian krai, from 1930 to 1937 - of West Siberian krai. September 28, 1937, West Siberian krai was divided into Novosibirsk oblast and Altay krai. This date is considered the official date of the region formation.

Novosibirsk Oblast - Features

Novosibirsk Oblast is located in the south east of the East-Siberian Plain, in the steppe, forest-steppe and taiga zones, between the Ob and the Irtysh rivers. The length of the region from west to east - 642 km, from north to south - 444 km.

The southern part of Vasyugan swamp, the largest swamp in the world, occupies the territory in the north and north-west of the province. In the southwest, it borders with Pavlodar oblast of Kazakhstan.

There are about 3,000 lakes on the territory of the Novosibirsk region. The largest lakes are Chany, Ubinskoye, Sartlan. Novosibirsk Reservoir also known as “the Ob Sea” (1,082 sq. km.) was created for Novosibirsk Hydroelectric Power Plant.

The climate is continental. The average temperature in January ranges from minus 16 degrees Celsius in the south and minus 20 degrees Celsius in the north. The average temperature in July - plus 18-20 degrees Celsius.

The largest cities and towns are Novosibirsk (1,621,000), Berdsk (103,500), Iskitim (54,700), Kuybishev (43,000). Novosibirsk is one the largest industrial, transport, scientific, and cultural center of Russia, the third most populous city in the country after Moscow and St. Petersburg. It is also the capital of the Siberian Federal District.

In the historical part of Novosibirsk you can find a lot of preserved monuments of the Russian Empire times. The Soviet era is presented by numerous scientific and cultural attractions, as well as beautiful parks.

There are more than 500 deposits of various mineral resources in Novosibirsk Oblast (coal, refractory clay, peat, anthracite). Natural gas and oil fields are located in the north-western part of the region. There are significant reserves of underground thermal and mineral waters. Forests cover about 4 million hectares, more than 20% of the territory.

Novosibirsk Oblast is one of the most industrially developed regions in Siberia (metal processing and machine building, food, power engineering, non-ferrous metallurgy industries). Heavy industries are concentrated in Novosibirsk, Iskitim and Berdsk.

The regional agriculture specializes in the cultivation of grain, potatoes and vegetables. Dairy cattle breeding, poultry farming and beekeeping are developed. The production of flax plays an important role too. Agricultural development of the territory is not high (about 48%). In general, it has about 25% of all agricultural land in Western Siberia.

Novosibirsk oblast of Russia photos

Nature of novosibirsk oblast.

Novosibirsk Oblast nature

Author: Klemeshev

Novosibirsk Oblast scenery

Author: Mikhantiev Zhenya

Sunflower field in Novosibirsk Oblast

Author: Sergey Savchak

Pictures of the Novosibirsk region

Steppe landscape in Novosibirsk Oblast

Author: Alex Strekhletov

Orthodox church in the Novosibirsk region

Author: Sergey Bulanov

• Currently 3.07/5

Rating: 3.1 /5 (174 votes cast)

• Skip to content
• Skip to search
• Skip to footer

Command Reference, Cisco IOS XE 17.15.x (Catalyst 9400 Switches)

Bias-free language.

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

• Using the Command-Line Interface
• Cisco SD-Access Commands
• Cisco TrustSec Commands
• High Availability Commands
• Interface and Hardware Commands
• IP Addressing Services Commands
• IP Multicast Routing Commands
• Layer 2/3 Commands
• MPLS Commands
• Network Management Commands

QoS Commands

• IP Routing Commands
• System Management Commands
• Tracing Commands
• VLAN Commands

Chapter: QoS Commands

Auto qos classify, auto qos trust, auto qos video, auto qos voip.

debug auto qos

match (class-map configuration)

Qos queue-softmax-multiplier, queue-buffers ratio, queue-limit, random-detect cos.

random-detect cos-based

random-detect dscp

random-detect dscp-based

random-detect precedence

random-detect precedence-based

service-policy (Wired)

Show auto qos, show class-map, show platform hardware fed active qos, show platform software fed active qos, show policy-map, show tech-support qos, trust device.

To automatically configure quality of service (QoS) classification for untrusted devices within a QoS domain, use the auto qos classify command in interface configuration mode. To return to the default setting, use the no form of this command.

auto qos classify [ police ]

no auto qos classify [ police ]

Syntax Description

Command Default

Auto-QoS classify is disabled on the port.

Command Modes

Interface configuration

Command History

Usage Guidelines

Use this command to configure the QoS for trusted interfaces within the QoS domain. The QoS domain includes the device, the network interior, and edge devices that can classify incoming traffic for QoS.

When auto-QoS is enabled, it uses the ingress packet label to categorize traffic, to assign packet labels, and to configure the ingress and egress queues.

Auto-QoS configures the device for connectivity with a trusted interface. The QoS labels of incoming packets are trusted. For nonrouted ports, the CoS value of the incoming packets is trusted. For routed ports, the DSCP value of the incoming packet is trusted.

To take advantage of the auto-QoS defaults, you should enable auto-QoS before you configure other QoS commands. You can fine-tune the auto-QoS configuration after you enable auto-QoS.

After auto-QoS is enabled, do not modify a policy map or aggregate policer that includes AutoQoS in its name. If you need to modify the policy map or aggregate policer, make a copy of it, and change the copied policy map or policer. To use the new policy map instead of the generated one, remove the generated policy map from the interface, and apply the new policy map.

To display the QoS configuration that is automatically generated when auto-QoS is enabled, enable debugging before you enable auto-QoS. Use the debug auto qos privileged EXEC command to enable auto-QoS debugging.

The following policy maps and class maps are created and applied when running the auto qos classify and auto qos classify police commands:

AutoQos-4.0-Classify-Police-Input-Policy

AutoQos-4.0-Output-Policy

AutoQos-4.0-Multimedia-Conf-Class (match-any)

AutoQos-4.0-Bulk-Data-Class (match-any)

AutoQos-4.0-Transaction-Class (match-any)

AutoQos-4.0-Scavanger-Class (match-any)

AutoQos-4.0-Signaling-Class (match-any)

AutoQos-4.0-Default-Class (match-any)

class-default (match-any)

AutoQos-4.0-Output-Priority-Queue (match-any)

AutoQos-4.0-Output-Control-Mgmt-Queue (match-any)

AutoQos-4.0-Output-Multimedia-Conf-Queue (match-any)

AutoQos-4.0-Output-Trans-Data-Queue (match-any)

AutoQos-4.0-Output-Bulk-Data-Queue (match-any)

AutoQos-4.0-Output-Scavenger-Queue (match-any)

AutoQos-4.0-Output-Multimedia-Strm-Queue (match-any)

To disable auto-QoS on a port, use the no auto qos classify interface configuration command. Only the auto-QoS-generated interface configuration commands for this port are removed. If this is the last port on which auto-QoS is enabled and you enter the no auto qos classify command, auto-QoS is considered disabled even though the auto-QoS-generated global configuration commands remain (to avoid disrupting traffic on other ports affected by the global configuration).

This example shows how to enable auto-QoS classification of an untrusted device and police traffic:

You can verify your settings by entering the show auto qos interface interface-id privileged EXEC command.

To automatically configure quality of service (QoS) for trusted interfaces within a QoS domain, use the auto qos trust command in interface configuration mode. To return to the default setting, use the no form of this command.

auto qos trust { cos | dscp }

no auto qos trust { cos | dscp }

Auto-QoS trust is disabled on the port.

Use this command to configure the QoS for trusted interfaces within the QoS domain. The QoS domain includes the device, the network interior, and edge devices that can classify incoming traffic for QoS. When auto-QoS is enabled, it uses the ingress packet label to categorize traffic, to assign packet labels, and to configure the ingress and egress queues.

The following policy maps and class maps are created and applied when running the auto qos trust cos command.

Policy maps:

AutoQos-4.0-Trust-Cos-Input-Policy

Class maps:

The following policy maps and class maps are created and applied when running the auto qos trust dscp command:

AutoQos-4.0-Trust-Dscp-Input-Policy

To disable auto-QoS on a port, use the no auto qos trust interface configuration command. Only the auto-QoS-generated interface configuration commands for this port are removed. If this is the last port on which auto-QoS is enabled and you enter the no auto qos trust command, auto-QoS is considered disabled even though the auto-QoS-generated global configuration commands remain (to avoid disrupting traffic on other ports affected by the global configuration).

This example shows how to enable auto-QoS for a trusted interface with specific CoS classification.

This example shows how to enable auto-QoS for a trusted interface with specific DSCP classification.

To automatically configure quality of service (QoS) for video within a QoS domain, use the auto qos video command in interface configuration mode. Use the no form of this command to return to the default setting.

auto qos video { cts | ip-camera | media-player }

no auto qos video { cts | ip-camera | media-player }

Auto-QoS video is disabled on the port.

Use this command to configure the QoS appropriate for video traffic within the QoS domain. The QoS domain includes the device, the network interior, and edge devices that can classify incoming traffic for QoS. When auto-QoS is enabled, it uses the ingress packet label to categorize traffic, to assign packet labels, and to configure the ingress and egress queues. For more information, see the queue tables at the end of this section.

Auto-QoS configures the device for video connectivity to a Cisco TelePresence system, a Cisco IP camera, or a Cisco digital media player.

The device applies the auto-QoS-generated commands as if the commands were entered from the command-line interface (CLI). An existing user configuration can cause the application of the generated commands to fail or to be overridden by the generated commands. These actions occur without warning. If all the generated commands are successfully applied, any user-entered configuration that was not overridden remains in the running configuration. Any user-entered configuration that was overridden can be retrieved by reloading the device without saving the current configuration to memory. If the generated commands fail to be applied, the previous running configuration is restored.

If this is the first port on which you have enabled auto-QoS, the auto-QoS-generated global configuration commands are executed followed by the interface configuration commands. If you enable auto-QoS on another port, only the auto-QoS-generated interface configuration commands for that port are executed.

The following policy maps and class maps are created and applied when running the auto qos video cts command:

The following policy maps and class maps are created and applied when running the auto qos video ip-camera command:

The following policy maps and class maps are created and applied when running the auto qos video media-player command:

To disable auto-QoS on a port, use the no auto qos video interface configuration command. Only the auto-QoS-generated interface configuration commands for this port are removed. If this is the last port on which auto-QoS is enabled, and you enter the no auto qos video command, auto-QoS is considered disabled even though the auto-QoS-generated global configuration commands remain (to avoid disrupting traffic on other ports affected by the global configuration).

The following is an example of the auto qos video cts command and the applied policies and class maps:

The following is an example of the auto qos video ip-camera command and the applied policies and class maps:

The following is an example of the auto qos video media-player command and the applied policies and class maps.

You can verify your settings by entering the show auto qos video interface interface-id privileged EXEC command.

To automatically configure quality of service (QoS) for voice over IP (VoIP) within a QoS domain, use the auto qos voip command in interface configuration mode. Use the no form of this command to return to the default setting.

auto qos voip { cisco-phone | cisco-softphone | trust }

no auto qos voip { cisco-phone | cisco-softphone | trust }

Auto-QoS is disabled on the port.

Use this command to configure the QoS appropriate for VoIP traffic within the QoS domain. The QoS domain includes the device, the network interior, and edge devices that can classify incoming traffic for QoS.

Auto-QoS configures the device for VoIP with Cisco IP phones on device and routed ports and for devices running the Cisco SoftPhone application. These releases support only Cisco IP SoftPhone Version 1.3(3) or later. Connected devices must use Cisco Call Manager Version 4 or later.

When you enter the auto qos voip cisco-phone interface configuration command on a port at the edge of the network that is connected to a Cisco IP phone, the device enables the trusted boundary feature. The device uses the Cisco Discovery Protocol (CDP) to detect the presence of a Cisco IP phone. When a Cisco IP phone is detected, the ingress classification on the port is set to trust the QoS label received in the packet. The device also uses policing to determine whether a packet is in or out of profile and to specify the action on the packet. If the packet does not have a DSCP value of 24, 26, or 46 or is out of profile, the device changes the DSCP value to 0. When a Cisco IP phone is absent, the ingress classification is set to not trust the QoS label in the packet. The policing is applied to those traffic matching the policy-map classification before the device enables the trust boundary feature.

• When you enter the auto qos voip cisco-softphone interface configuration command on a port at the edge of the network that is connected to a device running the Cisco SoftPhone, the device uses policing to decide whether a packet is in or out of profile and to specify the action on the packet. If the packet does not have a DSCP value of 24, 26, or 46 or is out of profile, the device changes the DSCP value to 0.
• When you enter the auto qos voip trust interface configuration command on a port connected to the network interior, the device trusts the CoS value for nonrouted ports or the DSCP value for routed ports in ingress packets (the assumption is that traffic has already been classified by other edge devices).

You can enable auto-QoS on static, dynamic-access, and voice VLAN access, and trunk ports. When enabling auto-QoS with a Cisco IP phone on a routed port, you must assign a static IP address to the IP phone.

The following policy maps and class maps are created and applied when running the auto qos voip trust command:

The following policy maps and class maps are created and applied when running the auto qos voip cisco-softphone command:

AutoQos-4.0-CiscoSoftPhone-Input-Policy

AutoQos-4.0-Voip-Data-Class (match-any)

AutoQos-4.0-Voip-Signal-Class (match-any)

The following policy maps and class maps are created and applied when running the auto qos voip cisco-phone command:

service-policy input AutoQos-4.0-CiscoPhone-Input-Policy

service-policy output AutoQos-4.0-Output-Policy

class AutoQos-4.0-Voip-Data-CiscoPhone-Class

class AutoQos-4.0-Voip-Signal-CiscoPhone-Class

class AutoQos-4.0-Default-Class

To disable auto-QoS on a port, use the no auto qos voip interface configuration command. Only the auto-QoS-generated interface configuration commands for this port are removed. If this is the last port on which auto-QoS is enabled and you enter the no auto qos voip command, auto-QoS is considered disabled even though the auto-QoS-generated global configuration commands remain (to avoid disrupting traffic on other ports affected by the global configuration).

The device configures egress queues on the port according to the settings in this table.

The following is an example of the auto qos voip trust command and the applied policies and class maps:

The following is an example of the auto qos voip cisco-phone command and the applied policies and class maps:

The following is an example of the auto qos voip cisco-softphone command and the applied policies and class maps:

To define a traffic classification match criteria for the specified class-map name, use the class command in policy-map configuration mode. Use the no form of this command to delete an existing class map.

class { class-map-name | class-default }

no class { class-map-name | class-default }

No policy map class-maps are defined.

Policy-map configuration

Before using the class command, you must use the policy-map global configuration command to identify the policy map and enter policy-map configuration mode. After specifying a policy map, you can configure a policy for new classes or modify a policy for any existing classes in that policy map. You attach the policy map to a port by using the service-policy interface configuration command.

After entering the class command, you enter the policy-map class configuration mode. These configuration commands are available:

admit —Admits a request for Call Admission Control (CAC)

bandwidth —Specifies the bandwidth allocated to the class.

exit —Exits the policy-map class configuration mode and returns to policy-map configuration mode.

no —Returns a command to its default setting.

police —Defines a policer or aggregate policer for the classified traffic. The policer specifies the bandwidth limitations and the action to take when the limits are exceeded. For more information about this command, see Cisco IOS Quality of Service Solutions Command Reference available on Cisco.com.

priority —Assigns scheduling priority to a class of traffic belonging to a policy map.

queue-buffers —Configures the queue buffer for the class.

queue-limit —Specifies the maximum number of packets the queue can hold for a class policy configured in a policy map.

service-policy —Configures a QoS service policy.

set —Specifies a value to be assigned to the classified traffic. For more information, see the set command.

shape —Specifies average or peak rate traffic shaping. For more information about this command, see Cisco IOS Quality of Service Solutions Command Reference available on Cisco.com.

To return to policy-map configuration mode, use the exit command. To return to privileged EXEC mode, use the end command.

The class command performs the same function as the class-map global configuration command. Use the class command when a new classification, which is not shared with any other ports, is needed. Use the class-map command when the map is shared among many ports.

You can configure a default class by using the class class-default policy-map configuration command. Unclassified traffic (traffic that does not meet the match criteria specified in the traffic classes) is treated as default traffic.

You can verify your settings by entering the show policy-map privileged EXEC command.

This example shows how to create a policy map called policy1. When attached to the ingress direction, it matches all the incoming traffic defined in class1 and polices the traffic at an average rate of 1 Mb/s and bursts at 1000 bytes, marking down exceeding traffic via a table-map.

This example shows how to configure a default traffic class to a policy map. It also shows how the default traffic class is automatically placed at the end of policy-map pm3 even though class-default was configured first:

To create a class map to be used for matching packets to the class whose name you specify and to enter class-map configuration mode, use the class-map command in global configuration mode. Use the no form of this command to delete an existing class map and to return to global or policy map configuration mode.

class-map class-map name { match-any | match-all }

no class-map class-map name { match-any | match-all }

No class maps are defined.

Global configuration

Policy map configuration

Use this command to specify the name of the class for which you want to create or modify class-map match criteria and to enter class-map configuration mode.

The class-map command and its subcommands are used to define packet classification, marking, and aggregate policing as part of a globally named service policy applied on a per-port basis.

After you are in quality of service (QoS) class-map configuration mode, these configuration commands are available:

description —Describes the class map (up to 200 characters). The show class-map privileged EXEC command displays the description and the name of the class map.

exit —Exits from QoS class-map configuration mode.

match —Configures classification criteria.

no —Removes a match statement from a class map.

If you enter the match-any keyword, you can only use it to specify an extended named access control list (ACL) with the match access-group class-map configuration command.

To define packet classification on a physical-port basis, only one match command per class map is supported.

The ACL can have multiple access control entries (ACEs).

This example shows how to configure the class map called class1 with one match criterion, which is an access list called 103:

This example shows how to delete the class map class1:

You can verify your settings by entering the show class-map privileged EXEC command.

To enable debugging of the automatic quality of service (auto-QoS) feature, use the debug auto qos command in privileged EXEC mode. Use the no form of this command to disable debugging.

no debug auto qos

This command has no arguments or keywords.

Auto-QoS debugging is disabled.

Privileged EXEC

To display the QoS configuration that is automatically generated when auto-QoS is enabled, enable debugging before you enable auto-QoS. You enable debugging by entering the debug auto qos privileged EXEC command.

The undebug auto qos command is the same as the no debug auto qos command.

When you enable debugging on a device stack, it is enabled only on the active device. To enable debugging on a stack member, you can start a session from the active device by using the session switch-number privileged EXEC command. Then enter the debug command at the command-line prompt of the stack member. You also can use the remote command stack-member-number LINE privileged EXEC command on the active device to enable debugging on a member device without first starting a session.

This example shows how to display the QoS configuration that is automatically generated when auto-QoS is enabled:

To define the match criteria to classify traffic, use the match command in class-map configuration mode. Use the no form of this command to remove the match criteria.

match { access-group { name acl-name | acl-index } | cos cos-value | dscp dscp-value | [ ip ] dscp dscp-list | [ ip ] precedence ip-precedence-list | mpls experimental-value | non-client-nrt | precedence precedence-value1...value4 | protocol protocol-name | qos-group qos-group-value | vlan vlan-id | wlan wlan-id }

no match { access-group { name acl-name | acl-index } | cos cos-value | dscp dscp-value | [ ip ] dscp dscp-list | [ ip ] precedence ip-precedence-list | mpls experimental-value | non-client-nrt | precedence precedence-value1...value4 | protocol protocol-name | qos-group qos-group-value | vlan vlan-id | wlan wlan-id }

No match criteria are defined.

Class-map configuration

The match command is used to specify which fields in the incoming packets are examined to classify the packets. Only the IP access group or the MAC access group matching to the Ether Type/Len are supported.

If you enter the class-map match-any class-map-name global configuration command, you can enter the following match commands:

match access-group name acl-name

match ip dscp dscp-list

match ip precedence ip-precedence-list

The match access-group acl-index command is not supported.

To define packet classification on a physical-port basis, only one match command per class map is supported. In this situation, the match-any keyword is equivalent.

For the match ip dscp dscp-list or the match ip precedence ip-precedence-list command, you can enter a mnemonic name for a commonly used value. For example, you can enter the match ip dscp af11 command, which is the same as entering the match ip dscp 10 command. You can enter the match ip precedence critical command, which is the same as entering the match ip precedence 5 command. For a list of supported mnemonics, enter the match ip dscp ? or the match ip precedence ? command to see the command-line help strings.

Use the input-interface interface-id-list keyword when you are configuring an interface-level class map in a hierarchical policy map. For the interface-id-list , you can specify up to six entries.

This example shows how to create a class map called class2, which matches all the incoming traffic with DSCP values of 10, 11, and 12:

This example shows how to create a class map called class3, which matches all the incoming traffic with IP-precedence values of 5, 6, and 7:

This example shows how to delete the IP-precedence match criteria and to classify traffic using acl1:

This example shows how to specify a list of physical ports to which an interface-level class map in a hierarchical policy map applies:

This example shows how to specify a range of physical ports to which an interface-level class map in a hierarchical policy map applies:

To create or modify a policy map that can be attached to multiple physical ports or switch virtual interfaces (SVIs) and to enter policy-map configuration mode, use the policy-map command in global configuration mode. Use the no form of this command to delete an existing policy map and to return to global configuration mode.

policy-map policy-map-name

no policy-map policy-map-name

No policy maps are defined.

Global configuration (config)

After entering the policy-map command, you enter policy-map configuration mode, and these configuration commands are available:

class —Defines the classification match criteria for the specified class map.

description —Describes the policy map (up to 200 characters).

exit —Exits policy-map configuration mode and returns you to global configuration mode.

no —Removes a previously defined policy map.

sequence-interval —Enables sequence number capability.

To return to global configuration mode, use the exit command. To return to privileged EXEC mode, use the end command.

Before configuring policies for classes whose match criteria are defined in a class map, use the policy-map command to specify the name of the policy map to be created, added to, or modified. Entering the policy-map command also enables the policy-map configuration mode in which you can configure or modify the class policies for that policy map.

You can configure class policies in a policy map only if the classes have match criteria defined for them. To configure the match criteria for a class, use the class-map global configuration and match class-map configuration commands. You define packet classification on a physical-port basis.

Only one policy map per ingress port is supported. You can apply the same policy map to multiple physical ports.

You can apply a nonhierarchical policy maps to physical ports. A nonhierarchical policy map is the same as the port-based policy maps in the device.

A hierarchical policy map has two levels in the format of a parent-child policy. The parent policy cannot be modified but the child policy (port-child policy) can be modified to suit the QoS configuration.

In VLAN-based QoS, a service policy is applied to an SVI interface.

This example shows how to create a policy map called policy1. When attached to the ingress port, it matches all the incoming traffic defined in class1, sets the IP DSCP to 10, and polices the traffic at an average rate of 1 Mb/s and bursts at 20 KB. Traffic less than the profile is sent.

This example show you how to configure hierarchical polices:

This example shows how to delete a policy map:

To assign priority to a class of traffic belonging to a policy map, use the priority command in policy-map class configuration mode. To remove a previously specified priority for a class, use the no form of this command.

priority [ Kbps [ burst -in-bytes ] | level level-value [ Kbps [ burst -in-bytes ] ] | percent percentage [ Kb/s [ burst -in-bytes ] ] ]

no priority [ Kb/s [ burst -in-bytes ] | level level value [ Kb/s [ burst -in-bytes ] ] | percent percentage [ Kb/s [ burst -in-bytes ] ] ]

No priority is set.

Policy-map class configuration (config-pmap-c)

The bandwidth and priority commands cannot be used in the same class, within the same policy map. However, these commands can be used together in the same policy map.

When the policy map containing class policy configurations is attached to the interface to stipulate the service policy for that interface, available bandwidth is assessed. If a policy map cannot be attached to a particular interface because of insufficient interface bandwidth, the policy is removed from all interfaces to which it was successfully attached.

The following example shows how to configure the priority of the class in policy map policy1:

To increase the value of the soft buffers used by an interface, use the qos queue-softmax-multiplier command in the global configuration mode.

qos queue-softmax-multiplier range-of-multiplier

no qos queue-softmax-multiplier range-of-multiplier

This example shows how to set the value of softmax buffer to 500:

To configure the queue buffer for the class, use the queue-buffers ratio command in policy-map class configuration mode. Use the no form of this command to remove the ratio limit.

queue-buffers ratio ratio limit

no queue-buffers ratio ratio limit

No queue buffer for the class is defined.

Either the bandwidth , shape , or priority command must be used before using this command. For more information about these commands, see Cisco IOS Quality of Service Solutions Command Reference available on Cisco.com

The device allows you to allocate buffers to queues. If buffers are not allocated, then they are divided equally amongst all queues. You can use the queue-buffer ratio to divide it in a particular ratio. The buffers are soft buffers because Dynamic Threshold and Scaling (DTS) is active on all queues by default.

The following example sets the queue buffers ratio to 10 percent:

To specify or modify the maximum number of packets the queue can hold for a class policy configured in a policy map, use the queue-limit policy-map class configuration command. To remove the queue packet limit from a class, use the no form of this command.

queue-limit queue-limit-size [ packets ] { cos cos-value | dscp dscp-value } percent percentage-of-packets

no queue-limit queue-limit-size [ packets ] { cos cos-value | dscp dscp-value } percent percentage-of-packets

Policy-map class configuration (policy-map-c)

Although visible in the command line help-strings, the packets unit of measure is not supported; use the percent unit of measure.

Weighted fair queuing (WFQ) creates a queue for every class for which a class map is defined. Packets satisfying the match criteria for a class accumulate in the queue reserved for the class until they are sent, which occurs when the queue is serviced by the fair queuing process. When the maximum packet threshold you defined for the class is reached, queuing of any further packets to the class queue causes tail drop.

You use queue limits to configure Weighted Tail Drop (WTD). WTD ensures the configuration of more than one threshold per queue. Each class of service is dropped at a different threshold value to provide for QoS differentiation.

You can configure the maximum queue thresholds for the different subclasses of traffic, that is, DSCP and CoS and configure the maximum queue thresholds for each subclass.

The following example configures a policy map called port-queue to contain policy for a class called dscp-1. The policy for this class is set so that the queue reserved for it has a maximum packet limit of 20 percent:

To change the minimum and maximum packet thresholds for the Class of service (CoS) value, use the random-detect cos command in QoS policy-map class configuration mode. To return the minimum and maximum packet thresholds to the default for the CoS value, use the no form of this command.

random-detect cos cos-value percent min-threshold max-threshold

no random-detect cos cos-value percent min-threshold max-threshold

QoS policy-map class configuration  (config-pmap-c)

Use the random-detect cos command in conjunction with the random-detect command in QoS policy-map class configuration mode.

The random-detect cos command is available only if you have specified the cos-based argument when using the random-detect command in interface configuration mode.

The following example enables WRED to use the CoS value 8. The minimum threshold for the CoS value 8 is 20, the maximum threshold is 40.

Related Commands

To enable weighted random early detection (WRED) on the basis of the class of service (CoS) value of a packet, use the random-detect cos-based command in policy-map class configuration mode. To disable WRED, use the no form of this command.

no random-detect cos-based

When WRED is configured, the default minimum and maximum thresholds are determined on the basis of output buffering capacity and the transmission speed for the interface.

In the following example, WRED is configured on the basis of the CoS value.

To change the minimum and maximum packet thresholds for the differentiated services code point (DSCP) value, use the random-detect dscp command in QoS policy-map class configuration mode. To return the minimum and maximum packet thresholds to the default for the DSCP value, use the no form of this command.

random-detect dscp dscp-value percent min-threshold max-threshold

no random-detect dscp dscp-value percent min-threshold max-threshold

Use the random-detect dscp command in conjunction with the random-detect command in QoS policy-map class configuration mode.

The random-detect dscp command is available only if you specified the dscp-based argument when using the random-detect command in interface configuration mode.

Specifying the DSCP Value

The random-detect dscp command allows you to specify the DSCP value per traffic class. The DSCP value can be a number from 0 to 63, or it can be one of the following keywords: af11 , af12 , af13 , af21 , af22 , af23 , af31 , af32 , af33 , af41 , af42 , af43 , cs1 , cs2 , cs3 , cs4 , cs5 , cs7 , ef , or rsvp .

On a particular traffic class, eight DSCP values can be configured per traffic class. Overall, 29 values can be configured on a traffic class: 8 precedence values, 12 Assured Forwarding (AF) code points, 1 Expedited Forwarding code point, and 8 user-defined DSCP values.

Assured Forwarding Code Points

The AF code points provide a means for a domain to offer four different levels (four different AF classes) of forwarding assurances for IP packets received from other (such as customer) domains. Each one of the four AF classes is allocated a certain amount of forwarding services (buffer space and bandwidth).

Within each AF class, IP packets are marked with one of three possible drop precedence values (binary 2{010}, 4{100}, or 6{110}), which exist as the three lowest bits in the DSCP header. In congested network environments, the drop precedence value of the packet determines the importance of the packet within the AF class. Packets with higher drop precedence values are discarded before packets with lower drop precedence values.

The upper three bits of the DSCP value determine the AF class; the lower three values determine the drop probability.

The following example enables WRED to use the DSCP value 8. The minimum threshold for the DSCP value 8 is 20, the maximum threshold is 40, and the mark probability is 1/10.

To base weighted random early detection (WRED) on the Differnciated Services Code Point (dscp) value of a packet, use the random-detect dscp-based command in policy-map class configuration mode. To disable this feature, use the no form of this command.

no random-detect dscp-based

WRED is disabled by default.

With the random-detect dscp-based command, WRED is based on the dscp value of the packet.

Use the random-detect dscp-based command before configuring the random-detect dscp command.

The following example shows that random detect is based on the precedence value of a packet:

To configure Weighted Random Early Detection (WRED) parameters for a particular IP precedence for a class policy in a policy map, use the random-detect precedence command in QoS policy-map class configuration mode. To return the values to the default for the precedence, use the no form of this command.

random-detect precedence precedence percent min-threshold max-threshold

no random-detect precedence

The default min-threshold value depends on the precedence. The min-threshold value for IP precedence 0 corresponds to half of the max-threshold value. The values for the remaining precedences fall between half the max-threshold value and the max-threshold value at evenly spaced intervals. See the table in the “Usage Guidelines” section of this command for a list of the default minimum threshold values for each IP precedence.

Interface configuration (config-if)

QoS policy-map class configuration (config-pmap-c)

WRED is a congestion avoidance mechanism that slows traffic by randomly dropping packets when congestion exists.

When you configure the random-detect command on an interface, packets are given preferential treatment based on the IP precedence of the packet. Use the random-detect precedence command to adjust the treatment for different precedences.

If you want WRED to ignore the precedence when determining which packets to drop, enter this command with the same parameters for each precedence. Remember to use appropriate values for the minimum and maximum thresholds.

Note that if you use the random-detect precedence command to adjust the treatment for different precedences within class policy, you must ensure that WRED is not configured for the interface to which you attach that service policy.

The following example shows the configuration to enable WRED on the interface and to specify parameters for the different IP precedences:

To base weighted random early detection (WRED) on the precedence value of a packet, use the random-detect precedence-based command in policy-map class configuration mode. To disable this feature, use the no form of this command.

no random-detect precedence-based

With the random-detect precedence-based command, WRED is based on the IP precedence value of the packet.

Use the random-detect precedence-based command before configuring the random-detect precedence-based command.

To apply a policy map to a physical port or a switch virtual interface (SVI), use the service-policy command in interface configuration mode. Use the no form of this command to remove the policy map and port association.

service-policy { input | output } policy-map-name

no service-policy { input | output } policy-map-name

No policy maps are attached to the port.

WLAN interface configuration

A policy map is defined by the policy map command.

Only one policy map is supported per port, per direction. In other words, only one input policy and one output policy is allowed on any one port.

You can apply a policy map to incoming traffic on a physical port or on an SVI.

This example shows how to apply plcmap1 to an physical ingress port:

This example shows how to remove plcmap2 from a physical port:

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:

You can verify your settings by entering the show running-config privileged EXEC command.

To classify IP traffic by setting a Differentiated Services Code Point (DSCP) or an IP-precedence value in the packet, use the set command in policy-map class configuration mode. Use the no form of this command to remove traffic classification.

set cos | dscp | precedence | ip | qos-group

set cos { cos-value } | { cos | dscp | precedence | qos-group } [ table table-map-name ]

set dscp { dscp-value } | { cos | dscp | precedence | qos-group } [ table table-map-name ]

set ip { dscp | precedence }

set precedence { precedence-value } | { cos | dscp | precedence | qos-group } [ table table-map-name ]

set qos-group { qos-group-value | dscp [ table table-map-name ] | precedence [ table table-map-name ]}

No traffic classification is defined.

Policy-map class configuration

For the set dscp dscp-value command, the set cos cos-value command, and the set ip precedence precedence-value command, you can enter a mnemonic name for a commonly used value. For example, you can enter the set dscp af11 command, which is the same as entering the set dscp 10 command. You can enter the set ip precedence critical command, which is the same as entering the set ip precedence 5 command. For a list of supported mnemonics, enter the set dscp ? or the set ip precedence ? command to see the command-line help strings.

When you configure the set dscp cos command, note the following: The CoS value is a 3-bit field, and the DSCP value is a 6-bit field. Only the three bits of the CoS field are used.

When you configure the set dscp qos-group command, note the following:

The valid range for the DSCP value is a number from 0 to 63. The valid value range for the QoS group is a number from 0 to 99.

If a QoS group value falls within both value ranges (for example, 44), the packet-marking value is copied and the packets is marked.

If QoS group value exceeds the DSCP range (for example, 77), the packet-marking value is not be copied and the packet is not marked. No action is taken.

The set qos-group command cannot be applied until you create a service policy in policy-map configuration mode and then attach the service policy to an interface or ATM virtual circuit (VC) .

This example shows how to assign DSCP 10 to all FTP traffic without any policers:

To display the quality of service (QoS) commands entered on the interfaces on which automatic QoS (auto-QoS) is enabled, use the show auto qos command in privileged EXEC mode.

show auto qos [ interface [interface-id] ]

The show auto qos command output shows only the auto qos command entered on each interface. The show auto qos interface interface-id command output shows the auto qos command entered on a specific interface.

Use the show running-config privileged EXEC command to display the auto-QoS configuration and the user modifications.

This is an example of output from the show auto qos command after the auto qos voip cisco-phone and the auto qos voip cisco-softphone interface configuration commands are entered:

This is an example of output from the show auto qos interface interface-id command when the auto qos voip cisco-phone interface configuration command is entered:

These are examples of output from the show auto qos interface interface-id command when auto-QoS is disabled on an interface:

To display quality of service (QoS) class maps, which define the match criteria to classify traffic, use the show class-map command in EXEC mode.

show class-map [ class-map-name | type control subscriber { all | class-map-name } ]

This is an example of output from the show class-map command:

To display device-specific hardware information, use the show platform hardware fed active qos command.

This topic elaborates only the QoS-specific options, that is, the options available with the show platform hardware fed { active | standby } qos command.

show platform hardware fed { active | | | standby } qos { afd | { config type type | [ asic asic_num ] | stats clients { all | bssid id }} | dscp-cos counters { iifd_id id | interface type number } | le-info { iifd_id id | interface type number } | policer config { iifd_id id | interface type number } | queue | { config | { iifd_id id | interface type number | internal port-type type { asic number [ port_num ]}} | label2qmap | [ aqmrepqostbl | iqslabeltable | sqslabeltable ] | { asic number } | stats | { iifd_id id | interface type number | internal { cpu policer | port-type type asic number } { asic number [ port_num ]}}} | resource }

This is an example of output from the show platform hardware fed active qos queue stats internal cpu policer command

To display device-specific software information, use the show platform hardware fed {active | standby} command.

This topic elaborates only the QoS-specific options available with the show platform software fed { active | standby } qos command.

show platform software fed { active | standby } qos { avc | internal | label2qmap | nflqos | policer | policy | qsb | tablemap }

To display quality of service (QoS) policy maps, which define classification criteria for incoming traffic, use the show policy-map command in EXEC mode.

show policy-map [ policy-map-name | interface interface-id ]

show policy-map interface { Auto-template | Capwap | GigabitEthernet | GroupVI | InternalInterface | Loopback | Lspvif | Null | Port-channel | TenGigabitEthernet | Tunnel | Vlan | brief | class | input | output }

show policy-map type control subscriber detail

Policy maps can include policers that specify the bandwidth limitations and the action to take if the limits are exceeded.

To display quality of service (QoS)-related information for use by technical support, use the show tech-support qos command in privileged EXEC mode.

show tech-support qos [ {active | all | standby} [control-plane | interface interface-name ]]

Privileged EXEC (#)

The output of this command is very long. To better manage this output, you can redirect the output to an external file (for example, show tech-support qos | redirect flash: filename ) in the local writable storage file system or remote file system.

The output of the show tech-support qos command displays a list of commands and their output. These commands differ based on the platform.

Output fields are self-explanatory.

To configure trust for supported devices connected to an interface, use the trust device command in interface configuration mode. Use the no form of this command to disable trust for the connected device.

trust device { cisco-phone | cts | ip-camera | media-player }

no trust device { cisco-phone | cts | ip-camera | media-player }

Trust disabled

Use the trust device command on the following types of interfaces:

Auto — auto-template interface

Capwap —CAPWAP tunnel interface

GigabitEthernet —Gigabit Ethernet IEEE 802

GroupVI —Group virtual interface

Internal Interface —Internal interface

Loopback —Loopback interface

Null —Null interface

Port-channel —Ethernet Channel interface

TenGigabitEthernet-- 10-Gigabit Ethernet

Tunnel —Tunnel interface

Vlan —Catalyst VLANs

range — interface range command

The following example configures trust for a Cisco IP phone in Interface GigabitEthernet 1/0/1 :

Was this Document Helpful?

Contact Cisco

• (Requires a Cisco Service Contract )