# MPLS QoS Modes

There are three MPLS QoS modes which are sometimes referred to as “tunneling” MPLS DiffServ. The three modes are: *uniform mode*, *short-pipe mode*, and *pipe mode*. The IP Precedence (or first three bits of the DSCP value) of a received customer packet is always mapped to the MPLS EXP value by default. The modes differ in whether the SP’s MPLS marking is transferred to the customer IP packet’s marking on egress at the PE-CE point.

Uniform mode means that the customer and SP QoS domain is one in the same. If the SP changes the MPLS EXP value at some point in the LSP, this change is reflected to the customer’s packet on egress. This is typically not desirable - in uniform mode the SP is overwriting the customer’s packet. However, if a single entity controls both the MPLS and customer network (as in a large enterprise running their own MPLS network) then it may make sense to use this.

Pipe and short-pipe mode means that the customer and SP QoS domains are separate. In this case, if the SP changes the MPLS EXP value in the LSP, this change is not reflected on the customer’s packet at egress. The customer’s QoS markings are left unaltered.

The difference between pipe and short-pipe is whether the egress PE uses the SP marking or customer marking when preforming QoS on the egress interface facing the CE. In short-pipe mode, the policy on the egress interface is based on the DSCP of the customer packet. The service provider’s “pipe” is shorter. In pipe mode, the pipe is “longer” because the SP controls a longer stretch of QoS control. The SP’s pipe extends to the egress interface of the egress PE, where policy is based off the MPLS EXP value, not the IP marking.

<table data-header-hidden><thead><tr><th width="193"></th><th></th></tr></thead><tbody><tr><td><strong>Mode</strong></td><td><strong>Use</strong></td></tr><tr><td>Uniform</td><td>The MPLS EXP value is translated to the IP packet on egress. The customer’s packet may be altered when they receive it on egress.</td></tr><tr><td>Short-Pipe</td><td>The IP packet marking is independent of the MPLS EXP marking. The customer’s packet is never altered. The egress PE does policy based on the customer’s marking.</td></tr><tr><td>Pipe</td><td>Same as short-pipe, but the egress PE does policy based on the MPLS marking, not the customer marking.</td></tr></tbody></table>

### Test your knowledge <a href="#ec199ca9-d8bb-43cd-a1fc-02e7159f1248" id="ec199ca9-d8bb-43cd-a1fc-02e7159f1248"></a>

What mode is this?

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2F3jUE5Iv2kKEyLtv0B9vj%2FUntitled.png?alt=media&#x26;token=56d409e9-6eb9-44a0-bc82-3877cc5ece88" alt=""><figcaption></figcaption></figure>

Answer: Uniform mode

What mode is this?

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2FFjnUnwXjGCuZ1EMMOdTB%2FUntitled%201.png?alt=media&#x26;token=e782c133-a39d-4470-945e-e67a52e5fe7e" alt=""><figcaption></figcaption></figure>

Answer: Pipe mode or short-pipe mode. (Not enough information to differentiate here).

What mode would you use if you want to preserve the customer’s original marking?

Answer: Pipe or short-pipe

### Lab <a href="#id-80deb1f1-38b1-4422-ae4a-c1a7a5e54e7b" id="id-80deb1f1-38b1-4422-ae4a-c1a7a5e54e7b"></a>

Let’s breifly lab uniform and pipe mode. We’ll reuse our lab from the previous article.

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2Fik4iwoeBt7AXjC6hxUsi%2Fimage.png?alt=media&#x26;token=4b962972-e4f8-45c4-a4c9-0a22ee1ae717" alt=""><figcaption></figcaption></figure>

First let’s examine what the default behavior is of our topology right now. Does it operate in uniform mode or pipe mode by default? To test we’ll need to change the EXP marking somewhere in the core network and see if it maps to the IPP value on egress.

Let’s configure P3 to re-mark data traffic from EXP 0 to EXP 2 as traffic comes from C2 destined to C1.

```
class-map EXP_0
 match mpls exp topmost 0
!
policy-map CHANGE_EXP_0_TO_2
 class EXP_0
  set mpls exp topmost 2
!
int Gi2
 service-policy input CHANGE_EXP_0_TO_2
```

On C1 we’ll ping C2 and see which IPP value the return traffic (C2 to C1) has as seen on C1.

```
C1#ping 10.1.2.10 repeat 100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.2.10, timeout is 2 seconds:
!!!!!

C1#show policy-map int gi1
 GigabitEthernet1 

  Service-policy input: COUNT_IPP

    Class-map: IPP_0 (match-all)  
      5 packets, 570 bytes
      5 minute offered rate 0000 bps
      Match: ip precedence 0 

    Class-map: IPP_1 (match-all)  
      0 packets, 0 bytes
      5 minute offered rate 0000 bps
      Match: ip precedence 1 

    Class-map: IPP_2 (match-all)  
      0 packets, 0 bytes
      5 minute offered rate 0000 bps
      Match: ip precedence 2
```

