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.
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:
EXP value provided by the CoS rewrite action.
EXP value derived from the top label of the stack (MPLS label stacking).
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.
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.
[edit]
firewall {
family inet {
filter vrf-rewrite {
term 1 {
from {
dscp b001100;
}
then {
dscp 0;
forwarding-class best-effort;
}
}
term 2 {
from {
dscp b010110;
}
then {
forwarding-class best-effort;
}
}
}
}
}
Applying the Multifield Classifier
Apply the filter to an input interface corresponding to the VRF:
[edit]
interfaces {
so-0/1/0 {
unit 0 {
family inet {
filter input vrf-rewrite;
}
}
}
}
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 0action, then the outgoing DSCP value of the packet is0, even if the packet matches a rewrite rule, and the rewrite rule is configured to mark the packet to a non-zero value. Thedscp 0action overrides any other rewrite rule actions configured on the router.Although you can use the
dscp 0action on an input filter, the output filter and other classifiers do not see the packet as being markeddscp 0. Instead, they classify the packet based on its original incoming DSCP value. The DSCP value of the packet is set to0after all other classification actions have completed on the packet.