Configuring MPLS Firewall Filters and Policers
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 on input or output. 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 cannot apply MPLS firewall filters to loopback interfaces.
You can configure the following match conditions for MPLS filters at the [edit firewall family mpls filter filter-name term term-name from] hierarchy level:
These exp match condition 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];
The label match condition can accept a range of values from 0 to 1048575.
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:
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:
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.
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.