Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Firewall Filters for MPLS

Configuring MPLS Firewall Filters and Policers on Routers

You can configure an MPLS firewall filter to count packets based on the EXP bits for the top-level MPLS label in a packet. You can also configure policers for MPLS LSPs.

The following sections discuss MPLS firewall filters and policers:

Configuring MPLS Firewall Filters

You can configure an MPLS firewall filter to count packets based on the EXP bits for the top-level MPLS label in a packet. You can then apply this filter to a specific interface. You can also configure a policer for the MPLS filter to police (that is, rate-limit) the traffic on the interface to which the filter is attached.

You can configure the following match criteria attributes for MPLS filters at the [edit firewall family mpls filter filter-name term term-name from] hierarchy level:

  • exp

  • exp-except

These attributes can accept EXP bits in the range 0 through 7. You can configure the following choices:

  • A single EXP bit—for example, exp 3;

  • Several EXP bits—for example, exp 0, 4;

  • A range of EXP bits—for example, exp [0-5];

If you do not specify a match criterion (that is, you do not configure the from statement and use only the then statement with the count action keyword), all the MPLS packets passing through the interface on which the filter is applied will be counted.

You also can configure any of the following action keywords at the [edit firewall family mpls filter filter-name term term-name then] hierarchy level:

  • count

  • accept

  • discard

  • next

  • policer

For more information about how to configure firewall filters, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide. For more information about how to configure interfaces, see the Junos OS Network Interfaces Library for Routing Devices and the Junos OS Services Interfaces Library for Routing Devices.

Examples: Configuring MPLS Firewall Filters

The following examples illustrate how you might configure an MPLS firewall filter and then apply the filter to an interface. This filter is configured to count MPLS packets with EXP bits set to either 0 or 4.

The following shows a configuration for an MPLS firewall filter:

The following shows how to apply the MPLS firewall filter to an interface:

The MPLS firewall filter is applied to the input and output of an interface (see the input and output statements in the preceding example).

Configuring Policers for LSPs

MPLS LSP policing allows you to control the amount of traffic forwarded through a particular LSP. Policing helps to ensure that the amount of traffic forwarded through an LSP never exceeds the requested bandwidth allocation. LSP policing is supported on regular LSPs, LSPs configured with DiffServ-aware traffic engineering, and multiclass LSPs. You can configure multiple policers for each multiclass LSP. For regular LSPs, each LSP policer is applied to all of the traffic traversing the LSP. The policer's bandwidth limitations become effective as soon as the total sum of traffic traversing the LSP exceeds the configured limit.

You configure the multiclass LSP and DiffServ-aware traffic engineering LSP policers in a filter. The filter can be configured to distinguish between the different class types and apply the relevant policer to each class type. The policers distinguish between class types based on the EXP bits.

You configure LSP policers under the family any filter. The family any filter is used because the policer is applied to traffic entering the LSP. This traffic might be from different families: IPv6, MPLS, and so on. You do not need to know what sort of traffic is entering the LSP, as long as the match conditions apply to all types of traffic.

You can configure only those match conditions that apply across all types of traffic. The following are the supported match conditions for LSP policers:

  • forwarding-class

  • packet-length

  • interface

  • interface-set

To enable a policer on an LSP, first you need to configure a policing filter and then include it in the LSP configuration. For information about how to configure policers, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide.

To configure a policer for an LSP, specify a filter by including the filter option to the policing statement:

You can include the policing statement at the following hierarchy levels:

LSP Policer Limitations

When configuring MPLS LSP policers, be aware of the following limitations:

  • LSP policers are supported for packet LSPs only.

  • LSP policers are supported for unicast next hops only. Multicast next hops are not supported.

  • LSP policers are not supported on aggregated interfaces.

  • The LSP policer runs before any output filters.

  • Traffic sourced from the Routing Engine (for example, ping traffic) does not take the same forwarding path as transit traffic. This type of traffic cannot be policed.

  • LSP policers work on all T Series routers and on M Series routers that have the Internet Processor II application-specific integrated circuit (ASIC).

  • LSP policers are not supported for point-to-multipoint LSPs.

