[Contents] [Prev] [Next] [Index] [Report an Error]

Applying Policers

Policers allow you to perform simple traffic policing on specific interfaces or Layer 2 virtual private networks (VPNs) without configuring a firewall filter. To apply policers, include the policer statement:

policer {
arp policer-template-name;
input policer-template-name;
output policer-template-name;
}

You can include these statements at the following hierarchy levels:

In the family statement, the protocol family can be ccc, inet, inet6, mpls, tcc, or vpls.

In the arp statement, list the name of one policer template to be evaluated when Address Resolution Protocol (ARP) packets are received on the interface. By default, an ARP policer is installed that is shared among all the Ethernet interfaces on which you have configured the family inet statement. If you want more stringent or lenient policing of ARP packets, you can configure an interface-specific policer and apply it to the interface. You configure an ARP policer just as you would configure any other policer, at the [edit firewall policer] hierarchy level. If you apply this policer to an interface, the default ARP packet policer is overridden. If you delete this policer, the default policer takes effect again.

In the input statement, list the name of one policer template to be evaluated when packets are received on the interface.

In the output statement, list the name of one policer template to be evaluated when packets are transmitted on the interface.

Note: To use policing on a CCC or TCC interface, you must configure the CCC or TCC protocol family.

You can configure a different policer on each protocol family on an interface, with one input policer and one output policer for each family. When you apply policers, you can configure the family ccc, inet, inet6, mpls, tcc, or vpls only, and one ARP policer for the family inet protocol only. Each time a policer is referenced, a separate copy of the policer is installed on the packet forwarding components for that interface.

If you apply both policers and firewall filters to an interface, input policers are evaluated before input firewall filters, and output policers are evaluated after output firewall filters.

If you apply the policer to the interface lo0, it is applied to packets received or transmitted by the Routing Engine.

On M-series platforms (except the M320 and M120 routers), if you apply a firewall filter or policer to multiple interfaces, the filter or policer acts on the sum of traffic entering or exiting those interfaces. On T-series, M120, and M320 platforms, the filter or policer acts on the sum of traffic, if the interfaces are on the same FPC.

For more information about policers, see the JUNOS Policy Framework Configuration Guide.

Applying Aggregate Policers

By default, if you apply a policer to multiple protocol families on the same logical interface, the policer restricts traffic for each protocol family individually. For example, a policer with a 50 Mbps bandwidth limit applied to both IPv4 and IPv6 traffic would allow the interface to accept 50 Mbps of IPv4 traffic and 50 Mbps of IPv6 traffic. If you apply an aggregate policer, the policer would allow the interface to receive only 50 Mbps of IPv4 and IPv6 traffic combined.

To configure an aggregate policer, include the logical-interface-policer statement at the [edit firewall policer policer-template-name] hierarchy level:

[edit firewall policer policer-template-name]
logical-interface-policer;

For the policer to be treated as an aggregate, you must apply it to multiple protocol families on a single logical interface by including the policer statement:

policer {
arp policer-template-name;
input policer-template-name;
output policer-template-name;
}

You can include these statements at the following hierarchy levels:

In the family statement, the protocol family can be ccc, inet, inet6, mpls, tcc, or vpls.

The protocol families on which you do not apply the policer are not affected by the policer. For example, if you configure a single logical interface to accept MPLS, IPv4, and IPv6 traffic and you apply the logical interface policer policer1 to only the IPv4 and IPv6 protocol families, MPLS traffic is not subject to the constraints of policer1.

If you apply policer1 to a different logical interface, there are two instances of the policer. This means the JUNOS software polices traffic on separate logical interfaces separately, not as an aggregate, even if the same logical-interface policer is applied to multiple logical interfaces on the same physical interface port.

Note: Logical interface policers are not supported for filter policers. In other words, you cannot include the logical-interface-policer statement at the [edit firewall filter name term name then policer] hierarchy level.

Example: Applying Aggregate Policers

Configure two logical interface policers: aggregate_police1 and aggregate_police2. Apply aggregate_police1 to IPv4 and IPv6 traffic received on logical interface fe-0/0/0.0. Apply aggregate_police2 to CCC and MPLS traffic received on logical interface fe-0/0/0.0. This configuration causes the software to create only one instance of aggregate_police1 and one instance of aggregate_police2.

Apply aggregate_police1 to IPv4 and IPv6 traffic received on another logical interface fe-0/0/0.1. This configuration causes the software to create a new instance of aggregate_police1, one that applies to unit 0 and another that applies to unit 1.

[edit firewall]
policer aggregate_police1 {
logical-interface-policer;
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 500k;
}
then {
discard;
}
}
policer aggregate_police2 {
logical-interface-policer;
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 200k;
}
then {
discard;
}
}
[edit interfaces fe-0/0/0]
unit 0 {
family inet {
policer {
input aggregate_police1;
}
}
family inet6 {
policer {
input aggregate_police1;
}
}
family ccc {
policer {
input aggregate_police2;
}
}
family mpls {
policer {
input aggregate_police2;
}
}
}
unit 1 {
family inet {
policer {
input aggregate_police1;
}
}
family inet6 {
policer {
input aggregate_police1;
}
}
}
[Contents] [Prev] [Next] [Index] [Report an Error]

Copyright © 2009, Juniper Networks, Inc. All rights reserved. Trademark Notice.