Brownian motion

I’ve decided to make it available after some nice people asked for this.

Now i have no time and, let’s say, health to make it better, so please don’t complain :-)

I guess it maybe would be better to make it available somewhere at code.google.com — i would like to work on this code later, surely.

Anyway. Now — as it now is. With incomplete README:

Hi.

Sorry, this is a mess.

Look at settings.py, of course. And there is one more file,
shap_defaults.py, take a look, make changes.

This configurator assumes that you have a linux box with two network
interfaces connected in a bridge (two-ports Ethernet switch), and you
wish to set up a HTB shaper on each; and these shapers should be
symmetrical, one for incoming (destined to your IP(s)) and another for
outgoing (from your IP(s)) traffic.

This configurator assumes that you already do have a script, which
should set up your shaper's "basement" --- root qdisc and root
class(es). With their leaves (qdiscs and classes) possibly. With ---
important --- hash tables for all your /24s.

An i assume you can set up django and add this "project" to it .)

Then you can set up (via django admin interface or using fixtures) your
networks, all one by one, as /24 prefixes (2 for /23, 4 for /22 etc..).

You can (and should, actually) configure:
  -  "QoS classes" (in terms of "which class should be a parent for this
     client's class" and "which part of ceil should be guaranteed").
  -  contract types (to use identifiers for contracts in a form
     "<letter_or_some_letters>-<digits><optional_prefix>")
  -  ?.. something else?.. Well, i will update this README, i hope.

You may configure:
  -  "own" client's networks (which, for example, your client announces
     to you via some of dynamic routing protocols, or which are set up
     statically by you own)
  -  network ranges delegations --- ugly, "incomplete" (if smth else may
     be considered as complete)

Now --- i am really sorry, *really* :-) --- there is no gettext support,
and there are a lot of comments and remarks in Ukrainian.

Now there are a lot (no too much though) places with unused code or like
this --- *this is a mess*.

I am not a programmer, at all. I wish _you_ could help me to do this
better.)

"AS IS", surely, and this README --- "AS IS".

Sorry.

# .-)
# vim: set tw=72:

I am not even sure this can be deployed and used. It works for me though, works great. So i hope i will update it to some more usable state.

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).

If you wish to use vlan sub-interfaces in linux, and sub-sub-interfaces, and sub-sub-sub-… and if you wish to ping something — sure, you may wish to have them only for switching, but if you wish to ping — don’t forget to re-set REORDER_HDR flag:

ip link set up dev eth2
 
vconfig add eth2 100
ip link set up dev vlan100
vconfig set_flag vlan100 1 0
 
vconfig add vlan100 200
ip link set up dev vlan200
vconfig set_flag vlan200 1 0
 
# ....etc-etc
 
vconfig add vlan800 900
ip link set up dev vlan900
vconfig set_flag vlan900 1 0
 
ip add add 192.168.1.100/24 brd 192.168.1.255 dev vlan900
 
ping 192.168.1.3

Note using command vconfig set_flag DEV 1 0 — i mean exactly this :-)

Now (since 2.6.x?.. can’t remember, doesn’t matter) Linux kernel creates vlan interfaces with REORDER_HDR=1.

You can verify current value of REORDER_HDR flag with command like this:

# cat /proc/net/vlan/vlan900
vlan900  VID: 900	 REORDER_HDR: 0  dev->priv_flags: 1
         total frames received          172
          total bytes received       222546
      Broadcast/Multicast Rcvd            0

      total frames transmitted          405
       total bytes transmitted       283743
            total headroom inc            0
           total encap on xmit           26
Device: vlan900
INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0
 EGRESS priority mappings:

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).