Example: Configuring an LSP Policer

The following example shows how you can configure a policing filter for an LSP:

Configuring Automatic Policers

Automatic policing of LSPs allows you to provide strict service guarantees for network traffic. Such guarantees are especially useful in the context of Differentiated Services for traffic engineered LSPs, providing better emulation for ATM wires over an MPLS network. For more information about Differentiated Services for LSPs, see DiffServ-Aware Traffic Engineering Introduction.

Differentiated Services for traffic engineered LSPs allow you to provide differential treatment to MPLS traffic based on the EXP bits. To ensure these traffic guarantees, it is insufficient to simply mark the traffic appropriately. If traffic follows a congested path, the requirements might not be met.

LSPs are guaranteed to be established along paths where enough resources are available to meet the requirements. However, even if the LSPs are established along such paths and are marked properly, these requirements cannot be guaranteed unless you ensure that no more traffic is sent to an LSP than there is bandwidth available.

It is possible to police LSP traffic by manually configuring an appropriate filter and applying it to the LSP in the configuration. However, for large deployments it is cumbersome to configure thousands of different filters. Configuration groups cannot solve this problem either, since different LSPs might have different bandwidth requirements, requiring different filters. To police traffic for numerous LSPs, it is best to configure automatic policers.

When you configure automatic policers for LSPs, a policer is applied to all of the LSPs configured on the router. However, you can disable automatic policing on specific LSPs.

Note:

When you configure automatic policers for DiffServ-aware traffic engineering LSP, GRES is not supported.
Note:

You cannot configure automatic policing for LSPs carrying CCC traffic.

The following sections describe how to configure automatic policers for LSPs:

Configuring Automatic Policers for LSPs

To configure automatic policers for standard LSPs (neither DiffServ-aware traffic engineered LSPs nor multiclass LSPs), include the auto-policing statement with either the class all policer-action option or the class ct0 policer-action option:

You can include this statement at the following hierarchy levels:

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

You can configure the following policer actions for automatic policers:

  • drop—Drop all packets.

  • loss-priority-high—Set the packet loss priority (PLP) to high.

  • loss-priority-low—Set the PLP to low.

These policer actions are applicable to all types of LSPs. The default policer action is to do nothing.

Automatic policers for LSPs police traffic based on the amount of bandwidth configured for the LSPs. You configure the bandwidth for an LSP using the bandwidth statement at the [edit protocols mpls label-switched-path lsp-path-name] hierarchy level. If you have enabled automatic policers on a router, change the bandwidth configured for an LSP, and commit the revised configuration, the change does not take affect on the active LSPs. To force the LSPs to use the new bandwidth allocation, issue a clear mpls lsp command.

Note:

You cannot configure automatic policers for LSPs that traverse aggregated interfaces or Multilink Point-to-Point Protocol (MLPPP) interfaces.

Configuring Automatic Policers for DiffServ-Aware Traffic Engineering LSPs

To configure automatic policers for DiffServ-aware traffic engineering LSPs and for multiclass LSPs, include the auto-policing statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

You include either the class all policer-action statement or a class ctnumber policer-action statement for each of one or more classes (you can configure a different policer action for each class). For a list of the actions that you can substitute for the policer-action variable, see Configuring Automatic Policers for LSPs. The default policer action is to do nothing.

Note:

You cannot configure automatic policers for LSPs that traverse aggregated interfaces or MLPPP interfaces.

Configuring Automatic Policers for Point-to-Multipoint LSPs

You can configure automatic policers for point-to-multipoint LSPs by including the auto-policing statement with either the class all policer-action option or the class ct0 policer-action option. You only need to configure the auto-policing statement on the primary point-to-multipoint LSP (for more information on primary point-to-multipoint LSPs, see Configuring the Primary Point-to-Multipoint LSP). No additional configuration is required on the subLSPs for the point-to-multipoint LSP. Point-to-multipoint automatic policing is applied to all branches of the point-to-multipoint LSP. In addition, automatic policing is applied to any local VRF interfaces that have the same forwarding entry as a point-to-multipoint branch.

