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

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

Most commonly, packet marking (that is, setting rewrite rules) in Junos uses the forwarding class and loss priority determined through a behavior aggregate (BA) classifier or multifield classifier. The forwarding class and loss priority are also used to decide queuing and scheduling 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 is undesirable 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) separate from queuing and scheduling behavior. 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. Depending on your platform and software release, 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.

    • proto-all – Enable IP header marking.

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

    • proto-all – Enable IP header marking.

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

    • proto-all – Enable IPv6 header marking.

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

To enable the policy map feature:

  • On most devices, enable enhanced-ip, enhanced-ethernet, or enhanced-mode under [edit chassis network-services].

  • On PTX10002-36QDD routers, 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.

Use Policy Maps to Pass Meta Data

On PTX10002-36QDD routers, you can also use policy maps to pass meta data between firewall filters. That is, a policy map value set in an ingress filter can be matched on in an egress filter, enabling you to perform any firewall action based on that meta data.

Note:

Use of policy maps for this purpose is not a CoS function and does not require a QoS license. When committing a configuration for this purpose, you can safely ignore any notice of the requirement of a QoS license.

As an example, consider a device with an ingress interface of xe-0/0/0 and an egress interface of xe-1/0/0. You can define an input firewall filter for xe-0/0/0 with a policy map as an action based on any desired match conditions. You can then define an egress firewall filter for xe-1/0/0 with that policy map as a match condition and apply any desired actions for packets that have that policy map applied.

  1. Enable policy map marking on each egress interface that you want to do policy map marking.

    For example:

  2. Configure a policy map.
    CAUTION:

    Be sure to define this policy map so it does not interfere with your packet marking (rewrite rule) scheme. For example, use a packet marking type here that you don't use for your normal packet marking.

    For example:

  3. Define an input firewall filter with the policy map as an action.

    For example:

  4. Apply the input firewall filter to an ingress interface.

    For example:

  5. Define an output firewall filter with the policy map as a match condition.

    For example:

  6. Apply the output firewall filter to an egress interface.

    For example:

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

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

  • INET-Precedence option marks 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.

  • You can also use policy maps to pass meta data between firewall filters. That is, a policy map value set in an ingress filter can be matched on in an egress filter.

Related Documentation