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.

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