Linux Solutions

Welcome to the tutorial guide. The guide will provide a user with guidance and instructions on filtering IPv6 traffic.

A user should know that the Routing Policy Database (RPDB) replaced the IPv4 routing and addressing structure within the Linux Kernel. The IPv6 structure within Linux was implemented outside of this core structure. Although they do share some facilities, the essential RPDB structure does not particpate in or with the IPv6 addressing and routing structures.
Marking IPv6 packets using ip6tables
ip6tables is able to mark a packet and assign a number to it:
# ip6tables -A PREROUTING -i eth0 -t mangle -p tcp -j MARK –mark 1
Please note that this will not help as the packet will not pass through the RPDB structure.
Using the u32 selector to match IPv6 packet
IPv6 is normally encapsulated in a SIT tunnel and transported over IPv4 networks.
The following filter matches all IPv6 encapsulated in IPv4 packets:
# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \
match ip protocol 41 0xff flowid 42:42
A user can assume his/her IPv6 packets get sent out over IPv4 and these packets have no options set. A user could use the following filter to match ICMPv6 in IPv6 in IPv4 with no options. 0×3a (58) is the Next-Header type for ICMPv6.
# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \
match ip protocol 41 0xff \
match u8 0×05 0×0f at 0 \
match u8 0×3a 0xff at 26 \
flowid 42:42
Matching the destination IPv6 address is a bit more work. The following filter matches on the destination address 3ffe:202c:ffff:32:230:4fff:fe08:358d:
# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \
match ip protocol 41 0xff \
match u8 0×05 0×0f at 0 \
match u8 0×3f 0xff at 44 \
match u8 0xfe 0xff at 45 \
match u8 0×20 0xff at 46 \
match u8 0×2c 0xff at 47 \
match u8 0xff 0xff at 48 \
match u8 0xff 0xff at 49 \
match u8 0×00 0xff at 50 \
match u8 0×32 0xff at 51 \
match u8 0×02 0xff at 52 \
match u8 0×30 0xff at 53 \
match u8 0×4f 0xff at 54 \
match u8 0xff 0xff at 55 \
match u8 0xfe 0xff at 56 \
match u8 0×08 0xff at 57 \
match u8 0×35 0xff at 58 \
match u8 0×8d 0xff at 59 \
flowid 10:13
The same technique can be used to match subnets. For example 2001::
# tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \
match ip protocol 41 0xff \
match u8 0×05 0×0f at 0 \
match u8 0×20 0xff at 28 \
match u8 0×01 0xff at 29 \
flowid 10:13

If you followed this advise and guidance then you would have learnt about IPv6 Traffic.

Welcome to the tutorial guide. The guide will provide a user with guidance and instructgions on IMQ. Please note that the Intermediate queueing device is not a qdisc but its usage is tightly bound to qdiscs. Within linux, qdiscs are attached to network devices and everything that is queued to the device is first queued to the qdisc. There are some limitations which are provided:

- Only egress shaping is possible (an ingress qdisc exists, but its possibilities are very limited compared to classful qdiscs).
- A qdisc can only see traffic of one interface, global limitations can’t be placed.
IMQ can solve these limitations. A user can put everything you choose in a qdisc. Specially marked packets get intercepted in netfilter NF_IP_PRE_ROUTING and NF_IP_POST_ROUTING hooks and pass through the qdisc attached to an imq device. An iptables target is used for marking the packets.
This will let a user carry out ingress shaping as he/she can just mark packets coming in from somewhere and/or treat interfaces as classes to set global limits.
Sample configuration
The first thing that might come to mind is use ingress shaping to provide a high guaranteed bandwidth. ;). Please note that the configuration is just like with any other interface:
tc qdisc add dev imq0 root handle 1: htb default 20

tc class add dev imq0 parent 1: classid 1:1 htb rate 2mbit burst 15k

tc class add dev imq0 parent 1:1 classid 1:10 htb rate 1mbit
tc class add dev imq0 parent 1:1 classid 1:20 htb rate 1mbit

