As explained in a section of the classification queue, the filter is categorized with the packet and placed in the corresponding child queue. These filters are called within the queue rules of the classification.
Here is the classifier (part) that we can use:
Fw
Judge the data packet by how it is tagged by the firewall. If you don't want to learn TC's filter syntax, this is a shortcut. For details, see the chapter on queues.
U32
Depending on the fields in the packet, such as the source IP address, and so on.
Route
is judged by which route the packet will be routed.
RSVP, RSVP6
Based on the RSVP of the packet. Only for your own network, the Internet does not comply with RSVP.
Tcindex
For Dsmark queue rules, see related chapters.
In general, there are always a number of ways to categorize packets, ultimately depending on which system you prefer to use.
Classifiers generally accept a few parameters, in order to facilitate our listing:
Kyoto
The protocol accepted by this classifier. Generally you only accept IP data. Necessary parameters.
Parent
Which handle is attached to this classifier. The handle must be a class that already exists. Necessary parameters.
Prio
The priority value of this classifier. Priority with low priority value.
Handle
For different filters, it has different meanings.
All subsequent sections assume that you are trying to reshape the flow of hosta. And assume that the root class is configured with 1: And you want to send the selected packets to 1:1 classes.
1. U32 classifier
The U32 classifier is the most advanced filter in the current implementation. All are based on a hash table, so you can still be robust when you have a lot of filters.
The simplest form of a U32 filter is a series of records, each containing two parts: a selector and an action. The following selector is used to match the IP packet and perform its specified action once a successful match is made. The simplest action is to send packets to a specific class queue.
The TC command line used to configure the filter consists of three parts: a filter description, a selector, and an action. A filter can be defined as follows:
TC Filter Add Dev IF [Kyoto PROTO]
[(preference|priority) Prio]
[Parent CBQ]
In the above line, the Kyoto field describes the protocol that the filter will match. We will only discuss the IP protocol. The Preference field (which can also be replaced by priority) sets the filter's precedence. This is important because you may have several filters with different priorities. Each filter list is scanned in the order entered, and the list of lower priority values (higher preference values) is processed first. The parent field defines the top of the CBQ that the filter belongs to (for example, 1:0).
The options described above apply to all filters, not just to U32.