Linux Solutions

Welcome to the tutorial guide. The guide will provide a user with guidance and instructions on Kernel network parameters. Please note that the kernel has lots of parameters which can be tuned for different circumstances.

By default, routers can route everything including packets which do not belong on the users network. For example, a common example is private IP space escaping onto the Internet. If a user has an interface with a route of 195.96.96.0/24 to it, a user will not expect packets from 212.64.94.1 to arrive there.
Lots of people would like to turn this feature off, so the kernel hackers have made it easy. There are files in /proc where a user can tell the kernel to do this for a user. The method is called “Reverse Path Filtering”. Basically, if the reply to a packet wouldn’t go out the interface this packet came in, then this is a bogus packet and should be ignored.
The following fragment will turn this on for all current and future interfaces.
# for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do
> echo 2 > $i
> done
By putting this example into practice, if a packet arrived on the Linux router on eth1 claiming to come from the Office+ISP subnet, it would be dropped. Similarly, if a packet came from the Office subnet, claiming to be from somewhere outside a users firewall, it would be dropped also.
The above is full reverse path filtering. The default is to only filter based on IPs that are on directly connected networks. This is because the full filtering breaks in the case of asymmetric routing (where packets come in one way and go out another, like satellite traffic, or if a user has dynamic routes in the his/her network. The data comes down through the satellite dish and replies go back through normal land-lines).
If this exception applies to the user then the user can simply turn off the rp_filter on the interface where the satellite data comes in. If a user wants to see if any packets are being dropped, the log_martians file in the same directory will tell the kernel to log them to his/her syslog.
# echo 1 >/proc/sys/net/ipv4/conf//log_martians

If you followed this tutorial guide, then you would have learnt about kernel network parameters

Welcome to the tutorial guide. The tutorial will provide instructions and guidance on classifying packets with filters. If a user wants to determine which class shall process a packet, the classifier chain is called each time a choice needs to be made. The classifier chain consists of all filters attached to the classful qdisc that needs to decide.
If a user wants to reiterate the tree, which is not a tree:
root 1:
|
_1:1_
/ | \
/ | \
/ | \
10: 11: 12:
/ \ / \
10:1 10:2 12:1 12:2
When enqueueing a packet, at each branch the filter chain is consulted for a relevant instruction. A typical setup might be to have a filter in 1:1 that directs a packet to 12: and a filter on 12: that sends the packet to 12:2.
A user can refer to this later latter rule to 1:1, but the user should note that efficiency can only be gained by having more specific tests lower in the chain.
A user cannot filter a packet upwards. Packets are only enqueued downwards. When they are dequeued, they go up again, where the interface lives. Please note that the packets do not fall off the end of the tree to the network adaptor.

If you followed this tutorial guide then you would have learnt about classifying packets with filters.

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.