tc qdisc add dev imq0 parent 1:10 handle 10: pfifo
tc qdisc add dev imq0 parent 1:20 handle 20: sfq

tc filter add dev imq0 parent 10:0 protocol ip prio 1 u32 match \
ip dst 10.0.0.230/32 flowid 1:10

In this example u32 is used for classification. Other classifiers should work as expected. Next traffic has to be selected and marked to be enqueued to imq0.
iptables -t mangle -A PREROUTING -i eth0 -j IMQ –todev 0

ip link set imq0 up
The IMQ iptables targets is valid in the PREROUTING and POSTROUTING chains of the mangle table. It’s syntax is
IMQ [ –todev n ] n : number of imq device
An ip6tables target is also provided.
Please note traffic is not enqueued when the target is hit but afterwards. The exact location where traffic enters the imq device depends on the direction of the traffic (in/out). These are the predefined netfilter hooks used by iptables:
enum nf_ip_hook_priorities {
NF_IP_PRI_FIRST = INT_MIN,
NF_IP_PRI_CONNTRACK = -200,
NF_IP_PRI_MANGLE = -150,
NF_IP_PRI_NAT_DST = -100,
NF_IP_PRI_FILTER = 0,
NF_IP_PRI_NAT_SRC = 100,
NF_IP_PRI_LAST = INT_MAX,
};
For ingress traffic, imq registers itself with NF_IP_PRI_MANGLE + 1 priority which means packets enter the imq device directly after the mangle PREROUTING chain has been passed.
For egress imq uses NF_IP_PRI_LAST which honours the fact that packets dropped by the filter table won’t occupy bandwidth.

If you followed this tutorial guide then you would have learnt about Intermediate queueing device (IMQ).

Welcome to the tutorial guide. The guide will provide a user with guidance and instructions on hierarchical token bucket.

Hierarchical approach is well suited for setups where a user has a fixed amount of bandwidth which he/she wants to divide for different purposes, giving each purpose a guaranteed bandwidth, with the possibility of specifying how much bandwidth can be borrowed.
HTB is a classful Token Bucket Filter. As a user’s HTB configuration gets more complex, the configuration scales well. With CBQ it is already complex even in simple cases. HTB3 is now part of the official kernel sources, however a user has to get a HTB3 patched version of tc. HTB kernel and userspace parts must be the same major version, or ‘tc’ will not work with HTB.
Sample configuration
Functionally almost identical to the CBQ sample configuration above:

# tc qdisc add dev eth0 root handle 1: htb default 30

# tc class add dev eth0 parent 1: classid 1:1 htb rate 6mbit burst 15k

# tc class add dev eth0 parent 1:1 classid 1:10 htb rate 5mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:20 htb rate 3mbit ceil 6mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 6mbit burst 15k
The author then recommends SFQ for beneath these classes:
# tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
# tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10
# tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10
Add the filters which direct traffic to the right classes:
# U32=”tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32″
# $U32 match ip dport 80 0xffff flowid 1:10
# $U32 match ip sport 25 0xffff flowid 1:20
And that’s it - no unsightly unexplained numbers, no undocumented parameters.
HTB certainly looks wonderful - if 10: and 20: both have their guaranteed bandwidth, and more is left to divide, they borrow in a 5:3 ratio, just as you would expect.
Unclassified traffic gets routed to 30:, which has little bandwidth of its own but can borrow everything that is left over. Because we chose SFQ internally, we get fairness thrown in for free

If you followed the guidance and instructions as provided in this tutorial guide then you would have learnt about Hierarchical Token Bucket (HTB)

Welcome to the tutorial guide. The guide will provide a user with guidance and instructions on load balancing.
If a user has already setup split access then instead of choosing one of the two providers as a users’ default route. Please set up the default route to be a multipath route. In the default kernel this will balance routes over the two providers. It is done as follows.
ip route add default scope global nexthop via $P1 dev $IF1 weight 1 \
nexthop via $P2 dev $IF2 weight 1

