Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

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

SUMMARY This topic describes the purpose and configuration of policy maps. Policy maps enable you to assign rewrite rules on a per-customer basis.

Policy Maps Overview

Traditionally, packet marking (that is, setting rewrite rules) in Junos 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 you to directly assign rewrite rules to 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, 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.

  • IPv6 Precedence 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.

  • 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:

On devices running Junos OS, creating a policy map requires you to enable enhanced-ip, enhanced-ethernet, or enhanced-mode under [edit chassis network-services].

On devices running Junos OS Evolved, you must enable policy-map-marking on each egress logical interface that you want to do policy map marking. You enable policy-map-marking at the [edit class-of-service interfaces interface-name unit unit-number] hierarchy level.
Note:

Policy maps have the following configuration restrictions:

  • When configuring both proto-ip and proto-mpls options for inet-precedence, inet6-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.

  • You cannot configure inet6-precedence and dscp-ipv6 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.

You assign a policy map to a customer through a firewall action on an ingress or egress firewall filter (where the match conditions identify the customer). Alternatively, you can 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, you can assign a single policy map 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.

Configuring Policy Maps

To assign rewrite rules on a per-customer basis:

  1. Configure a policy map.

    For example:

  2. Apply the policy map.

    • Apply the policy map to an ingress or egress firewall filter.

      For example:

      Note:

      In this example, every IPv4 packet arriving from IP address 10.2.2.0/24 is assigned a DSCP value of 111000.

    • Alternatively, apply the policy map to a routing instance.

      For example:

      Note:

      In this example, every IPv4 packet in routing instance r1 is assigned a DSCP value of 111000.

    • Alternatively, apply the policy map directly to an ingress interface.

      For example:

      Note:

      In this example, every IPv4 packet arriving on interface xe-4/0/0 unit 0 is assigned a DSCP value of 111000.

Platform-Specific Policy Map Behavior

Use Feature Explorer to confirm platform and release support for policy maps.

Use the following table to review platform-specific behaviors for your platform:

Platform

Difference

PTX10002-36QDD

  • PTX10002-36QDD routers support the following types of packet marking: INET-Precedence, DSCP, IEEE802.1p, and IEEE802.1ad.

  • INET-Precedence and DSCP options mark both IPv4 and IPv6 packets.

  • Due to hardware limitations, you can't create a policy map with both Layer 2 and Layer 3 packet marking types.

  • Enabling policy-map action on an egress filter interface does not have any impact on rewrite values.

Related Documentation