Example: Using Policers to Manage Oversubscription
You might want to use a policer when an interface is oversubscribed and you want to control what will happen if congestion occurs. For example, you might have servers connected to a switch as listed in Table 1.
Server Type |
Connection |
IP Address |
|---|---|---|
Network application server |
1-gigabit interface |
10.0.0.1 |
Authentication server |
1-gigabit interface |
10.0.0.2 |
Database server |
10-gigabit interface |
10.0.0.3 |
In this example, users access services provided by the network application server, which requests information from the database server as appropriate. When it receives a request from a user, the network application server first contacts the authentication server to verify the user’s credentials. When a user is authenticated and the network application server provides the requested service, all the packets sent from the database server to the application server must transit the 1-Gigabit Ethernet interface connected to the application server twice—once on ingress to the application server and again on egress to the user.
The sequence of events for a user session is as follows:
A user connects to the application server and requests a service.
The application server requests the user’s credentials and relays them to the authentication server.
If the authentication server verifies the credentials, the application server initiates the requested service.
The application server requests the files necessary to meet the user’s request from the database server.
The database server sends the requested files to the application server.
The application server includes the requested files in its response to the user.
Traffic from the database server to the application server might congest the 1-gigabit interface to which that the application server is connected. This congestion might prevent the server from responding to requests from users and creating new sessions for them. You can use policing to make sure that this does not occur.
To create this firewall configuration, perform the following steps on the database server:
Create a policer to drop traffic from the database server to the application server if it exceeds certain limits:
[edit firewall] user@switch# set policer Database-Egress-Policer if-exceeding bandwidth-limit 400 burst-size-limit 500m user@switch# set policer Database-Egress-Policer then discard
Create a filter to examine traffic from the database server to the application server:
[edit firewall] user@switch# edit family inet filter Database-Egress-Filter
Configure the filter to apply the policer to traffic egressing the database server and destined for the application server:
[edit firewall family inet filter Database-Egress-Filter] user@switch# set term term-1 from destination-address 10.0.0.1 user@switch# set term term-1 then policer Database-Egress-Policer
If required, configure a term to allow traffic from the database server to other destinations (otherwise the traffic will be dropped by the implicit deny statement):
[edit firewall family inet filter Database-Egress-Filter] user@switch# set term term-2 then accept
Note that omitting a
fromstatement causes the term to match all packets, which is the desired behavior.Install the egress filter as an output filter on the database server interface that is connected the application server:
[edit interfaces] user@switch# set xe-0/0/3 unit 0 family inet filter output Database-Egress-Filter
Here is how the final configuration would appear:
firewall {
policer Database-Egress-Policer {
if-exceeding {
bandwidth-limit 400;
burst-size-limit 500m;
}
then discard;
}
family inet {
filter Database-Egress-Filter {
term term-1 {
from {
destination-address {
10.0.0.1/24;
}
}
then policer Database-Egress-Policer;
}
term term-2 { # If required, include this term so that traffic from the database server to other destinations is allowed.
then accept;
}
}
}
]