This will balance the routes over both providers. Please note that balancing will not be perfect, as it is route based, and routes are cached. This means that routes to often-used sites will always be over the same provider.
If you followed advise and guidance as provided in this tutorial guide then you would have learnt about routing policy database.

Welcome to the tutorial guide. The guide will provide a user with guidance and instructions on split access.
It is good to know that a user can set some symbolic names such as $IF1, $IF2, $IP1, etc. Let’s assume that $IF1 is the name of the first interface and $IF2 the name of the second. A user can then use $IP1 as an IP address associated with $IF1 and $IP2 the IP address associated with $IF2. Now a user can then let $P1 be the IP address of the gateway at Provider 1, and $P2 the IP address of the gateway at provider 2. Finally, let $P1_NET be the IP network $P1 is in, and $P2_NET the IP network $P2 is in.
This will result in two additional routing tables, say T1 and T2. These are added in /etc/iproute2/rt_tables. Now a user can set up routing in these tables as follows:
ip route add $P1_NET dev $IF1 src $IP1 table T1
ip route add default via $P1 table T1
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2

A user can just build a route to the gateway and build a default route via that gateway, as a user would do in the case of a single upstream provider, but put the routes in a separate table per provider.
Now a user can set up the main routing table. It is good to know that that the src arguments ensure the right outgoing IP address is chosen.
ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2

A users preference for default route is:
ip route add default via $P1

After this, a user can set up the routing rules. These actually choose what routing table to route with. Here a user has to ensure that in order to make sure that he or she routes out a given interface if a user already has the corresponding source address:
ip rule add from $IP1 table T1
ip rule add from $IP2 table T2

If a user followed advise and guidance as provided in this tutorial guide then he/she would have learnt about split access.

Welcome to the tutorial guide. The guide will provide a user with guidance and instructions on how to deal with fast massive filtering.

If a user needs thousands of rules because he/she has a lot of clients or computers with different QoS specifications, then a user will note that he/she will note that the kernel spends a lot of time matching all those rules.
By default, all filters reside in one big chain which is matched in descending order of priority. If a user has 1000 rules, then he/she will require 1000 checks. These checks are required in order to determine what to do with a packet.
If a user has 256 chains with four rules then matching will be quicker also, if he/she can divide packets over those 256 chains, so that the right rule will be there.
If a user has 1024 cable modem customers in his/her network, with IP addresses ranging from 1.2.0.0 to 1.2.3.255, and each has to go in another bin, for example ‘lite’, ‘regular’ and ‘premium’. A user will then have 1024 rules like this:
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
1.2.0.0 classid 1:1
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
1.2.0.1 classid 1:1
…
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
1.2.3.254 classid 1:3
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
1.2.3.255 classid 1:2
If a user wants to speed up then he can use the last part of the IP address as a hash key and 256 tables will be obtained. The first table will look like as below:
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
1.2.0.0 classid 1:1
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
1.2.1.0 classid 1:1
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
1.2.2.0 classid 1:3
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
1.2.3.0 classid 1:2
The next table will start as described below:
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
1.2.0.1 classid 1:1
…
In this way, a user will require only four checks.
Please note that configuration is difficult but it is useful by the time a user has many rules. First a user needs to make a filter root, then he/she has to create a table with 256 entries:
# tc filter add dev eth1 parent 1:0 prio 5 protocol ip u32
# tc filter add dev eth1 parent 1:0 prio 5 handle 2: protocol ip u32 divisor 256
A user can now add some rules to entries in the created table:
# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 2:7b: \
match ip src 1.2.0.123 flowid 1:1
# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 2:7b: \
match ip src 1.2.1.123 flowid 1:2
# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 2:7b: \
match ip src 1.2.3.123 flowid 1:3
# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 2:7b: \
match ip src 1.2.4.123 flowid 1:2

