Brownian motion

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

I liked just a couple of their songs, or, rather, the manner.

But… *That* time was horrible. Really.

ps. Red sunrise is followed by brown sunset…

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

If the future needs us — in a which way?..

… already for a long time humanity is the human-machine system, which only in this state can perform its functions. If we look at trends, we can see that part of this system’s information, which is being stored outside of human brain, is gradually increasing during thousands of years already — since the invention of cuneiform script — and we simply are closer and closer to that time, when this part of information in a human will become negligibly small.

But do not separate humans and computers — they, along with printed books, are parts of the single system, which can not work otherwise.

Yes, independent can be only that, what can reproduce itself. So, what reproduces itself now? Human? Not at all. Independently of the rest of humanity modern human will die in a few weeks. Reproduces itself the civilization — along with the necessary people, who are reproduced exactly as a machines. … Simply in a some step some elements of evolutionary system can become unneeded — how steams became unneeded some time before, — with the exception that those elements will become we, humans.

However, is it possible to stop progress? Definitely, total control over all planet is necessary for this.

(Translation from russian is mine, sorry for my english)

I would note, however, that i am more optimistic.

Everything will stop before robots will become humans and humans will become robots ;-)

However… we will see.