Brownian motion

Having used IRRToolSet in elder Ubuntu releases (elder compilers, libraries etc), i finally decided to compile it under 9.10 (yes, previously made RtConfig works under 9.10 too, «but anyway»).

But something goes wrong, with several files — illegal conversion and «bad» syntax and the like.

So, if you’ll run into the same problems, hope this patch will help.

Apply patch as usually (in the directory where IRRToolSet-4.8.5 is unpacked):

$ patch -p0 --dry-run < IRRToolSet-4.8.5-ubu-patch.diff

If everything is OK, remove --dry-run switch and run again.

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

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