Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Example: Writing Different DSCP and EXP Values in MPLS-Tagged IP Packets

 

On Juniper Networks M320 Multiservice Edge Routers and T Series Core Routers, you can selectively set the DSCP field of MPLS-tagged IPv4 and IPv6 packets to 000000. In the same packets, you can set the MPLS EXP field according to a configured rewrite table, which is based on the forwarding classes that you set in incoming packets using a BA or multifield classifier.

Queue selection is based on the forwarding classes you assign in scheduler maps. This means that you can direct traffic to a single output queue, regardless of whether the DSCP field is unchanged or rewritten to 000000. To do this, you must configure a multifield classifier that matches selected packets and modifies them with the dscp 0 action.

Selective marking of DSCP fields to 0, without affecting output queue assignment, can be useful. For example, suppose you need to use the MPLS EXP value to configure CoS applications for core provider routers. At the penultimate egress provider edge (PE) router where the MPLS labels are removed, the CoS bits need to be provided by another value, such as DSCP code points. This case illustrates why it is useful to mark both the DSCP and MPLS EXP fields in the packet. Furthermore, it is useful to be able to mark the two fields differently, because the CoS rules of the core provider router might differ from the CoS rules of the egress penultimate router. At egress, as always, you can use a rewrite table to rewrite the MPLS EXP values corresponding to the forwarding classes that you need to set.

Note

When both customer-facing and core-facing interfaces exist, you can derive the EXP value in the following precedence order, while adding the MPLS label:

  1. EXP value provided by the CoS rewrite action.
  2. EXP value derived from the top label of the stack (MPLS label stacking).
  3. IPv4 or IPv6 precedence (Layer 3 VPN, Layer 2 VPN, and VPLS scenarios).

For IPv4 traffic, the dscp 0 action modifier at the [edit firewall family inet filter filter-name term term-name then] hierarchy level is valid. However, for IPv6 traffic, you configure this feature by including the traffic-class 0 action modifier at the [edit firewall family inet6 filter filter-name term term-name then] hierarchy level.

In the following IPv4 example, term 1 of the multifield classifier matches packets with DSCP 001100 code points coming from a certain VRF, rewrites the bits to DSCP 000000, and sets the forwarding class to best-effort. In term 2, the classifier matches packets with DSCP 010110 code points and sets the forwarding class to best-effort. Because term 2 does not include the dscp 0 action modifier, the DSCP 010110 bits remain unchanged. Because the classifier sets the forwarding class for both code points to best-effort, both traffic types are directed to the same output queue.

Note

If you configure a bit string in a DSCP match condition in a firewall filter, then you must include the letter “b” in front of the string, or the match rule creation fails on commit.

Applying the Multifield Classifier

Apply the filter to an input interface corresponding to the VRF:

Note

The dscp 0 action is supported in both input and output filters. You can use this action for non-MPLS packets as well as for IPv4 and IPv6 packets entering an MPLS network. All IPv4 and IPv6 firewall filter match conditions are supported with the dscp 0 action.

The following limitations apply:

  • You can use a multifield classifier to rewrite DSCP fields to value 0 only. Other values are not supported.

  • If a packet matches a filter that has the dscp 0 action, then the outgoing DSCP value of the packet is 0, even if the packet matches a rewrite rule, and the rewrite rule is configured to mark the packet to a non-zero value. The dscp 0 action overrides any other rewrite rule actions configured on the router.

  • Although you can use the dscp 0 action on an input filter, the output filter and other classifiers do not see the packet as being marked dscp 0. Instead, they classify the packet based on its original incoming DSCP value. The DSCP value of the packet is set to 0 after all other classification actions have completed on the packet.