How to Configure Rate Limiting on Juniper Devices

Applying Rate Limiting to Ports on a Juniper Device (Policer Example)

If you need to limit bandwidth for servers connected to specific ports on a Juniper device, you can achieve this by creating a firewall policer and applying it through a filter to the chosen interface. The steps below show a clear example for implementing a 40 Mbps limit using Junos-style configuration commands and explain the purpose of each setting to help you plan and verify the change safely.

Step-by-step example: create a 40 Mbps policer

Start by defining a policer that enforces a maximum bandwidth and a burst size. In this example, the policer is named 40m-limit and will discard packets when the configured limit is exceeded.

root@SW1# set firewall policer 40m-limit if-exceeding bandwidth-limit 40m

root@SW1# set firewall policer 40m-limit if-exceeding burst-size-limit 256k

root@SW1# set firewall policer 40m-limit then discard

Create a filter that uses the policer

After creating the policer, place it into a filter term so it can be attached to an interface. The filter defines where and how the policer is applied. In this simple example, the filter is named testfilter and includes a term called policer that invokes the policer you defined.

root@SW1# set firewall family inet filter testfilter term policer then policer 40m-limit

Apply the filter to the interface

With the filter configured, attach it to the interface you want to limit. Filters can be applied in the input or output direction; here the filter is applied to incoming traffic on interface ge-0/0/15.

root@SW1# set interfaces ge-0/0/15 unit 0 family inet filter input testfilter

Commit the configuration

Once the policer, filter, and interface assignment are in place, commit the configuration to make the changes active.

root@SW1# commit

What each parameter does

– bandwidth-limit 40m: Sets the sustained rate limit to 40 megabits per second.
– burst-size-limit 256k: Defines how much traffic can be sent in a short burst above the sustained rate before enforcement begins; this helps accommodate brief traffic spikes.
– then discard: Specifies that packets which exceed the policer limits are dropped. Other actions can be configured depending on policy needs (for example, marking or counting).

Operational considerations and tips

– Direction: Decide whether to apply the policer on input or output based on where you want to enforce the limit (ingress policing versus egress shaping scenarios). The example uses input.
– Testing: Apply policers in a controlled environment or during a maintenance window if working in production. Verify the impact on connected servers before broad deployment.
– Monitoring: After committing, monitor traffic and policer behavior to ensure the limit behaves as expected. Use your device’s monitoring tools and counters to observe dropped packets, bursts, and overall bandwidth usage.
– Naming and documentation: Use clear names for policers and filters to keep configuration easy to understand and maintain. Document why a limit was applied and which hosts or ports it affects.
– Adjustments: If you need to change the limit or burst size, update the policer configuration and commit again. To remove the policy, delete the interface filter assignment and the related filter and policer stanzas, then commit.

Example use cases

Rate limiting with policers is useful to prevent a single server or port from consuming excess bandwidth, protect shared uplinks, or enforce service-level limits for tenants or applications. Applying an appropriate burst size can reduce packet loss for short-lived spikes while still capping sustained throughput.

Author: Samed Gül