Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Assigning Rewrite Rules on a Per-Customer Basis Using Policy Maps Overview

Traditionally, packet marking (that is, setting rewrite rules) in Junos OS uses the forwarding class and loss priority that have been determined through a behavior aggregate (BA) classifier or multifield classifier. The forwarding class and loss priority are also used to decide queuing behavior. This approach does not allow rewrite rules to be directly assigned for each customer because of the limited number of combinations of forwarding class and loss priority. When a new customer is added, setting rewrite rules using this approach requires changes to the configuration on the core interfaces, which must be avoided as one mistake can affect traffic from all customers.

An alternative packet marking scheme, available starting in Junos OS 16.1, called policy map, enables you to define rewrite rules on a per-customer basis (that is, for each customer). The policy map makes it possible to use any packet field to identify a given flow and specify a rewrite value for that flow.

A policy map is defined at the [edit class-of-service policy-map] hierarchy level. The policy map can define the following types of packet marking:

  • IPv4 Precedence with the following options:

    • proto-ip – Mark the packet for IPv4 to IPv4 traffic.

    • proto-mpls – Mark the packet for an IPv4 packet entering an MPLS tunnel.

  • IPv4 DSCP with the following options:

    • proto-ip – Mark the packet for IPv4 to IPv4 traffic.

    • proto-mpls – Mark the packet for an IPv4 packet entering an MPLS tunnel.

  • IPv6 DSCP with the following options:

    • proto-ip – Mark the packet for IPv6 to IPv6 traffic.

    • proto-mpls – Mark the packet for an IPv6 packet entering an MPLS tunnel.

  • MPLS EXP with the following options:

    • all-label – Mark all labels.

    • outer-label – Mark only the outer label.

  • IEEE 802.1p with the following options:

    • outer – Mark only the outer VLAN header.

    • outer-and-inner – Mark both the outer and inner VLAN headers.

  • IEEE 802.1ad with the following options:

    • outer – Mark only the outer VLAN header.

    • outer-and-inner – Mark both the outer and inner VLAN headers.

Note:

Creating a policy map requires enhanced-ip, enhanced-ethernet, or enhanced-mode to be configured under [edit chassis network-services].

Note:

Policy maps have the following configuration restrictions:

  • When configuring both proto-ip and proto-mpls options for inet-precedence, dscp, or dscp-ipv6, you must configure both options with the same code point or code point alias.

  • You cannot configure inet-precedence and dscp in the same policy map.

  • In case of MPLS SWAP/PUSH operation, only the new labels are marked on all label-switching routers (LSRs), except the penultimate hop case where if it exposes the next label in the stack, then the exposed label is marked. Therefore, with the penultimate hop, the service label is changed.

  • You cannot configure ieee-802.1 and ieee-802.1ad in the same policy map.

  • You cannot configure both outer and outer-and-inner options for ieee-802.1 and ieee-802.1ad code points in the same policy map.

  • For IEEE 802.1ad with the outer-and-inner option, the discard eligibility (DE) bit is marked only for the outer VLAN header. For the inner VLAN header, only the three CoS Bits are marked.

The policy map can be assigned to a customer through a firewall action on an ingress or egress firewall filter (where the match conditions identify the customer). Alternatively, you can also assign a policy map to an ingress interface or a routing instance. You can assign multiple policy maps to a customer, one for each of the customer’s traffic flows. Also, a single policy map can be assigned to multiple customers.

A policy map is executed on a packet just before it is queued, so it overrides any other packet- marking scheme that was previously applied to the packet.