The IPP\_2 counters are not incrementing on C1. Let’s take a look at the packet on the link between PE1 and P3:

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2FIUOFCqtnHaQ0ExnOhYab%2FUntitled%202.png?alt=media&#x26;token=6b5edf40-5c33-4164-b651-d60514eef20a" alt=""><figcaption></figcaption></figure>

The packet has a single MPLS label with EXP=0. What happened? P3 set the topmost label to EXP=2 but then popped it off. Let’s configure PE1 to signal P3 to use an explicit-null label instead of preforming PHP.

```
#PE1
mpls ldp explicit-null

P3#show mpls forwarding-table 1.1.1.1
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    
Label      Label      or Tunnel Id     Switched      interface              
19         explicit-n 1.1.1.1/32       60            Gi1        10.1.3.1
```

Here is a pcap taken on the same link again:

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2F2LIJc6YBlcUCXb2BZ5BY%2FUntitled%203.png?alt=media&#x26;token=8ad0c870-8371-43b1-adaa-434e177fef4b" alt=""><figcaption></figcaption></figure>

The IPP\_2 counters are still not incrementing on C1. This is because, by default, the MPLS EXP value is *not* mapped to the IP Precedence when the label is removed.

```
C1#show policy-map int gi1
 GigabitEthernet1 

  Service-policy input: COUNT_IPP

    Class-map: IPP_0 (match-all)  
      15 packets, 1710 bytes
      5 minute offered rate 0000 bps
      Match: ip precedence 0 

    Class-map: IPP_1 (match-all)  
      0 packets, 0 bytes
      5 minute offered rate 0000 bps
      Match: ip precedence 1 

    Class-map: IPP_2 (match-all)  
      0 packets, 0 bytes
      5 minute offered rate 0000 bps
      Match: ip precedence 2
```

So by default, which mode is configured right now?

The answer is pipe mode. In pipe mode, the SP and Customer have two separate QoS domains. The SP markings do not affect the Customer’s traffic. This is the default behavior because the MPLS EXP value is not mapped to the IP Precedence value.

Let’s configure uniform mode now. On PE1 we will match EXP 2 and set the IPP to 2. We cannot map the MPLS EXP directly to the IPP on ingress of Gi2, because it is only label switching the traffic and the hardware is not inspecting the IP layer. Instead we will map the MPLS EXP to a QoS-Group, and then map the QoS-Group to the IPP on egress.

```
class-map EXP_2
 match mpls exp top 2
!
policy-map EXP_TO_QOS_GROUP
 class EXP_2
  set qos-group 2
!
class-map QOS_GROUP_2
 match qos-group 2
!
policy-map QOS_GROUP_TO_IPP
 class QOS_GROUP_2
  set ip precedence 2
!
int Gi2
 service-policy input EXP_TO_QOS_GROUP
!
int Gi1
 service-policy output QOS_GROUP_TO_IPP
```

When we ping again, we see the IPP has been changed to 2:

```
C1#show policy-map int gi1
 GigabitEthernet1 

  Service-policy input: COUNT_IPP

    Class-map: IPP_0 (match-all)  
      25 packets, 2850 bytes
      5 minute offered rate 0000 bps
      Match: ip precedence 0 

    Class-map: IPP_1 (match-all)  
      0 packets, 0 bytes
      5 minute offered rate 0000 bps
      Match: ip precedence 1 

    Class-map: IPP_2 (match-all)  
      10 packets, 1140 bytes
      5 minute offered rate 0000 bps
      Match: ip precedence 2
```

### Conclusion <a href="#id-9ca3a270-3210-4242-8bbb-4d5433520e89" id="id-9ca3a270-3210-4242-8bbb-4d5433520e89"></a>

In this lab we covered the need for explicit null, and uniform/pipe modes. Uniform mode maps the EXP marking onto the IP packet. Pipe mode leaves the customer packet alone and does not map the EXP marking to the IP packet.

You’ve seen that by default, the IP packet’s IPP value is mapped to the MPLS EXP value on ingress, but the reverse is not true. The MPLS EXP value is not mapped to the customer’s IP packet on egress.

This makes sense for most deployments. You want to rely on your customer to mark voice traffic, and not require your PE to do packet inspection to figure out if it is SIP traffic, etc. Yet, if the SP uses the EXP bits to de-prioritize the traffic (perhaps because some traffic exceeded the CIR), you don’t want this to change the customer’s IP packet. The customer should be able to expect that an IP packet sent to one PE will egress the other PE unchanged.

Therefore you will likely see pipe mode in the real world. If the service provider is altering the EXP value in the LSP, then perhaps it wants to use this all the way to the egress interface of the egress PE. We saw how you must translate the EXP value to the QoS group. The QoS group is an internal marking that is not part of the actual packet, but can be used on egress.

If the SP is not changing the EXP value, then it will likely use short-pipe mode, and simply use the customer’s IP marking in the egress policy.

As you can see, these concepts are a bit wordy to explain but hopefully are fairly intuitive once you have configured it and seen it in action!

### Further Reading <a href="#ebebc055-9bfd-44fc-a890-d272361821c9" id="ebebc055-9bfd-44fc-a890-d272361821c9"></a>

*MPLS Fundamentals*, Luc De Ghein, Chapter 12
