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:
exp
label
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:
accept
count
discard
policer
three-color-policer
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:
[edit firewall] family mpls { filter expf { term expt0 { from { exp 0,4; } then { count counter0; accept; } } } }
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.