Double Play Packet

You decide to try a quick test now that you have seen good examples of both types of packet tagging. You have router1 set up with a 2.4 kernel and both the NetFilter and the DiffServ running. You then run the following set of commands to set up the tagging mechanisms for both iptables and u32:

tc qdisc add dev eth1 handle ffff: ingress
tc filter add dev eth1 parent ffff: protocol ip prio 1 u32 \
     match ip src 10.1.1.0/24 classid :2

iptables -t mangle -i eth1 -A PREROUTING -s 10.1.1.0/24 -d 0/0 -j MARK --set-mark 1

ip rule add fwmark 1 table 1 prio 15000 realms 1/2
ip rule add fwmark 2 table 2 prio 15100 realms 3/4

ip route add default via 192.168.1.1 src 192.168.1.254 table 1
ip route add default via 192.168.1.1 src 192.168.1.254 table 2

Now you try a ping from net1 to host2 and look at your realms. The only ones with any traffic are realms 1/2:

[root@router1 /root]# rtacct
Realm     BytesTo     PktsTo     BytesFrom     PktsFrom
1     0     0     336     4
2     336     4     0     0

[root@router1 /root]# rtacct 3
Realm     BytesTo     PktsTo     BytesFrom     PktsFrom
3     0     0     0     0

[root@router1 /root]# rtacct 4
Realm     BytesTo     PktsTo     BytesFrom     PktsFrom
3     0     0     0     0

You know that the rtacct utility will only list out the realms that have actual counts in them. Just to make sure, you manually listed realm 3 and realm 4 and found them empty.

Now you do wonder if maybe the fact that the rule for the u32 filter was of a higher priority, 15000, than the rule for NetFilter, 15100. So just to make sure you reverse the order of the commands, change the priorities on the rules, reboot router1, and try again. Your command listing looks like this:

iptables -t mangle -i eth1 -A PREROUTING -s 10.1.1.0/24 -d 0/0 -j MARK --set-mark 1

tc qdisc add dev eth1 handle ffff: ingress
tc filter add dev eth1 parent ffff: protocol ip prio 1 u32 \
     match ip src 10.1.1.0/24 classid :2

ip rule add fwmark 2 table 2 prio 15000 realms 3/4
ip rule add fwmark 1 table 1 prio 15100 realms 1/2

ip route add default via 192.168.1.1 src 192.168.1.254 table 1
ip route add default via 192.168.1.1 src 192.168.1.254 table 2

You try this setup and it gives the exact same output as the first. So you correctly conclude that the NetFilter framework operates at a lower level within the packet tagging structures than the ingress qdisc, and that the one does not override the other.

Now you decide quickly to test out the coexistence. To this end you set up the following script, which uses u32 to tag host1 and iptables to mark host2:

iptables -t mangle -i eth1 -A PREROUTING -s 10.1.1.3/32 -d 0/0 -j MARK --set-mark 2

tc qdisc add dev eth1 handle ffff: ingress
tc filter add dev eth1 parent ffff: protocol ip prio 1 u32 \
     match ip src 10.1.1.2/32 classid :1

ip rule add fwmark 2 table 2 prio 15000 realms 3/4
ip rule add fwmark 1 table 1 prio 15100 realms 1/2

ip route add default via 192.168.1.1 src 192.168.1.254 table 1
ip route add default via 192.168.1.1 src 192.168.1.254 table 2

When you run this script you get output for all four realms. Recalling that earlier the two tagging mechanisms were set to tag the same packets, you realize that you can now have the best of both worlds. The NetFilter mark can be used on the packet headers and the u32 classifier can be used on arbitrary binary data from the packet. This allows for a truly powerful system.