This is entry 123, which contains matches for 1.2.0.123, 1.2.1.123, 1.2.2.123, 1.2.3.123, and sends them to 1:1, 1:2, 1:3 and 1:2 respectively. Please note that a user will need to specifiy the hash bucket in hex, 0×7b is 123.
After that a user will then need to create a ‘hashing filter’ that directs traffic to the right entry in the hashing table:
# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 800:: \
match ip src 1.2.0.0/16 \
hashkey mask 0×000000ff at 12 \
link 2:

It is good know what are these numbers. The default hash table is called 800:: and all filtering starts there. Then a user can select the source address, which lives as position 12, 13, 14 and 15 in the IP

A user should note that this is difficult but the good thing about it is that it works in practice and performance is good.
If you have followed this tutorial guide then you would have learnt about dealing with fast massive filtering.

Welcome to the tutorial guide. The guide will provide a user with advise and guidance on filtering commands. Please note that most of the commands presented in this guide will start with this preamble:
# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ..
These are the so called ‘u32′ matches, which can match on ANY part of a packet.
On source/destination address
Source mask ‘match ip src 1.2.3.0/24′, destination mask ‘match ip dst 4.3.2.0/24′. To match a single host, use /32, or omit the mask.
On source/destination port, all IP protocols
Source: ‘match ip sport 80 0xffff’, destination: ‘match ip dport 80 0xffff’
On ip protocol (tcp, udp, icmp, gre, ipsec)
Use the numbers from /etc/protocols, for example, icmp is 1: ‘match ip protocol 1 0xff’.
On fwmark
A user can mark packets with either ipchains or iptables and have that mark survive routing across interfaces. This is really useful to for example only shape traffic on eth1 that came in on eth0. Syntax:
# tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle 6 fw flowid 1:1
Note that this is not a u32 match!
A user can place a mark like this:
# iptables -A PREROUTING -t mangle -i eth0 -j MARK –set-mark 6
The number 6 is arbitrary.
If a user is not interested in understanding the full tc filter syntax, just use iptables, and only learn to select on fwmark.
On the TOS field
To select interactive, minimum delay traffic:
# tc filter add dev ppp0 parent 1:0 protocol ip prio 10 u32 \
match ip tos 0×10 0xff \
flowid 1:4
Use 0×08 0xff for bulk traffic.

If you followed advise and guidance as provided in this tutorial guide then you would have learnt about filtering commands.

Welcome to the tutorial guide. The guide will provide a user with advise and guidance on filtering.
If a user has a PRIO qdisc called ‘10:’ which contains three classes, and he/she wants to assign all traffic from and to port 22 to the highest priority band, the filters would be:
# tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \
ip dport 22 0xffff flowid 10:1
# tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \
ip sport 80 0xffff flowid 10:1
# tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2
Let’s see what does this mean. It means that: attach to eth0, node 10: a priority 1 u32 filter that matches on IP destination port 22 *exactly* and send it to band 10:1. And it then repeats the same for source port 80. The last command says that anything unmatched so far should go to band 10:2, the next-highest priority.
A user needs to add ‘eth0′, or whatever his/her interface is called, because each interface has a unique namespace of handles.
If a user wants to select on an IP address, thene he/she needs to use this:
# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 \
match ip dst 4.3.2.1/32 flowid 10:1
# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 \
match ip src 1.2.3.4/32 flowid 10:1
# tc filter add dev eth0 protocol ip parent 10: prio 2 \
flowid 10:2
This assigns traffic to 4.3.2.1 and traffic from 1.2.3.4 to the highest priority queue, and the rest to the next-highest one.
A user can concatenate matches, to match on traffic from 1.2.3.4 and from port 80, do this:
# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 match ip src 4.3.2.1/32 \
match ip sport 80 0xffff flowid 10:1.

If a user followed advise and guidance as provided in this tutorial guide then he/she learnt about filtering.

Welcome to the tutorial guide. The guide will provide a user with advise and guidance on how to police the filters.

