Application QoS
AppQoS enable you to identify and control access to specific applications and provides the granularity of the stateful firewall rule base to match and enforce quality of service (QoS) at the application layer. For more information, see the following topics:
Understanding Application Quality of Service (AppQoS)
The application quality of service (AppQoS) feature expands the capability of Junos OS class of service (CoS) to include marking DSCP values based on Layer-7 application types, honoring application-based traffic through loss priority settings, and controlling transfer rates on egress PICs based on Layer-7 application types.
There are four ways to mark DSCP values on the security device:
IDP attack action-based DSCP rewriters
Layer 7 application-based DSCP rewriters
ALG-based DSCP rewriters
Firewall filter-based DSCP rewriters
IDP remarking is conducted at the ingress port based on IDP rules. Application remarking is conducted at the egress port based on application rules. Interface-based remarking also occurs at the egress port based on firewall filter rules. (See the Class of Service User Guide (Security Devices) for a detailed description of Junos OS CoS features.)
The remarking decisions of these three rewriters can be different. If a packet triggers all three, the method that takes precedence is based on how deep into the packet content the match is conducted. IDP remarking has precedence over application remarking which has precedence over interface-based remarking.
If a packet triggers both AppQoS and ALG-based DSCP rewriters, then AppQoS takes precedence over ALG-based DSCP rewriters.
The AppQoS DSCP rewriter conveys a packet’s quality of service through both the forwarding class and a loss priority. The AppQoS rate-limiting parameters control the transmission speed and volume for its associated queues.
- Benefit of Application QoS
- Unique Forwarding Classes and Queue Assignments
- Application-Aware DSCP Code-Point and Loss Priority Settings
- Rate Limiters and Profiles
- Rate-Limiter Assignment
- Rate-Limiter Action
- AppQoS Security Policy Configuration
Benefit of Application QoS
AppQoS provides the ability to prioritize and meter the application traffic to provide better service to business-critical or high-priority application traffic.
Unique Forwarding Classes and Queue Assignments
The forwarding class provides three functions:
Groups packets with like characteristics
Assigns output queues
Resolves conflicts with existing Junos OS firewall filter-based rewriters
Unique forwarding class names protect AppQoS remarking from being overwritten by interface-based rewrite rules. A firewall filter-based rewriter remarks a packet’s DSCP value if the packet’s forwarding class matches a class defined specifically for this rewriter. If the packet’s forwarding class does not match any of the firewall filter-based rewriter’s classes, the DSCP value is not remarked. To protect AppQoS values from being overwritten, therefore, use forwarding class names that are unknown to the firewall filter-based rewriter.
Each forwarding class is assigned to an egress queue that provides the appropriate degree of enhanced or standard processing. Many forwarding classes can be assigned to a single queue. Therefore, any queues defined for the device can be used by IDP, AppQoS, and firewall filter-based rewriters. It is the forwarding class name, not the queue, that distinguishes the transmission priority. (See the Class of Service User Guide (Security Devices) for information about configuring queues and schedulers.)
For SRX5400, SRX5600, and SRX5800 devices, the AppQoS forwarding class names and queue
assignments are defined with the class-of-service CLI configuration
command:
[edit class-of-service] user@host# set forwarding-classes class forwarding-class-name queue-num queue-number
For SRX300, SRX320, SRX340, SRX345, SRX380, SRX550M, SRX1500, SRX4100, SRX4200, and SRX4600
devices and vSRX Virtual Firewall instances, the
AppQoS forwarding class names and queue
assignments are defined with the
class-of-service CLI
configuration command:
[edit class-of-service] user@host# set forwarding-classes queue queue-number forwarding-class-name
Application-Aware DSCP Code-Point and Loss Priority Settings
For AppQoS, traffic is grouped based on rules that associate a defined forwarding class with selected applications. The match criteria for the rule includes one or more applications. When traffic from a matching application encounters the rule, the rule action sets the forwarding class, and remarks the DSCP value and loss priority to values appropriate for the application.
A Differentiated Services (DiffServ) code point (DSCP) value is specified in the rule either by a 6-bit bitmap value or by a user-defined or default alias. Table 1 provides a list of Junos OS default DSCP alias names and bitmap values.
Alias |
Bit Value |
|---|---|
ef |
101110 |
af11 |
001010 |
af12 |
001100 |
af13 |
001110 |
af21 |
010010 |
af22 |
010100 |
af23 |
010110 |
af31 |
011010 |
af32 |
011100 |
af33 |
011110 |
af41 |
100010 |
af42 |
100100 |
af43 |
100110 |
be |
000000 |
cs1 |
001000 |
cs2 |
010000 |
cs3 |
011000 |
cs4 |
100000 |
cs5 |
101000 |
nc1/cs6 |
110000 |
nc2/cs7 |
111000 |
See Default CoS Values and Aliases for more details.
The queue’s scheduler uses the loss priority to control packet discard during periods of congestion by associating drop profiles with particular loss priority values. (See the Class of Service User Guide (Security Devices) for information about configuring queues and schedulers.)
The rule applies a loss priority to the traffic groups. A high loss priority means a high probability that the packet could be dropped during a period of congestion. Four levels of loss priority are available:
highmedium-highmedium-lowlow
The rule set is defined in the class-of-service application-traffic-control configuration command:
[edit class-of-service] user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 match application application-name application-name ... user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 match application-group application-group-name application-group-name ... user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 then forwarding-class fc-name user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 then dscp-code-point bitmap user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 then loss-priority loss-pri-value
Rate Limiters and Profiles
When congestion occurs, AppQoS implements rate limiting on all egress PICs on the device. If packets exceed the assigned limitations, they are dropped. Rate limiters maintain a consistent level of throughput and packet loss sensitivity for different classes of traffic. All egress PICs employ the same rate-limiting scheme.
The total bandwidth of a PIC is about 10 Gbps. Rate-limiter hardware for the PIC can provision up to 2 Gbps. Therefore, the upper bandwidth limit for rate limiting is 231 bps.
A rate-limiter profile defines the limitations. It is a unique
combination of bandwidth-limit and burst-size-limit specifications. The bandwidth-limit defines the maximum
number of kilobits per second that can traverse the port. The burst-size-limit defines the maximum number of bytes that can
traverse the port in a single burst. The burst-size-limit reduces starvation of lower priority traffic by ensuring a finite
size for each burst.
AppQoS allows up to 16 profiles and up to 1000 rate limiters per device. Multiple rate limiters can use the same profile. In the following example, five rate limiters are defined using two profiles:
Rate Limiter Name |
Profile |
|
|---|---|---|
bandwidth-limit |
burst-size-limit |
|
limiter-1 |
200 |
26000 |
limiter-2 |
200 |
26000 |
limiter-3 |
200 |
26000 |
limiter-4 |
400 |
52000 |
limiter-5 |
400 |
52000 |
Rate limiters are defined with the class-of-service application-traffic-control configuration command.
[edit class-of-service] user@host# set application-traffic-control rate-limiters rate-limiter-name bandwidth-limit value-in-Kbps burst-rate-limit value-in-bytes
Rate-Limiter Assignment
Rate limiters are applied in rules based on the application
of the traffic. Two rate limiters are applied for each session: client-to-server and server-to-client. This usage
allows traffic in each direction to be provisioned separately.
The processing of traffic bandwidth by rate limiters is done at the packet level regardless of the direction of traffic. For example: Consider a case where you have only one rate limiter of 10G configured, if the ingress and egress traffic is from the same line card, then the throughput (maximum traffic of both ingress and egress directions combined) can only be up to 10G and not 20G. However, if the device has IOC support (in case of SRX5000 line devices and SRX4600 devices) and ingress traffic is through one IOC and egress traffic through other IOC, then with a single rate-limiter of 10G configured, you can expect a throughput of 20G.
Different AppQoS rules within the same rule set can share a rate limiter. In this case, the applications of those rules share the same bandwidth. There are no limitations on the number of rules in one rule set that can assign the same rate limiter.
The following examples show how the rate limiters defined in the preceding section could be assigned. For instance, a rule set could reuse a rate limiter in several rules and in one or both flow directions:
rule-set-1
rule-1A
client-to-server limiter-1
server-to-client limiter-1
rule-1B
client-to-server limiter-1
server-to-client limiter-1
If the same profiles are needed in several rule sets, a sufficient
number of rate limiters needs to be defined specifying the same bandwidth-limit and burst-size-limit. The two rule
sets in the following example implement the same profiles by assigning
different, but comparable, rate limiters.
rule-set-2
rule-2A
client-to-server limiter-2
server-to-client limiter-2
rule-2B
client-to-server limiter-2
server-to-client limiter-4
rule-set-3
rule-3A
client-to-server limiter-3
server-to-client limiter-3
rule-3B
client-to-server limiter-3
server-to-client limiter-5
A rate limiter is applied using the edit class-of-service
application-traffic-control rule-sets command in the same way
that a forwarding class, DSCP value, and loss priority are set.
[edit class-of-service] user@host# set application-traffic-control rule-sets rule-set-name rule rule-name1 then rate-limit client-to-server rate-limiter1 server-to-client rate-limiter2
If AppQoS and firewall filter-based rate limiting are both implemented on the egress PIC, both are taken into consideration. AppQoS rate limiting is considered first. Firewall filter-based rate limiting occurs after that.
If packets are dropped from a PIC, the device does not send notifications to the client or the server. The upper-level applications on the client and the server devices are responsible for retransmission and error handling.
Rate-Limiter Action
Based on the type of security device, AppQoS rules can be configured with different rate-limiter actions:
Discard
When this option is selected, the out-of-profile packets are just dropped.
This is the default action type and need not be configured.
This option is supported on all SRX Series Firewalls.
Loss-priority-high
When this option is selected , it elevates the loss priority to maximum. In other words, it is a delayed drop; that is, the discard decision is taken at the egress output queue level. If there is no congestion, it allows the traffic even with maximum loss priority. But if congestion occurs, it drop these maximum loss priority packets first.
This option must be configured within the AppQoS rule (to override the default action) using the following command:
[edit] user@host# set class-of-service application-traffic-control rule-sets rset-01 rule r1 then rate-limit loss-priority-high
This option is supported only on for SRX300, SRX320, SRX340, SRX345 devices.
AppQoS Security Policy Configuration
The AppQoS rule set can be implemented in an existing policy or a specific application policy.
[edit security policies from-zone zone-name to-zone zone-name]
user@host# set policy policy-name match source-address IP-address
user@host# set policy policy-name match destination-address IP-address
user@host# set policy policy-name match application application-name application-name
user@host# set policy policy-name then permit application-services application-traffic-control rule-set app-rule-set-name
See Also
Example: Configuring Application Quality of Service
This example shows how to enable AppQoS prioritization and rate limiting within a policy.
Requirements
No special configuration beyond device initialization is required before configuring this feature.
Overview
In this example, AppQoS is implemented so that FTP applications are restricted to a level below the specified throughput while other applications are transmitted at a more conventional speed and loss priority level.
Configuration
Procedure
To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.
set class-of-service forwarding-classes queue 4 my-app-fc set class-of-service application-traffic-control rate-limiters test-rl bandwidth-limit 100 set class-of-service application-traffic-control rate-limiters test-rl burst-size-limit 13000 set class-of-service application-traffic-control rate-limiters test-r2 bandwidth-limit 200 set class-of-service application-traffic-control rate-limiters test-r2 burst-size-limit 26000 set class-of-service application-traffic-control rule-sets app-test1 rule 0 match application junos:FTP set class-of-service application-traffic-control rule-sets app-test1 rule 0 match application junos:HTTP set class-of-service application-traffic-control rule-sets app-test1 rule 0 then forwarding-class my-app-fc set class-of-service application-traffic-control rule-sets app-test1 rule 0 then dscp-code-point af22 set class-of-service application-traffic-control rule-sets app-test1 rule 0 then loss-priority low set class-of-service application-traffic-control rule-sets app-test1 rule 0 then rate-limit client-to-server test-r2 set class-of-service application-traffic-control rule-sets app-test1 rule 0 then rate-limit server-to-client test-r2 set class-of-service application-traffic-control rule-sets app-test1 rule 0 then log set class-of-service application-traffic-control rule-sets app-test1 rule 1 match application-any set class-of-service application-traffic-control rule-sets app-test1 rule 1 then rate-limit client-to-server test-r2 set class-of-service application-traffic-control rule-sets app-test1 rule 1 then rate-limit server-to-client test-r2 set class-of-service application-traffic-control rule-sets app-test1 rule 1 then log set security policies from-zone trust to-zone untrust policy p1 match source-address any set security policies from-zone trust to-zone untrust policy p1 match destination-address any set security policies from-zone trust to-zone untrust policy p1 match application any set security policies from-zone trust to-zone untrust policy p1 then permit application-services application-traffic-control rule-set ftp-test1
Step-by-Step Procedure
To configure an AppQoS on your security device:
-
Define one or more forwarding classes dedicated to AppQoS marking. In this example, a single forwarding class, my-app-fc, is defined and assigned to queue 4.
[edit] user@host# set class-of-service forwarding-classes queue 4 my-app-fc
For SRX5400, SRX5600, and SRX5800 devices, use the
set class-of-service forwarding-classes class my-app-fc queue 4command.Juniper Networks devices support eight queues (0 to 7). The default queues 0 through 3 are assigned to default forwarding classes. Queues 4 through 7 have no default assignments to FCs and are not mapped. To use queues 4 through 7, you must create custom FC names and map them to the queues. For more details, see Forwarding Classes Overview.
Define rate limiters. In this example, two rate limiters are defined.
[edit] user@host# set class-of-service application-traffic-control rate-limiters test-rl bandwidth-limit 100 user@host# set class-of-service application-traffic-control rate-limiters test-rl burst-size-limit 13000 user@host# set class-of-service application-traffic-control rate-limiters test-r2 bandwidth-limit 200 user@host# set class-of-service application-traffic-control rate-limiters test-r2 burst-size-limit 26000
For SRX5400, SRX5600, and SRX5800 devices, you can define up to 1000 rate limiters for a device, but only 16 profiles (unique bandwidth-limit and burst-size-limit combinations).
-
Define AppQos rules and application match criteria.
[edit] user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 match application junos:FTP user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 match application junos:HTTP user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then forwarding-class my-app-fc user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then dscp-code-point af22 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then loss-priority low user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then rate-limit client-to-server test-r1 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then rate-limit server-to-client test-r1 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then log
In this example, when a match is made, the packet is marked with the forwarding class my-app-fc, the DSCP value of af22, and a loss priority of low. We've assigned same rate limiter on both the directions.
You can assign a rate limiter to one or both traffic directions in a single rule. You can also assign a same rate limiter to other rules within a rule set. However, you cannot assign a same rate limiter to different rule set.
-
Define another rule to handle application packets that did not match the previous rule. In this example, a second and final rule applies to all remaining applications.
[edit] user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 1 match application-any user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 1 then rate-limit client-to-server test-r2 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 1 then rate-limit server-to-client test-r2 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 1 then log
-
Add the AppQoS setting to the security policy.
[edit] user@host# set security policies from-zone trust to-zone untrust policy p1 match source-address any user@host# set security policies from-zone trust to-zone untrust policy p1 match destination-address any user@host# set security policies from-zone trust to-zone untrust policy p1 match application any user@host# set security policies from-zone trust to-zone untrust policy p1 then permit application-services application-traffic-control rule-set app-test1
Results
From configuration mode, confirm your policy configuration by entering the show security
policies and show class-of-service command. If the output
does not display the intended configuration, repeat the instructions in this example to
correct the configuration.
For brevity, this show command output includes only
the configuration that is relevant to this example. Any other configuration
on the system has been replaced with ellipses (...).
...
policy p1 {
match {
source-address any;
destination-address any;
application any;
}
then {
permit {
application-services {
application-traffic-control {
rule-set app-test1
}
}
}
}
}
...
user@host# show class-of-service
forwarding-classes {
queue 4 my-app-fc;
}
application-traffic-control {
rate-limiters test-rl {
bandwidth-limit 100;
burst-size-limit 13000;
}
rate-limiters test-r2 {
bandwidth-limit 200;
burst-size-limit 26000;
}
rule-sets app-test1 {
rule 0 {
match {
application [junos:FTP junos:HTTP];
}
then {
forwarding-class my-app-fc;
dscp-code-point af22;
loss-priority low;
rate-limit {
client-to-server test-r2;
server-to-client test-r2;
}
log;
}
}
rule 1 {
match {
application-any;
}
then {
rate-limit {
client-to-server test-r2;
server-to-client test-r2;
}
log;
}
}
}
}
If you are done configuring the device, enter commit from configuration mode.
Verification
Confirm that the configuration is working properly.
- Verifying Flow Session Configuration
- Verifying Session Statistics
- Verifying Rate-Limiter Statistics
- Verifying Rule Statistics
Verifying Flow Session Configuration
Purpose
Verify that AppQoS is enabled.
Action
From operational mode, enter the show security
flow session application-traffic-control extensive command.
user@host> show security flow session application-traffic-control extensive
Session ID: 3729, Status: Normal, State: Active
Flag: 0x40
Policy name: p1
Source NAT pool: Null
Dynamic application: junos:FTP
Application traffic control rule-set: app-test1, Rule: rule0
Maximum timeout: 300, Current timeout: 276
Session State: Valid
Start time: 18292, Duration: 603536
In: 192.0.2.1/1 --> 203.0.113.0/1;pim,
Interface: reth1.0,
Session token: 0x1c0, Flag: 0x0x21
Route: 0x0, Gateway: 192.0.2.4, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 21043, Bytes: 1136322
Out: 203.0.113.0/1 --> 192.0.2.0/1;pim,
Interface: .local..0,
Session token: 0x80, Flag: 0x0x30
Route: 0xfffd0000, Gateway: 192.0.2.0, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 0, Bytes: 0
Meaning
The entry for application traffic control identifies the rule set and rule of the current session.
Verifying Session Statistics
Purpose
Verify that AppQoS session statistics are being accumulated at each egress node.
Action
From operational mode, enter the show class-of-service
application-traffic-control counter command.
user@host> show class-of-service application-traffic-control counter pic: 2/1 Counter type Value Sessions processed 300 Sessions marked 200 Sessions honored 0 Sessions rate limited 100 Client-to-server flows rate limited 100 Server-to-client flows rate limited 100 pic: 2/0 Counter type Value Sessions processed 400 Sessions marked 300 Sessions honored 0 Sessions rate limited 200 Client-to-server flows rate limited 200 Server-to-client flows rate limited 200
Meaning
The AppQoS statistics are maintained only if application-traffic-control service is enabled. The number of sessions processed, marked, and honored show that sessions are being directed based on configured AppQoS features. The rate-limiting statistics count the number of directional session flows that have been rate limited.
Verifying Rate-Limiter Statistics
Purpose
Verify that bandwidth is being limited as expected when the FTP application is encountered.
Action
From operational mode, enter the show class-of-service
application-traffic-control statistics rate-limiter command.
user@host> show class-of-service application-traffic-control statistics rate-limiter pic: 2/1 Ruleset Application Client-to-server Rate(kbps) Server-to-client Rate(kbps) app-test1 HTTP test-r2 200 test-r2 200 app-test1 HTTP test-r2 200 test-r2 200 appp–test1 FTP test-r1 100 test-r1 100
Meaning
Real-time application bandwidth-limit information for each PIC is displayed by rule set. This command provides an indication of the applications being rate limited and the profile being applied.
Verifying Rule Statistics
Purpose
Verify that the rule matches the rule statistics.
Action
From operational mode, enter the show class-of-service
application-traffic-control statistics rule command.
user@host>show class-of-service application-traffic-control statistics rule pic: 2/1 Ruleset Rule Hits app-test1 0 100 app-test1 1 200 ... pic: 2/0 Ruleset Rule Hits app-test1 0 100 app-test1 1 200
Meaning
This command provides information on the number of (session) hits for a rule under each rule set.
Application Quality of Service Support for Unified Policies
Starting in Junos OS Release 18.2R1, SRX Series Firewalls and vSRX Virtual Firewall instances support unified policies, allowing granular control and enforcement of dynamic Layer 7 applications within the traditional security policy.
Unified policies are the security policies that enable you to use dynamic applications as part of the existing 5-tuple or 6-tuple (5-tuple with a user firewall) match conditions to detect application changes over time.
Application quality of service (AppQoS) is supported when the security device is configured with unified policies. You can configure a default AppQoS rule set to manage unified policy conflicts if multiple security policies match the traffic.
AppQoS rule sets are included in the unified policy to implement
application-aware quality-of-service control. You can configure a
rule set with rules under the application-traffic-control option, and attach the AppQoS rule set to a unified security policy
as an application service. If the traffic matches the specified dynamic
application and the policy action is permit, the application-aware
quality of service is applied.
Note the following AppQoS functionality in unified policies:
Upgrading from traditional security policy to a unified policy—In a unified policy, when you configure the
dynamic-applicationoption asnone, the AppQoS rule set is applied during the security policy match and the AppQoS looks for the corresponding rule for the identified traffic. This is the same behavior for AppQoS functionality in Junos OS releases prior to Release 18.2R1.AppQoS rule with a unified policy—In the application traffic control configuration, the AppQoS rule set is configured with the match condition as
application-anyand in the unified policy, a specific dynamic application is used as the match condition, then, the AppQoS functionality works according to the rule in the unified policy.
- Understanding Default Application Quality of Service Rule Set for Unified Policies
- Default Application Quality of Service Rule Set In Different Scenarios
- Limitation of AppQoS with Unified Policies
Understanding Default Application Quality of Service Rule Set for Unified Policies
You can configure an AppQoS default rule set to manage security policy conflicts.
The initial policy lookup phase occurs prior to identifying a dynamic application. If there are multiple policies present in the potential policy list that contain different AppQoS rule sets, then the security device applies the default AppQoS rule set until a more explicit match has occurred.
You can set an AppQoS as a default AppQoS rule set under the edit security ngfw hierarchy level. The default AppQoS rule
set is leveraged from one of the existing AppQoS rule sets, which
are configured under the [edit class-of-service application-traffic-control] hierarchy level.
Table 2 summarizes the usage of the default AppQoS rule set under different scenarios in a unified policy.
Application Identification Status |
AppQoS Rule Set Usage |
Action |
|---|---|---|
No security policy conflict. |
The AppQoS rule set under the [ |
AppQoS is applied as in the AppQoS rule set. |
Security policy conflict and conflicting polices have distinct AppQoS rule sets. |
The default AppQoS rule set is not configured or is not found. |
Session is ignored because the default AppQoS profile is not configured. As a result, even if the final matched policy in the policy conflict scenario has an AppQoS rule set, this rule set is not applied. We recommend configuring a default AppQoS rule set to manage security policy conflicts. |
The default AppQoS rule set is configured. |
AppQoS is applied as in the default AppQoS rule set. |
|
Final application is identified |
The matching security policy has an AppQoS rule set, which is same as the default AppQoS rule set. |
AppQoS is applied as in the default AppQoS rule set. |
The matching security policy does not have an AppQoS rule set. |
Default AppQoS rule set is not applied and AppQoS is not applied for the session. |
|
The Matching security policy has an AppQoS rule set different from the default AppQoS rule set, which is already applied. |
Default AppQoS rule set remains as the default AppQoS rule set. |
When a default AppQoS rule set is applied on the traffic and the final security policy has a different AppQoS rule set, in such cases switching from the default AppQoS rule set to the AppQoS rule set in the final security policy is not supported.
Default Application Quality of Service Rule Set In Different Scenarios
The following links are to examples that discuss the default AppQoS rule sets in different scenarios:
Table 3 shows different AppQoS rule sets that are configured for unified policies with dynamic applications as the match condition.
Security Policy |
Source Zone |
Source IP Address |
Destination Zone |
Destination IP Address |
Port Number |
Protocol |
Dynamic Application |
Service |
AppQoS Rule Set |
|---|---|---|---|---|---|---|---|---|---|
Policy-P1 |
S1 |
50.1.1.1 |
D1 |
Any |
Any |
Any |
AppQoS |
AppQoS-1 |
|
Policy-P2 |
S1 |
50.1.1.1 |
D1 |
Any |
Any |
Any |
AppQoS |
AppQoS-2 |
|
Policy-P3 |
S1 |
50.1.1.1 |
D1 |
Any |
Any |
Any |
YouTube |
AppQoS |
AppQoS-3 |
In this example, any AppQoS rule sets (AppQoS-1, AppQoS-2, AppQoS-3)
can be configured as a default AppQoS rule set under the [security
ngfw] hierarchy level. It is not necessary for a default rule
set to be part of a security policy configuration. Any AppQoS rule
set under the [edit class-of-service application-traffic-control] hierarchy level can be assigned as the default AppQoS rule set.
- No Policy Conflict—All Policies Have the Same AppQoS Rule Set
- No Policy Conflict—All Policies Have the Same AppQoS Rule Set and the Final Policy Has No AppQoS Rule Set
- Policy Conflict—No AppQoS Rule Set is Configured for the Final Policy
- Policy Conflict—Default AppQoS Rule Set and a Different AppQoS Rule Set for the Final Policy
No Policy Conflict—All Policies Have the Same AppQoS Rule Set
All matching policies have the same AppQoS rule set as shown in Table 4.
Security Policy |
Source Zone |
Source IP Address |
Destination Zone |
Destination IP Address |
Port Number |
Protocol |
Dynamic Application |
Service |
AppQoS Rule Set |
|---|---|---|---|---|---|---|---|---|---|
Policy-P1 |
S1 |
Any |
D1 |
Any |
Any |
Any |
AppQoS |
AppQoS-1 |
|
Policy-P2 |
S1 |
Any |
D1 |
Any |
Any |
Any |
AppQoS |
AppQoS-1 |
In this scenario, the policies Policy-P1 and Policy-P2 have the same AppQoS rule set; that is, AppQoS-1. The rule set AppQoS-1 is applied. Policy-P3 is not configured in this scenario.
If you have configured the rule set AppQoS-2 as the default rule set, it is not applied. That’s because there is no conflict in the AppQoS rule sets in the conflicted policies (Policy-P1 and Policy-P2).
No Policy Conflict—All Policies Have the Same AppQoS Rule Set and the Final Policy Has No AppQoS Rule Set
All matching policies have the same AppQoS rule set as shown in Table 5 and the final policy has no AppQoS rule set.
Security Policy |
Source Zone |
Source IP Address |
Destination Zone |
Destination IP Address |
Port Number |
Protocol |
Dynamic Application |
Service |
AppQoS Rule Set |
|---|---|---|---|---|---|---|---|---|---|
Policy-P1 |
S1 |
Any |
D1 |
Any |
Any |
Any |
AppQoS |
AppQoS-1 |
|
Policy-P2 |
S1 |
Any |
D1 |
Any |
Any |
Any |
AppQoS |
AppQoS-1 |
|
Policy-P3 |
S1 |
50.1.1.1 |
D1 |
Any |
Any |
Any |
YouTube |
Other |
None |
In this scenario, both Policy-P1 and Policy-P2 have the same AppQoS rule set, that is, AppQoS-1. In this case, the rule set AppQoS-1 is applied.
When the final policy Policy-P3 is matched, AppQoS ignores the session, because the AppQoS rule set is not configured for Policy-P3.
If the final security policy does not have any AppQoS rule set, then AppQoS is not applied on the traffic. All AppQoS settings that are applied in the prematch stage are reverted to the original values.
Policy Conflict—No AppQoS Rule Set is Configured for the Final Policy
The default AppQoS rule set (in this scenario AppQoS-1) is applied during the potential policy match as shown in Table 6. The final policy Policy-P3 has no AppQoS rule set.
Security Policy |
Source Zone |
Source IP Address |
Destination Zone |
Destination IP Address |
Port Number |
Protocol |
Dynamic Application |
Service |
AppQoS Rule Set |
|---|---|---|---|---|---|---|---|---|---|
Policy-P1 |
S1 |
50.1.1.1 |
D1 |
Any |
Any |
Any |
AppQoS |
AppQoS-1 |
|
Policy-P2 |
S1 |
50.1.1.1 |
D1 |
Any |
Any |
Any |
AppQoS |
AppQoS-2 |
|
Policy-P3 |
S1 |
50.1.1.1 |
D1 |
Any |
Any |
Any |
YouTube |
Other |
NA |
AppQoS ignores the session if the final matching policy Policy-P3 is applied.
If the final security policy does not have any AppQoS rule set, then AppQoS is not applied on the traffic. In this case, all AppQoS settings that are applied in the prematch stage are reverted to the original values.
Policy Conflict—Default AppQoS Rule Set and a Different AppQoS Rule Set for the Final Policy
The rule set AppQoS-1 is configured as a default rule set and is applied when the final application is not yet identified. The final policy Policy-P3 has a different AppQoS rule set (AppQoS-3) as shown in Table 7.
Security Policy |
Source Zone |
Source IP Address |
Destination Zone |
Destination IP Address |
Port Number |
Protocol |
Dynamic Application |
Service |
AppQoS Rule Set |
|---|---|---|---|---|---|---|---|---|---|
Policy-P1 |
S1 |
50.1.1.1 |
D1 |
Any |
Any |
Any |
AppQoS |
AppQoS-1 |
|
Policy-P2 |
S1 |
50.1.1.1 |
D1 |
Any |
Any |
Any |
AppQoS |
AppQoS-2 |
|
Policy-P3 |
S1 |
50.1.1.1 |
D1 |
Any |
Any |
Any |
YouTube |
AppQoS |
AppQoS-3 |
When the final application is identified, the policy Policy-P3 is matched and applied. In this case, the rule set AppQoS-3 is not applied. Instead the rule set AppQoS-1 is applied as the default rule set and remains as the default rule set.
Limitation of AppQoS with Unified Policies
When a security policy is applied to the matching traffic, the AppQoS rule set is applied to the permitted traffic. If the security policy and the applied AppQoS rule set have different dynamic applications, then a conflict might occur as shown in the following example:
user@host#set class-of-service application-traffic-control rule-sets AQ2 rule 1 match application junos:GOOGLEuser@host#set class-of-service application-traffic-control rule-sets AQ2 rule 1 then forwarding-class network-controluser@host#set class-of-service application-traffic-control rule-sets AQ2 rule 1 then dscp-code-point 110001user@host#set class-of-service application-traffic-control rule-sets AQ2 rule 1 then loss-priority high
user@host#set security policies from-zone trust to-zone untrust policy 1 match source-address anyuser@host#set security policies from-zone trust to-zone untrust policy 1 match destination-address anyuser@host#set security policies from-zone trust to-zone untrust policy 1 match application anyuser@host#set security policies from-zone trust to-zone untrust policy 1 match dynamic-application junos:FTPuser@host#set security policies from-zone trust to-zone untrust policy 1 then permit application-services application-traffic-control rule-set AQ2
In this example, the application traffic control rule is configured for junos:GOOGLE and the security policy match condition for the dynamic application is junos: FTP. In such cases, conflicts might occur when the final policy is applied.
See Also
Example: Configuring Application Quality of Service with Unified Policy
This example shows how to enable application quality of service (AppQoS) within a unified policy to provide prioritization and rate limiting for the traffic.
Requirements
This example uses the following hardware and software components:
SRX Series Firewall running Junos OS Release 18.2R1 and later. This configuration example is tested for Junos OS Release 18.2R1.
No special configuration beyond device initialization is required before configuring this feature.
Overview
In this example, you configure an AppQoS rule set and invoke AppQoS as an application service in the security policy for the Facebook application.
You define a default AppQoS rule set under the [edit security
ngfw] hierarchy level to manage security policy conflicts, if
any.
Configuration
Procedure
Step-by-Step Procedure
To configure AppQoS with a unified policy:
Define an AppQoS rule set.
[edit] user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 match application junos:FACEBOOK-APP user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 then forwarding-class fc-appqos loss-priority medium-low dscp-code-point 101110 log user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 then rate-limit client-to-server Ratelimit1 user@host# set class-of-service application-traffic-control rate-limiters Ratelimit1 bandwidth-limit 1000
Configure a default AppQoS rule set. Select the rule set
RS1that is created under the application traffic control as the default AppQoS rule set.[edit] user@host# set security ngfw default-profile application-traffic-control rule-set RS1
Associate the class-of-service rule set to the unified policy.
[edit] user@host# set security policies from-zone untrust to-zone trust policy from_internet match source-address any user@host# set security policies from-zone untrust to-zone trust policy from_internet match destination-address any user@host# set security policies from-zone untrust to-zone trust policy from_internet match application any user@host# set security policies from-zone untrust to-zone trust policy from_internet match dynamic-application junos:FACEBOOK-APP user@host# set security policies from-zone untrust to-zone trust policy from_internet then permit application-services application-traffic-control rule-set RS1
Results
From configuration mode, confirm your policy configuration
by entering the show security policies command. If the
output does not display the intended configuration, repeat the instructions
in this example to correct the configuration.
For brevity, this show command output includes only
the configuration that is relevant to this example. Any other configuration
on the system has been replaced with ellipses (...).
...
policies {
from-zone trust to-zone untrust {
policy permit-all {
match {
source-address any;
destination-address any;
application any;
dynamic-application junos:FACEBOOK-APP;
}
then {
permit {
application-services {
application-traffic-control {
rule-set RS1;
}
}
}
}
}
}
}
...
ngfw {
default-profile {
application-traffic-control {
rule-set RS1;
}
}
}
If you are done configuring the device, enter commit from configuration mode.
Verification
Confirm that the configuration is working properly.
Verifying Flow Session Configuration
Purpose
Display AppQoS session statistics.
Action
From operational mode, enter the show class-of-service
application-traffic-control counter command.
Sample Output
command-name
pic: 0/0 Counter type Value Sessions processed 2 Sessions marked 1 Sessions honored 1 Sessions rate limited 1 Client-to-server flows rate limited 0 Server-to-client flows rate limited 1 Session default ruleset hit 1 Session ignored no default ruleset 1
Meaning
The output displays the number of sessions processed, marked, and honored. The rate-limiting statistics count the number of directional session flows that have been rate limited.
Verifying Rule Statistics
Purpose
Display the AppQoS rule statistics.
Action
From operational mode, enter the show class-of-service
application-traffic-control statistics rule command.
user@host>show class-of-service application-traffic-control statistics rule
pic: 0/0
Ruleset Rule Hits
RS1 1 1
Meaning
The output provides information on the number of sessions matched for the rule under each AppQoS rule set.