The automatic policer configuration for point-to-multipoint LSPs is identical to the automatic policer configuration for standard LSPs. For more information, see Configuring Automatic Policers for LSPs.

Disabling Automatic Policing on an LSP

When you enable automatic policing, all of the LSPs on the router or logical system are affected. To disable automatic policing on a specific LSP on a router where you have enabled automatic policing, include the policing statement with the no-auto-policing option:

You can include this statement at the following hierarchy levels:

Example: Configuring Automatic Policing for an LSP

Configure automatic policing for a multiclass LSP, specifying different actions for class types ct0, ct1, ct2, and ct3.

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

You can selectively set the DiffServ code point (DSCP) field of MPLS-tagged IPv4 and IPv6 packets to 0 without affecting output queue assignment, and continue to set the MPLS EXP field according to the configured rewrite table, which is based on forwarding classes. You can accomplish this by configuring a firewall filter for the MPLS-tagged packets.

Platform-Specific Behavior

Use Feature Explorer to confirm platform and release support for specific features.

Use the following tables to review platform-specific behavior for your platform:

Platform

Difference

PTX Series Routers

The PTX10003 router only supports regular LSPs.

Overview of MPLS Firewall Filters on Loopback Interface

Although all interfaces are important, the loopback interface might be the most important because it is the link to the Routing Engine, which runs and manages all the routing protocols. The loopback interface is a gateway for all the control traffic that enters the Routing Engine of the switch. You can control traffic by configuring a firewall filter on the loopback interface (lo0) on family mpls in QFX5100, QFX5110, QFX5200, and QFX5210 switches. Loopback firewall filters affect only traffic destined for the Routing Engine CPU. You can apply a loopback firewall filter only in the ingress direction (packets entering the interface). Starting with Junos OS Release 19.2R1, you can apply an MPLS firewall filter to a loopback interface on a label switch router (LSR) on QFX5100, QFX5110, QFX5200, and QFX5210 switches.

When you configure an MPLS firewall filter, you define filtering criteria (terms, with match conditions) for the packets and an action for the switch to take if the packets match the filtering criteria. Because you apply the filter to a loopback interface, you must explicitly specify the time to live (TTL) match condition under family mpls and set its TTL value to 1 (ttl=1). The TTL is an 8-bit (IPv4) header field that signifies the remaining time an IP packet has left before its life ends and is dropped. You can also match packets with other MPLS qualifiers such as label, exp, Layer 4 source port, and Layer 4 destination port.

Benefits of Adding MPLS Firewall Filters on the Loopback Interface

  • Protects the Routing Engine by ensuring that it accepts traffic only from trusted networks.

  • Helps protect the Routing Engine from denial-of-service attacks.

  • Gives you the flexibility to match packets on the source port and destination port. For example, if you run a traceroute, you can selectively filter traffic by choosing either TCP or UDP.

Guidelines and Limitations

  • You can apply a loopback firewall filter only in the ingress direction

  • Only MPLS fields label, exp, ttl=1 and Layer 4 fields tcp and udp port numbers are supported.

  • Only accept, discard, and count actions are supported.

  • You must explicitly specify ttl=1 under family mpls to match on TLL packets.

  • Filters applied on the loopback interface cannot be matched on the destination port (inner payload) of an IPv6 packet.

  • You cannot apply a filter on packets that have more than two MPLS labels.

  • You cannot specify a port range for TCP or UDP match conditions.

  • Only 255 firewall terms are supported.

Platform-Specific MPLS firewall filters Behavior

Table 1: Platform-Specific Behavior

Platform

Difference

QFX5100 / QFX5110 / QFX5200 / QFX5210

Supports MPLS firewall filters on lo0 from Junos OS 19.2R1; only ingress direction; ttl=1 required under family mpls.

MX Series