If a user wants to police at 4mbit/s, but 5mbit/s of traffic is present, then he or she can stop matching either the entire 5mbit/s, or only not match 1mbit/s, and do send 4mbit/s to the configured class.
If bandwidth exceeds the configured rate, then a user can drop a packet, reclassify it, or see if another filter will match it.
There are two different ways to police the filter. For example, if a user compiled the kernel with Estimators, the kernel can measure for each filter how much traffic it is passing, more or less. These estimators are very easy on the CPU, as they simply count 25 times per second how many data has been passed, and calculate the bitrate from that.
The other way for policing the filter is through a Token Bucket Filter, this time living within his/her filter. Please note that the TBF only matches traffic up to a users configured bandwidth, if more is offered, only the excess is subject to the configured overlimit action.
Policing with kernel estimator
This is very simple and has only one parameter: avrate. Either the flow remains below avrate, and the filter classifies the traffic to the classid configured, or a users rate exceeds it in which case the specified action is taken, which is reclassify by default.
The kernel uses an Exponential Weighted Moving Average for the bandwidth which makes it less sensitive to short bursts.
Policing with Token Bucket Filter
A user has a choice to use the following parameters:
• burst/buffer/maxburst
• mtu/minburst
• mpu
• rate
A user should be aware that if he/she sets the mtu of a TBF policer too low then no packets will pass, whereas the egress TBF qdisc will just pass them slower.

Overlimit actions
If a users filter decides that it is overlimit, it can take actions. Currently, four actions are available:
continue
Causes this filter not to match, but perhaps other filters will.
drop
This is a very fierce option which simply discards traffic exceeding a certain rate. It is often used in the ingress policer and has limited uses.
Pass/OK
Pass on traffic ok. Might be used to disable a complicated filter, but leave it in place.
reclassify
Most often comes down to reclassification to Best Effort. This is the default action.
Please have a look at this example:
Limit incoming icmp traffic to 2kbit, drop packets over the limit:
tc filter add dev $DEV parent ffff: \
protocol ip prio 20 \
u32 match ip protocol 1 0xff \
police rate 2kbit buffer 10k drop \
flowid :1
Limit packets to a certain size (i.e. all packets with a length greater than 84 bytes will get dropped):
tc filter add dev $DEV parent ffff: \
protocol ip prio 20 \
u32 match tos 0 0 \
police mtu 84 drop \
flowid :1
This method can be used to drop all packets:
tc filter add dev $DEV parent ffff: \
protocol ip prio 20 \
u32 match ip protocol 1 0xff \
police mtu 1 drop \
flowid :1
It actually drops icmp packets greater-than 1 byte. While packets with a size of 1 byte are possible in theory, a user will not find these in a real network.
If you followed this tutorial guide then you would have learnt about policing the filters.

Welcome to the tutorial guide. The tutorial guide will provide a user with guidance and instructions about the route classifier.

Please note that the route classifier filters based on the results of the routing tables. When a packet that is traversing through the classes reaches one that is marked with the “route” filter, it splits the packets up based on information in the routing table.
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 route
A user can add a route classifier onto the parent node 1:0 with priority 100 as you can see in the mentioned example. When a packet reaches this node, it will consult the routing table. If the packet matches, it will be send to the given class and have a priority of 100. Please note that in order to action this a user needs to add the appropriate routing entry:
A user can define the realm based on either destination or source. It is easy to do it like this:
# ip route add Host/Network via Gateway dev Device realm RealmNumber
If a user wants to define the destination network 192.168.10.0 with a realm number 10, then it an be done as shown below:
# ip route add 192.168.10.0/24 via 192.168.10.1 dev eth1 realm 10
When adding route filters, a user can use realm numbers to represent the networks or hosts and specify how the routes match the filters.
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 \
route to 10 classid 1:10
This rule matches the packets going to the network 192.168.10.0.
Please note that a route filter can be used to match source routes. For example, there is a subnetwork attached to the Linux router on eth2.
# ip route add 192.168.2.0/24 dev eth2 realm 2
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 \
route from 2 classid 1:2
In this case the filter specifies that packets from the subnetwork 192.168.2.0 (realm 2) will match class id 1:2.
If you followed advise and guidance as provided in this tutorial guide then you would have learnt about the route classifier.