The following are the high-level steps involved in the configuration and implementation of QoS using Trellix IPS:
Make sure you have deployed Trellix IPSaccording to your requirement. See Trellix Intrusion Prevention System Installation Guide for details.
Make sure you have connected the monitoring ports to the networks that you want to monitor in inline mode. QoS is not applicable to SPAN or tap mode.
Create the rule objects that you plan to use in your QoS rules. For example, identify the IPv4 and IPv6 addresses and address ranges and create the corresponding rule objects. Similarly, verify if rule objects are available for the applications for which you want to provide QoS.
If you plan to use the Host DNS Name rule object, make sure you configure the DNS server details in the Manager. Also, make sure these servers are accessible to the Sensor's management port. If the DNS servers are not accessible, a fault message is raised.
Note
The DNS server details apply to Firewall, QoS, integration with GTI for File Reputation, and NTBA.
If you plan to use user name or user group rule objects, make sure you have integrated the Manager with Trellix Logon Collector version 3.0.11 or above.
If you are using any time-based rule objects, make sure you have configured the Time Zone in the Manager. Time-based rules are implemented using the local time zone of the corresponding Sensor. The pre-configured Time Zone is GMT.
Create the required QoS policies at the corresponding admin domain. When you create a QoS policy, you define the QoS rules separately for DiffServ tagging and VLAN 802.1p tagging.
After you create a QoS policy, you must assign them to the corresponding inline port pairs.
You assign the QoS policies separately for inbound and outbound directions of a port pair.
You can assign only one QoS policy per direction (inbound/outbound) of a port pair.
You can assign a QoS policy to any number of port pairs.
You can assign the same QoS policy to both inbound and outbound directions.
After you complete assigning the QoS policies to the required Sensor resources, do a configuration update. The Sensor assigns the QoS policy to the corresponding Sensor monitoring ports. Consider port pair G1/1-G1/2 with a port speed of 1 Gbps in either direction. Assume G1/1 is connected to the outside network. Then the QoS policy that you assigned to G1/1-G1/2/Outbound is assigned to port G1/1. The QoS policy that you assigned to G1/1-G1/2/Inbound is assigned to port G1/2.
Notes and examples
The important thing to note about QoS is that the policies are applied only to the traffic exiting the port-pair. Consider the example in the previous point. The traffic originating from your inside network is detected at G1/2. The Sensor applies the Firewall, Connection Limiting, Recon, Advanced Malware, and IPS policies assigned to port G1/2 on this traffic but not the QoS policy. The traffic that is allowed to pass through according to these policies reaches G1/1 and about to egress out through G1/1. At this point, the QoS policy assigned to G1/1 is applied on this traffic. Similarly, the traffic from the outside network enters through G1/1 and is subjected to the other IPS features. The QoS policy assigned to G1/2 is applied on this traffic when it exits through G1/2.
.png)
When the Sensor applies a QoS policy, it matches the traffic against the Diff Serv and 802.1p rules simultaneously. That is, it applies the Diff Serv and 802.1p rules in a top-down fashion on the traffic. When a rule matches the traffic, the Sensor does not consider the remaining rules of the same type.
To understand how the DiffServ technique works:
Consider you have created a QoS policy named QoS_Policy. You have made sure you have the required rule objects to create this policy.
Consider port G1/2 which is connected to your inside network. Assume that the port speed of G1/2 is 1 Gbps
To keep it simple, consider the policy QoS_Policy assigned to G1/2.
The first Diff Serv rule is to identify SSL traffic. So, in the Application column, you select the SSL Service rule object. In the Diff Serv Tag column, you specify 60.
The second rule is to identify HTTP traffic. So, in the Application column, you select HTTP service rule object. In the Diff Serv Tag column, you specify 50.
The third rule is to identify FTP traffic. So, in the Application column, you select FTP service rule object. In the Diff Serv Tag column, you specify 40.
Again, to understand how 802.1p tagging works, consider the same example. Assume that the first 802.1p rule is assigned a 802.1p VLAN priority value of 6, the second a 802.1p VLAN priority value of 5, and the third rule a 802.1p VLAN priority value of 4.
The SSL traffic going out through port G1/2 is tagged 60 for DiffServ; tagged with 6 for 802.1p; and restricted to 300 Mbps.
In case of DiffServ and 802.1p, you can specify if you want the Sensor to tag value of zero for unclassified traffic.
Suppose you have specified the DiffServ tag value to be set to zero for unclassified traffic. In our example, there is no DiffServ rule to identify Telnet. So, the Telnet traffic exiting through G1/2 is treated as unclassified. If, for example, this Telnet traffic reaches the Sensor with a DiffServ tag value of 10, then the Sensor tags the Telnet traffic with a zero value, and then passes it on to the external network device for DiffServ categorization.
On the other hand, you have opted for the tag value as seen on the wire. Now the telnet traffic exiting out of G1/2 reaches is sent out with the tag value of 10. That is the Sensor does not alter the tagging.
The user-based rule objects and application-related rule objects work the same way as in the case of Firewall policies. Refer to the Firewall policies section to understand how these features work.
You can view the number of bytes and packets that the Sensor dropped for a specific class of traffic under Traffic Statistics.