Supports MPLS filters on lo0; fxp0 supports only IP filters, not MPLS.

PTX Series

Supports MPLS filters on lo0.

Configuring MPLS Firewall Filters and Policers on Switches

You can configure firewall filters to filter MPLS traffic. To use an MPLS firewall filter, you must first configure the filter and then apply it to an interface you have configured for forwarding MPLS traffic. You can also configure a policer for the MPLS filter to police (that is, rate-limit) the traffic on the interface to which the filter is attached.

When you configure an MPLS firewall filter, you define the filtering criteria (terms, with match conditions) and an action for the switch to take if the packets match the filtering criteria.

Note:

You can only configure MPLS filters in the ingress direction. Egress MPLS firewall filters are not supported.

Configuring an MPLS Firewall Filter

To configure an MPLS firewall filter:

  1. Configure the filter name, term name, and at least one match condition—for example, match on MPLS packets with EXP bits set to either 0 or 4:
  2. In each firewall filter term, specify the actions to take if the packet matches all the conditions in that term—for example, count MPLS packets with EXP bits set to either 0 or 4:
  3. When you are finished, follow the steps below to apply the filter to an interface.

Applying an MPLS Firewall Filter to an MPLS Interface

To apply the MPLS firewall filter to an interface you have configured for forwarding MPLS traffic (using the family mpls statement at the [edit interfaces interface-name unit unit-number] hierarchy level):

Note:

You can apply firewall filters only to filter MPLS packets that enter an interface.

  1. Apply the firewall filter to an MPLS interface—for example, apply the firewall filter to interface xe-0/0/5:
  2. Review your configuration and issue the commit command:

Applying an MPLS Firewall Filter to a Loopback Interface

To apply an MPLS firewall filter to a loopback interface (lo0):

  1. First, specify the packet format by using the packet-format-match command. You must restart the PFE every time you configure this command.
  2. Configure the firewall filter match conditions and actions as described in Configuring MPLS Firewall Filters and Policers on Switches. You must explicitly set the TTL match condition to (ttl=1). You can also match packets with other MPLS qualifiers such as label, exp, and Layer 4 source port, and destination port.
  3. Apply the filter to the loopback interface as an input filter.
  4. Review your configuration and issue the commit command:

The following is an example configuration.

Configuring Policers for LSPs

You can send traffic matched by an MPLS filter to a two-color policer or three-color policer. MPLS LSP policing allows you to control the amount of traffic forwarded through a particular LSP. Policing helps to ensure that the amount of traffic forwarded through an LSP never exceeds the requested bandwidth allocation. LSP policing is supported on regular LSPs, LSPs configured with DiffServ-aware traffic engineering, and multiclass LSPs. You can configure multiple policers for each multiclass LSP. For regular LSPs, each LSP policer is applied to all of the traffic traversing the LSP. The policer's bandwidth limitations become effective as soon as the total sum of traffic traversing the LSP exceeds the configured limit.

You configure the multiclass LSP and DiffServ-aware traffic engineering LSP policers in a filter. The filter can be configured to distinguish between the different class types and apply the relevant policer to each class type. The policers distinguish between class types based on the EXP bits.

You configure LSP policers under the family any filter. The family any filter is used because the policer is applied to traffic entering the LSP. This traffic might be from different families: IPv6, MPLS, and so on. You do not need to know what sort of traffic is entering the LSP, as long as the match conditions apply to all types of traffic.

When configuring MPLS LSP policers, be aware of the following limitations:

  • LSP policers are supported for packet LSPs only.

  • LSP policers are supported for unicast next hops only. Multicast next hops are not supported.

  • The LSP policer runs before any output filters.

  • Traffic sourced from the Routing Engine (for example, ping traffic) does not take the same forwarding path as transit traffic. This type of traffic cannot be policed.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
19.2R1
Starting with Junos OS Release 19.2R1, you can apply an MPLS firewall filter to a loopback interface on a label switch router (LSR) on QFX5100, QFX5110, QFX5200, and QFX5210 switches.