Interactions with Packet Filters

In your testing of the u32 qdisc you came to wonder what interactions exist between the NetFilter mangle and the u32 filter. You know from testing the fwmark that the mangle table can select and mark packets on input using the PREROUTING hook. You know from your u32 testing that the u32 filter can select and mark packets on ingress. Does one override the other or can they coexist?

Example 6.7 ”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   /usr/local/bin/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   4          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 wonder if this lack of traffic through fwmark 2 is due to the priority of the rule for fwmark 1 being a higher priority, 15000, than the rule for fwmark 2, 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:

  /usr/local/bin/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 con clude that the NetFilter parts are 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:

  /usr/local/bin/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.

Top