Home / Certification / Juniper / Rate limit traffic per destination IP on Junos

Rate limit traffic per destination IP on Junos

You can easily rate limit traffic per destination IP address in Junos. We will go through an easy process on how to perform such a task by creating prefix-list, policer and firewall filter. We will have a look at the theoretical background and run a simple test.

Rate limiting the traffic based on IP address can be useful in several situations. If you have a link with limited bandwidth, you don’t want to push more traffic that it can handle otherwise you would have packet drops. Another situation is when you have a SLA with your provider, if you send more traffic you’d probably get an higher bill since you are exceeding the agreed bandwidth.

 

Rate Limit Traffic – The Theory

1 – Create a prefix-list

The key point is configuring convenient filter specific traffic policer that can be created within policy configuration. I strongly recommend (and even for the test lab) to work with prefix-lists. They will help us to realize what’s the root point of rate limit traffic scenario and they are easy to comprehend and easy to update. By creating prefix-list, we basically create an object (list of IP addresses) that can be inserted anywhere in our configuration on the go. If you want to become a skilled Network Engineer, make sure you are familiar with prefix-lists.

 

2 – Create a traffic policer

Once we create prefix-list and use proper naming convention, that’s easy to remember, we follow by creating a policer. Policers enable you to control the maximum rate of IP traffic sent or received on a device interface. The policer type we will use in this lab is called the ‘Bandwidth Policer’. There are just few main parameters that we need to consider when creating one to rate limit traffic, so let’s go to Junos configuration mode to have a look:

[email protected]JunOS-LAB1# set firewall policer rate-test if-exceeding ?
bandwidth-limit     Bandwidth limit (8000..100000000000 bits per second)
bandwidth-percent   Bandwidth limit in percentage (1..100 percent)
burst-size-limit    Burst size limit (1500..100000000000 bytes)

Bandwidth-limit and bandwidth-percent values are we can say pretty straight forward values, but the burst-size-limit can be a bit confusing. Juniper says:

Bytes—Burst-size limit in bytes: The minimum recommended value is the maximum transmission unit (MTU) of the IP packets being policed. You can specify the value either as a complete decimal number or as a decimal number followed by the abbreviation k (1000), m (1,000,000), or g (1,000,000,000). Range: 1500 through 100,000,000,000

This can still be kind of confusing. However referring to the JNCIA study guide, the maximum burst-size-limit is suggested by TAC engineers to be equal to amount of traffic that possibly can get through an interface (in bytes) in 5 milliseconds. So the minimum value is 1500 (suggested MTU size) and the maximum value suggested by TAC engineers is dependent on the specific interface. (For a gigabit interface it’s recommended to use 625k burst-size-limit, feel free to calculate yourself).

Not to mention that there are certain limitations in regards of bandwidth-limit and burst-size-limit combinations. Juniper doesn’t allow you to make mistakes and if you set it too low, it will calculate its own values or apply the preset minimum.

 

3 – Create firewall filter

When we have a prefix list and a traffic policer ready, then there are just few small steps to finalize it all. We create a firewall filter to check if the destination IP matches our prefix list and if it does, we will police that by a single statement.

 

4 – Apply firewall filter to the interface

When the firewall filter is ready, it’s going to be applied to an outgoing interface.

Rate Limit Traffic – The Lab

Let’s consider the following scenario:

Advertisement

Rate limit traffic lab scenario

I tried to make it very simple, so I have just two MX routers in a lab. When we rate limit per destination IP address, we usually want to do it as close to the source as possible anyway.

On JunOS-LAB2, there are only loopback addresses configured and also IP address on the ge-1/0/0.0 interface.

On JunOS-LAB1, that’s where is all other configuration happening.

 

1 – Create a prefix-list

I want to rate limit the whole 192.168.20.0/24 subnet, while 192.168.10.0/24 will be left untouched:

[email protected]JunOS-LAB1# set policy-options prefix-list rate-limit-dest 192.168.20.0/24
[email protected]JunOS-LAB1# show policy-options prefix-list rate-limit-dest
192.168.0.0/24;

2 – Create a policer

I want to do a simple ping test from one MX router to another, therefore I need to set the values correctly to be able to limit/discard ICMP traffic:

[email protected]JunOS-LAB1# set firewall policer rate-test if-exceeding bandwidth-limit 1m
[email protected]JunOS-LAB1# set firewall policer rate-test if-exceeding burst-size-limit 15k
[email protected]JunOS-LAB1# set firewall policer rate-test then discard
[email protected]JunOS-LAB1# show firewall policer rate-test
if-exceeding {
   bandwidth-limit 1m;
   burst-size-limit 15k;
}
then discard;

3 – Create firewall filter

Firewall filter is named dest-rate and it checks for destination IP address and if there’s a match it polices the traffic, but if not there’s a final ACCEPT ALL rule!

[email protected]JunOS-LAB1# set firewall family inet filter dest-rate term 1 from destination-prefix-list rate-limit-dest
[email protected]JunOS-LAB1# set firewall family inet filter dest-rate term 1 then policer rate-test
[email protected]JunOS-LAB1# set firewall family inet filter dest-rate term 2 then accept
[email protected]JunOS-LAB1# run show configuration firewall family inet filter dest-rate
term 1 {
   from {
       destination-prefix-list {
           rate-limit-dest;
       }
   }
   then policer rate-test;
}
term 2 {
   then accept;
}

4 – Apply firewall filter to the interface

We will apply the filter to outgoing traffic from LAB1 to LAB2:

[email protected]JunOS-LAB1#set interfaces ge-0/0/1 unit 0 family inet filter output dest-rate

Another thing we might want to do is to configure a static route towards destination IPs on LAB1, so that our LAB1 router knows how to reach destination IP addresses:

set routing-options static route 192.168.10.0/24 next-hop 10.10.10.2
set routing-options static route 192.168.20.0/24 next-hop 10.10.10.2

Rate Limit Traffic – Testing

To test the configuration, we execute a ping repeated 1000 times passing through the rate limited interface 192.168.20.0/24 :

[email protected]JunOS-LAB1# ping 192.168.20.1 count 1000 rapid
PING 192.168.20.1 (192.168.20.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
***Output omitted**
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!ping: sendto: Operation canceled
.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

— 192.168.20.1 ping statistics —
1000 packets transmitted, 999 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.356/0.547/37.995/1.345 ms

As we can see the ping test, we have transmitted 1000 packets and received 999. It seems like we have lost packet on the way (can be seen as ‘ping: sendto: Operation canceled’ in our output), but in reality it was our policer working as expected:

[email protected]JunOS-LAB1> show firewall filter dest-rate
Filter: dest-rate
Policers:
Name                                    Bytes              Packets
rate-limit-dest                         84                    1 << We got a hit!

When we run the pings towards 192.168.10.1, it’s not being limited at all. Feel free to change the prefix list to meet your requirements, it’s just an easy amendment to the configuration presented above. Enjoy and have fun!

Advertisement
Rate limit traffic per destination IP on Junos
5 (100%)

About Milan Zapletal

I am an open-minded network engineer with 5+ years of experience with passion for learning and technology in general and I enjoy networking and network automation. GNS3 early contributor and fan.

Leave a Reply

Your email address will not be published. Required fields are marked *