You can use FTD to limit the rate of network traffic after an access control rule allows or trusts the traffic. An FTD device, however, does not regulate the rate of any particular traffic when a Prefilter policy applies the Fastpath action on them. Limiting the rate of traffic is a way to manage the bandwidth of a network and to ensure quality of service (QoS) for business-critical applications. This chapter discusses the steps in configuring a QoS policy on an FTD device and to verify its operations.
There are multiple ways to enable QoS in a network. FTD implements the traffic policing mechanism to limit the rate of traffic. With this method, FTD drops excessive traffic when the traffic rate reaches a predefined limit. As of this writing, FTD does not support traffic shaping, where excessive traffic is queued in a buffer—rather than being dropped—for later transmission.
Figure 15-1 illustrates the crests and troughs of the traffic pattern when an FTD device rate limits traffic using the policing method.
Figure 15-2 shows a typical graph illustrating traffic that is rate limited by the shaping mechanism.
At any given time, an FTD device can have only one active QoS policy. However, you can add multiple QoS rules within a QoS policy. Each QoS rule must be associated with a source interface and a destination interface, where both of them have to be routed interfaces. You can set separate upload and download speed limits for the traffic that match the conditions of a QoS rule. Furthermore, FTD allows you to define the QoS rule conditions based on advanced networking characteristics, such as network address, port number, application, URL, and user identity.
The Firepower engine evaluates a QoS rule and classifies traffic. When a packet matches with a QoS rule, the Firepower engine sends the ID of the matching rule to the Firewall engine. The firewall engine limits the rate of individual flows based on the download and upload speed limits defined on a QoS rule. You must enable logging at the end of a connection to view QoS-related information.
Figure 15-3 shows a workflow of the QoS feature on the Firepower System. You use the FMC to configure and apply a QoS policy and view any QoS events. FTD ensures that the traffic conforms to the QoS rule.
As of this writing, FTD supports up to 32 QoS rules within a single QoS policy. FTD allows you to add different rule conditions for different network segments that are connected to different FTD interfaces. However, you should enable a QoS rule as close to the source as possible to ensure that the traffic does not consume the network and system resources more than it should.
Figure 15-4 shows an example of a typical network where FTD enables different QoS rules through the same QoS policy. Traffic is originated from different source networks and rate limited by different QoS rules.
Each interface participating in a QoS policy must be in Routed Mode and associated with an interface object. You cannot apply a QoS policy to an interface that is in Inline Mode, Passive Mode, or Switched Mode. (Read Chapter 8, “Firepower Deployment in Routed Mode,” to learn about Routed Mode.)
Figure 15-5 shows the configuration of the FTD interface. Both of the participating interfaces are in Routed Mode (assigned with IP addresses) and associated with security zones (interface objects).
Follow these steps to create a QoS policy and add a rule within it:
Step 1. Navigate to the Devices > QoS page. FTD does not provide a default policy, so click the New Policy button to create one (see Figure 15-6). The New Policy window appears.
Step 2. Give a name to the new policy and add a target device to which you want to apply this policy. Click Save to save the changes. The QoS policy editor page appears.
Step 3. As shown in Figure 15-7, select a device for the new QoS policy you want to create and click Add to Policy. Then click Save.
Step 4. On the QoS policy editor page, notice that there is a link to the Policy Assignments option that you can use to associate a new managed device with this policy. Click the Add Rule button (see Figure 15-8). The Add Rule window appears, and in it you can define a rule condition.
Step 5. Give a name to the new QoS rule. Using the Apply QoS On dropdown, define where you want to rate limit traffic. In addition, on the Interface Objects tab, add a source and destination interface to the rule condition.
Tip
You should rate limit traffic as close to the source as possible to ensure that the traffic rate does not go beyond an entitled limit throughout the network.
Figure 15-9 shows a new QoS rule, named Rate Limiting Rule, that is applied on Interfaces in Source Interface Objects. This rule limits rates only when the traffic originates from Inside_Zone interface and is destined for Outside_Zone.
Step 6. Enter a desired traffic limit for the interface. FTD allows you to enter upload and download limits separately. If you do not enter a value, FTD supports the maximum throughput for that physical interface.
Table 15-1 provides a conversion chart for commonly used traffic rates. When you enter a traffic limit, FTD considers the value as megabit per second (Mbps), not megabytes per second (MBps). The highlighted rows of this table are used in the configuration example in this chapter.
Megabits per Second |
Megabytes per Second |
1 Mbps |
0.125 MBps |
4 Mbps |
0.5 MBps |
8 Mbps |
1 MBps |
10 Mbps |
1.25 MBps |
16 Mbps |
2 MBps |
40 Mbps |
5 MBps |
80 Mbps |
10 MBps |
100 Mbps |
12.5 MBps |
Note
FTD supports the rate limit 0.008 to 1000 Mbps per interface. If you want to allocate below 0.008 Mbps to any hosts, it implies that those hosts are not important to you. You may just want to consider blocking them by using an access rule or a prefilter rule.
Figure 15-10 shows the traffic limits for download and upload flows, 40 Mbps and 8 Mbps, respectively.
Step 7. Optionally, add a precise rate limiting condition based on any additional networking characteristics, such as network address, port number, application, URL, user identity, and so on.
Step 8. Once you outline a rule condition, click the OK button to create the QoS rule. The browser returns to the QoS policy editor page. Click the Save button to preserve the QoS rules you have created.
Figure 15-11 shows the custom QoS rule you have just created.
At this point, you can click the Deploy button to activate a QoS rule, but by default, FTD does not generate a log when a QoS rule triggers. A QoS policy does not offer an option for logging. If you want to view QoS-related statistics for any specific connection, you must identify the associated access rule that triggers the QoS rule and enable logging at the end of that connection. To accomplish that, you have to edit the access control policy and redeploy the revised policy.
Figure 15-12 shows the steps to enable logging. Because this exercise does not use any custom access rules, you can enable logging for the default action to generate QoS data when a connection hits the default action.
After you successfully deploy a QoS policy, you can verify the deployment status from the FTD CLI. Example 15-1 shows confirmation of the QoS policy configurations and the interface where the policy is deployed.
! To view the rate-limiting settings:
> show running-config policy-map
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
no tcp-inspection
policy-map type inspect ip-options UM_STATIC_IP_OPTIONS_MAP
parameters
eool action allow
nop action allow
router-alert action allow
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect icmp
inspect icmp error
inspect dcerpc
inspect ip-options UM_STATIC_IP_OPTIONS_MAP
class class-default
set connection advanced-options UM_STATIC_TCP_MAP
policy-map policy_map_INSIDE_INTERFACE
match flow-rule qos 268442624
police input 8000000 250000
police output 40000000 1250000
!
>
! To determine where a policy is applied:
> show running-config service-policy
service-policy global_policy global
service-policy policy_map_INSIDE_INTERFACE interface INSIDE_INTERFACE
>
Now, you can verify the impact of the QoS policy you have deployed. First, download a file from the server to a client system. Then upload a file from the client PC to the server. You should notice two different traffic rates.
Figure 15-13 shows the topology of a simple deployment that you can use to verify the download and upload speeds through an FTD device.
Figure 15-14 shows the download of a software image file. FTD enforces the download rate within 5 MBps.
Figure 15-15 shows the upload of a PDF file. FTD regulates the upload rate below 1 MBps.
Both of these transfers—download of the ISO and upload of the PDF—are initiated by a host that is located at the inside zone. Therefore, the traffic matches the QoS rule Rate Limiting Rule, and FTD regulates the traffic rate. However, if the connection is initiated by an outside system, it does not match the QoS rule condition. Hence, the QoS policy does not limit the traffic rate; the source and destination should be able to utilize the full capacity of the FTD interface bandwidth.
If you have enabled logging for the connections that also match your QoS rule conditions, you can view the QoS-related statistics in the Connection Events page. Here are the steps to view them:
Step 1. Navigate to the Analysis > Connections > Events page.
Step 2. Select the Connection Events as the table view.
Step 3. Expand the Search Constraints arrow on the left.
Step 4. Select the necessary QoS-related data points.
Figure 15-16 shows two sets of connection events. The bottom two connections are originated by an inside client; they match the conditions in the Rate Limiting Rule, and rate is limited. However, the top two connections are not rate limited because they are initiated by an outside system.
Example 15-2 demonstrates the actions of a QoS policy on an FTD device. This example provides two commands that you can use to determine any drop due to a rate limiting rule during a file transfer.
! Record on the service policy statistics
> show service-policy police
Interface INSIDE_INTERFACE:
Service-policy: policy_map_INSIDE_INTERFACE
Flow-rule QoS id: 268442624
Input police Interface INSIDE_INTERFACE:
cir 8000000 bps, bc 250000 bytes
conformed 334152 packets, 21168506 bytes; actions: transmit
exceeded 0 packets, 0 bytes; actions: drop
conformed 473456 bps, exceed 0 bps
Output police Interface INSIDE_INTERFACE:
cir 40000000 bps, bc 1250000 bytes
conformed 1129736 packets, 1618239735 bytes; actions: transmit
exceeded 127629 packets, 182986654 bytes; actions: drop
conformed 36194128 bps, exceed 4092744 bps
>
! Statistics of the Accelerated Security Path (ASP) counts
> show asp drop
Frame drop:
No route to host (no-route) 79
TCP packet SEQ past window (tcp-seq-past-win) 1
Output QoS rate exceeded (rate-exceeded) 127629
Slowpath security checks failed (sp-security-failed) 4
FP L2 rule drop (l2_acl) 18
Last clearing: 00:51:31 UTC Apr 10 2017 by enable_1
Flow drop:
Last clearing: 00:51:31 UTC Apr 10 2017 by enable_1
>
Example 15-3 reveals the connections that are rate limited by a QoS rule. The flags associated with a connection confirm whether it is going through a Firepower deep packet inspection process.
! You can use a QoS Rule ID to view any associated active connections.
> show conn flow-rule qos 268442624
1 in use, 4 most used
TCP OUTSIDE_INTERFACE 172.16.1.2:80 INSIDE_INTERFACE 192.168.1.2:47072, idle
0:00:00, bytes 1199375239, flags UIO N
>
! To determine the meaning of each flag, you can use the "detail" keyword. For exam-
ple, the flag 'N' confirms that the Firepower Snort engine inspects the connection.
> show conn detail
1 in use, 4 most used
Flags: A - awaiting responder ACK to SYN, a - awaiting initiator ACK to SYN,
b - TCP state-bypass or nailed,
C - CTIQBE media, c - cluster centralized,
D - DNS, d - dump, E - outside back connection, e - semi-distributed,
F - initiator FIN, f - responder FIN,
G - group, g - MGCP, H - H.323, h - H.225.0, I - initiator data,
i - incomplete, J - GTP, j - GTP data, K - GTP t3-response
k - Skinny media, M - SMTP data, m - SIP media, N - inspected by Snort, n - GUP
O - responder data, P - inside back connection,
q - SQL*Net data, R - initiator acknowledged FIN,
R - UDP SUNRPC, r - responder acknowledged FIN,
T - SIP, t - SIP transient, U - up,
V - VPN orphan, v - M3UA W - WAAS,
w - secondary domain backup,
X - inspected by service module,
x - per session, Y - director stub flow, y - backup stub flow,
Z - Scansafe redirection, z - forwarding stub flow
TCP OUTSIDE_INTERFACE: 172.16.1.2/80 INSIDE_INTERFACE: 192.168.1.2/47072,
flags UIO N, qos-rule-id 268442624, idle 0s, uptime 4m42s, timeout 1h0m, bytes
1529246551
>
Example 15-4 shows the real-time debug messages generated by the firewall and Firepower engines, due to the match of a QoS rule (ID: 268442624).
! Debug messages in the ASA Firewall Engine:
> system support firewall-engine-debug
Please specify an IP protocol: tcp
Please specify a client IP address:
Please specify a client port:
Please specify a server IP address:
Please specify a server port:
Monitoring firewall engine debug messages
192.168.1.2-47072 > 172.16.1.2-80 6 AS 1 I 0 New session
192.168.1.2-47072 > 172.16.1.2-80 6 AS 1 I 0 using HW or preset rule order 2, id
268434432 action Allow and prefilter rule 0
192.168.1.2-47072 > 172.16.1.2-80 6 AS 1 I 0 allow action
192.168.1.2-47072 > 172.16.1.2-80 6 AS 1 I 0 Starting with minimum 0, id 0 and
SrcZone first with zones 2 -> 1, geo 0(0) -> 0, vlan 0, sgt tag: untagged, svc 0,
payload 0, client 0, misc 0, user 9999997, url , xff
192.168.1.2-47072 > 172.16.1.2-80 6 AS 1 I 0 match rule order 1, id 268442624 action
Rate Limit
192.168.1.2-47072 > 172.16.1.2-80 6 AS 1 I 0 QoS policy match status (match found),
match action (Rate Limit), QoS rule id (268442624)
192.168.1.2-47072 > 172.16.1.2-80 6 AS 1 I 0 Got end of flow event from hardware
with flags 40000001
^C
Caught interrupt signal
Exiting.
>
! Debug messages in the Firepower Snort Engine:
> debug snort event
>
Flow from 192.168.1.2/47072 to 172.16.1.2/80 matched qos_rule_id 268442624 flag
Regular flow
RL pkts = 0, RL Bytes = 0, Rv RL pkts = 153693, Rv RL Byt = 220395762, Qos_on_Src 1
> undebug all
>
The statistics in these examples were captured when a client PC was downloading a large ISO file from the server using a web browser. You could perform similar analysis on uploaded traffic. Before you begin uploading a file from the client PC to the server, you can run the following commands to reset the counters.
> clear service-policy interface INSIDE_INTERFACE
> clear asp drop
In this chapter, you have learned the steps to configure QoS policy on an FTD device. This chapter also provides an overview to the common rate limiting mechanisms and how an FTD device implements QoS. Finally, this chapter provides the command-line tools you can use to verify the operation of QoS policies in FTD.
1. Which of the following statements is correct?
a. The Firepower engine not only evaluates but also enforces a QoS rule.
b. Snort rate limits traffic as soon as it receives it.
c. The ASA firewall engine enforces the actual rate limit.
d. All of the above.
2. Which step is necessary to view any QoS-related events?
a. In a QoS policy, enable logging at the beginning of a connection.
b. In a QoS policy, enable logging at the end of a connection.
c. In an access control policy, enable logging at the beginning of a connection.
d. In an access control policy, enable logging at the end of a connection.
3. To limit the download rate to 50 MBps, which value should you enter in a QoS rule?
a. 5
b. 50
c. 400
d. 500
4. Which of the following commands confirms whether traffic is rate limited by FTD?
a. show service-policy police
b. show conn detail
c. show asp drop
d. All of the above
3.144.84.175