Brownian motion

Hash-tables based shaper can act as an effective firewall; just take a look.

Now our shaper configurator generates, let’s say, this script for a client’s connection (excerpt):

#
# Contract I-1082,
# connection 606 (0x25e).
#
# input:
/sbin/tc class add dev clients0 classid 1:25e parent 1:fe10 htb rate 96kbit ceil 128kbit quantum 1500 burst 7500 cburst 12500 prio 50
/sbin/tc filter add dev clients0 protocol 802.1q parent 1:0 prio 100 u32 ht 133:5c match ip dst X.X.133.92 flowid 1:25e
/sbin/tc filter add dev clients0 protocol 802.1q parent 1:0 prio 100 u32 ht 133:5d match ip dst X.X.133.93 flowid 1:25e
/sbin/tc filter add dev clients0 protocol 802.1q parent 1:0 prio 100 u32 ht 133:5e match ip dst X.X.133.94 flowid 1:25e
/sbin/tc filter add dev clients0 protocol 802.1q parent 1:0 prio 100 u32 ht 133:5f match ip dst X.X.133.95 flowid 1:25e

Now let’s assume we have a lot of DoS traffic from IP 173.204.53.138 to IP X.X.133.94 — a lot of packets, a client’s bandwidth is exhausted. (Yes, that’s real IP, that was a real DoS attack,-)

All we need is to write a filter into a proper hash table cell:

# input:
/sbin/tc class add dev clients0 classid 1:25e parent 1:fe10 htb rate 96kbit ceil 128kbit quantum 1500 burst 7500 cburst 12500 prio 50
# FIXME:
/sbin/tc filter add dev clients0 protocol 802.1q parent 1:0 prio 100 u32 ht 133:5e match ip src 173.204.53.138 police mtu 1 drop flowid 1:fe49
#
/sbin/tc filter add dev clients0 protocol 802.1q parent 1:0 prio 100 u32 ht 133:5c match ip dst X.X.133.92 flowid 1:25e
/sbin/tc filter add dev clients0 protocol 802.1q parent 1:0 prio 100 u32 ht 133:5d match ip dst X.X.133.93 flowid 1:25e
/sbin/tc filter add dev clients0 protocol 802.1q parent 1:0 prio 100 u32 ht 133:5e match ip dst X.X.133.94 flowid 1:25e
/sbin/tc filter add dev clients0 protocol 802.1q parent 1:0 prio 100 u32 ht 133:5f match ip dst X.X.133.95 flowid 1:25e

«FIXME» — because it’s a manual work, i have to add this feature in my configurator :-)

This filter we have added to a cell, where all filters regarding packets to X.X.133.94 are (there are only one filter normally). And we added it before «normal» filter, which «routes» packets to a client’s class.

This work like this: if a packet from IP 173.204.53.138 has MTU less that 1 byte (physically unreal case) — it should be «routed» to a default class (yes, 1:fe49 is the default class for my shaper now). If this packet has a larger MTU — it should be dropped.

Therefore, our queueing discipline have not to cope with these packets (HTB in my case, but it may be any qdisc).

Well.. I’ve done my django based configurator for my HTB shaper (bridge/linux).

I will try to translate this post in english; if you can read Ukrainian, try here.

Regarding the problem with shaping vlan-tagged traffic on linux bridge — it was my fault :-)

I asked community@lists.altlinux.org, and Sergey Vlasov answered me with some info and hint — thanks a lot!-)

As Sergey told, «a packet is being passed to bridge module before 8021q can process it». That’s why the classifier decides that a packet does not match a filter rule — because filter contains «protocol ip» condition, however a packet contains «protocol 802.1q» actually. It look like it’s enough to use «protocol 802.1q» in filter condition — after that ip addresses (offsets from IP packet’s start) will be counted correctly.

This offers a possibility to build «aggregating shapers» on linux bridges, which will be able to shaper clients” traffic regardless of «traffic direction» (regardless of a particular vlan membership). And it will be very easy to migrate from an «usual» shaper on linux bridge — we will have to replace «protocol ip» with «protocol 802.1q» in a filter template (or we can add one more filter — if it is really necessary).

Update: there are no any problem with vlans in classifiers, that was my fault.

Have been playing with shapers and run into such a problem: u32 classifier does not work (?) for tagged traffic on «non-tagged» linux bridge.

In more details:

Test bed:

Let’s take three linux boxes. One will be two-ports switch (SW), on two another (BoxA and BoxB) we will configure IP addresses 172.17.2.10/24 and 172.17.2.11/24, for example.

So.. For the beginning BoxA should ping BoxB on crossover cable.

Building bridge:

brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
ip link set up dev br0

Now BoxA should successfully ping BoxB through this switch.

Configuring shaper:

DEV=eth0
#
# QDisc:
tc qdisc add dev $DEV root handle 1: htb default 200
#
# root class:
tc class add dev $DEV classid 1:10 parent 1:0 htb rate 100Mbit
#
# default class:
tc class add dev $DEV classid 1:200 parent 1:10 htb rate 1Mbit
#
# class for test traffic:
tc class add dev $DEV classid 1:100 parent 1:10 htb rate 10Mbit
#
# filter for test traffic:
tc filter add dev $DEV protocol ip parent 1:0 prio 100 u32 match ip dst 172.17.2.10 flowid 1:100

Check — BoxA should ping BoxB, and this traffic should be in class 1:100, this can be verified by tc -s class show dev $DEV.

Configuring vlan subinterfaces:

Now on boxes A and B we remove addresses from interfaces and put them on sub-interfaces:

ip addr del 172.17.2.10/24 brd 172.17.2.255 dev eth0
#
vconfig add eth0.100
ip link set up dev eth.100
#
# on the other box there should be .11/24:
ip addr add 172.17.2.10/24 brd 172.17.2.255 dev eth0.100

Switch’s configuration remains unchanged.

Now BoxA still can ping BoxB, but this traffic is in the default class, 1:10, instead of 1:100.

The value of REORDER_HDR does not matter.

This is the problem.

What is wrong?

Some considerations:

1. u32 classifier takes «offset» counting from the beginning of IP packet.
2. vlan tag should not mess IP related code…

Is any of these wrong?

I’ve mentioned, i’m not a programmer :-)

I have finally formatted my «old» paper about using Python’s SPARK module for compiling «little languages» and code generation — as example, for scanning, parsing, analyzing a simple configuration file for configuring HTB shaper and generating a code (shell script).

I put it as a staic page — here.