Juniper Traffic Policing is another application of Firewall Filter that allows you to rate limit the traffic instead of just accepting or dropping it.
Juniper Traffic Policing Fundamental
This is the firewall filter building block that we used in the previous section to accept or drop some traffic at the data plane.
If you remember, in addition to accepting or rejecting traffic, we have the option to limit traffic rate, which means that we limit traffic to a specific rate so it doesn’t overload the bandwidth. It is especially useful for bulk and junk traffic.
To limit the rate of the traffic, there are two parameters to be configured.
The first option is the bandwidth rate in bps (bits per second). For example, when you configure to limit the rate of a given traffic to 2 Mbps (Mbit per second) to ensure it doesn’t consume all of the bandwidth. if it excceded, however for a short time, it can disrupt delay-sensitive applications like voice and video.
The second option is burst size limit. Some traffic sends traffic in bursts. This means that they do not necessarily exceed the average limit rate, but consume the entire capacity of the interface link for a very short time. With burst-size-limit option, you can limit how much time a traffic can consume the entire capacity of the interface link which is configured in Bytes and not in bits.
burst limit size concept and example
Suppose the interface link speed is 100 Mbps and you want to limit the bandwidth to 2 Mbps. Also, you don’t want to allow a given traffic to be sent in bursts in more than 50ms.
As you know, applications that send traffic in bursts consume the entire capacity of the link. If you want to limit burst of a certain traffic to 50ms, then you have to configure the burst-limit-size to 625 kilo Bytes as it is calculated in the figure.
Juniper Traffic Policing Configuration Example Overview
This is a traffic policing configuration example from juniper documents.
In the first step, a policer with the name of ‘p1’ is configured in firewall section. The bandwidth is limited to 400kbps and burst-size-limit is configured as 100 kilo Bytes.
Any traffic exceeding the policy will be discarded.
In the next step, policer “p1” is applied to the first term of a firewall filter with the name of “rate-limit-subnet”. This term matches traffic with the source of 192.100.1.0/24.
In other words, in this example, the traffic rate with the source 192.100.1.0/24 is limited to 400 kbps, and if it exceeds the policy, extra traffic will be dropped.
The second term, permit any other traffic. if you remember, by default, all traffic are discarded by firewall filter if they don’t match any terms. So this rule helps other traffic not to be discarded.
Juniper Traffic Policing Configuration Example
Now we will implement a sample Traffic Policing in vSRX devices.
Traffic Policing Topology review
This is the topology that we are going to apply the Traffic Policing.
There are two vSRX devices connected to each other through ge-0/0/0 interface with IP subnet 10.10.10.0/24. Each vSRX devices has a loopback interface. Loopback interface connected to vSRX1 has the IP address of 172.16.1.1/24 and loopback interface connected to vSRX2 has the IP address of 172.16.2.1/24.
Routing between these two devices is already configured in previous sections and loopback interfaces are now reachable over the link connecting two vSRX devices to each other.
In this example we want to configure a very simple Traffic Policing to limit the rate of ICMP traffic from the source 172.16.1.1 to the destination 172.16.2.1. all other traffic will be permitted.
We write the Traffic Policing in vSRX2 and apply it to the ge-0/0/0 interface and in the incoming direction.
As you noticed, this example is exactly the same as the previous example, the only difference is that instead of discarding traffic in the first rule, we’re going to limit the rate of the traffic.
Juniper Traffic Policing configuration
This is the configuration that I have already prepared to configure in vSRX2.
!!! vSRX2
set firewall policer p1 if-exceeding bandwidth-limit 200k
set firewall policer p1 if-exceeding burst-size-limit 100k
set firewall policer p1 then discard
set firewall family inet filter FILTER2 term limit-ICMP from source-address 172.16.1.1/32
set firewall family inet filter FILTER2 term limit-ICMP from destination-address 172.16.2.1/32
set firewall family inet filter FILTER2 term limit-ICMP from protocol icmp
set firewall family inet filter FILTER2 term limit-ICMP then policer p1
set firewall family inet filter FILTER2 term PERMIT-ALL then accept
set interfaces ge-0/0/0 unit 0 family inet filter input FILTER2
!
!
!
rayka@vSRX2# show | compare
[edit interfaces ge-0/0/0 unit 0 family inet filter]
- input FILTER1;
+ input FILTER2;
[edit firewall family inet]
+ filter FILTER2 {
+ term limit-ICMP {
+ from {
+ source-address {
+ 172.16.1.1/32;
+ }
+ destination-address {
+ 172.16.2.1/32;
+ }
+ protocol icmp;
+ }
+ then policer p1;
+ }
+ term PERMIT-ALL {
+ then accept;
+ }
+ }
[edit firewall]
+ policer p1 {
+ if-exceeding {
+ bandwidth-limit 200k;
+ burst-size-limit 100k;
+ }
+ then discard;At first we configure a policer with the name of “p1” to limit the rate of the traffic to 200kbps and also limit the burst size to 100 kilo Bytes. Any traffic that exceed this policy will be discarded.
Then we configure a filter with the name of “FILTER2” . it has two terms, “limit-ICMP” and “PERMIT-ALL”.
In the first term, “limit-ICMP”, we limit the rate of ICMP traffic from vSRX1 loopback interfaces with to the destination vSRX2 loopback interface to 200kbps.
In the second term. “PERMIT-ALL”, we permit every other traffic.
The firewall filter, “FILTER2” is applied in incoming direction of interface, ge-0/0/0 in vSRX2 router.
After applying the configuration, to see the result of the configuration, we send ping traffic from 172.16.1.1 to 172.16.2.1 once with default size and then with big size ping packets.
vSRX1> ping 172.16.2.1 source 172.16.1.1
PING 172.16.2.1 (172.16.2.1): 56 data bytes
64 bytes from 172.16.2.1: icmp_seq=0 ttl=64 time=1.556 ms
64 bytes from 172.16.2.1: icmp_seq=1 ttl=64 time=1.548 ms
64 bytes from 172.16.2.1: icmp_seq=2 ttl=64 time=1.439 ms
64 bytes from 172.16.2.1: icmp_seq=3 ttl=64 time=1.639 ms
64 bytes from 172.16.2.1: icmp_seq=4 ttl=64 time=2.219 ms
^C
--- 172.16.2.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.439/1.680/2.219/0.277 ms
rayka@vSRX1> ping 172.16.2.1 source 172.16.1.1 size 30000
PING 172.16.2.1 (172.16.2.1): 30000 data bytes
30008 bytes from 172.16.2.1: icmp_seq=0 ttl=64 time=17.668 ms
30008 bytes from 172.16.2.1: icmp_seq=1 ttl=64 time=15.807 ms
30008 bytes from 172.16.2.1: icmp_seq=2 ttl=64 time=15.928 ms
30008 bytes from 172.16.2.1: icmp_seq=3 ttl=64 time=15.338 ms
30008 bytes from 172.16.2.1: icmp_seq=4 ttl=64 time=15.966 ms
30008 bytes from 172.16.2.1: icmp_seq=5 ttl=64 time=16.230 ms
^C
--- 172.16.2.1 ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max/stddev = 15.338/16.156/17.668/0.727 ms
rayka@vSRX1> ping 172.16.2.1 source 172.16.1.1 size 50000
PING 172.16.2.1 (172.16.2.1): 50000 data bytes
50008 bytes from 172.16.2.1: icmp_seq=0 ttl=64 time=26.474 ms
50008 bytes from 172.16.2.1: icmp_seq=1 ttl=64 time=35.004 ms
50008 bytes from 172.16.2.1: icmp_seq=2 ttl=64 time=26.517 ms
^C
--- 172.16.2.1 ping statistics ---
14 packets transmitted, 3 packets received, 78% packet loss
round-trip min/avg/max/stddev = 26.474/29.332/35.004/4.011 msAs you can see, as we increase the size of ping packets, response time will be increased until the extra traffic are discarded..