Трохи роботи .)
Щойно дописав підтримку IPv6 для свого конфігуратора (Django/Python) шейпера (HTB/Linux).
«Воно жахливе, але працює чудово»™ .)
around the essentials…
Щойно дописав підтримку IPv6 для свого конфігуратора (Django/Python) шейпера (HTB/Linux).
«Воно жахливе, але працює чудово»™ .)
This info was tested with kernels 2.6.26 and 2.6.32. Caution, 2.6.31, looks like, has some nitpicks.
Well, I did not examine cls_u32.c
etc-etc — so I can be wrong .)
Some notes regarding «filtering logic»:
tc filter ... protocol <proto> u32 match u<length> <value> <mask> at <offset>
— we mention an offset «from ZERO», the kernel does it «from the beginning of IP packet».
Here is a «demo» script (fully working however), which will filter packets in vlan 22 and 310 into different classes (as usually, I am talking of linux bridge with shaper on it; and this bridge passes throught vlan tagged traffic):
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:
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:
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.
*subj* :-)
Давно було зрозуміло, що без нормального конфігуратора керувати нормальним шейпером «важкувато», але… все ускладнювала одна обставина — я не програміст (тм).
Чим мене не влаштовують наявні інструменти?
По-перше, всі знайдені вирішують трохи інші задачі, простіші; зокрема, я так і не знайшов конфігуратора для «свого шейпера» — шейпера на мості (bridge/linux), з використанням хеш-таблиць. Для великої кількості клієнтів, для великої кількості IP адрес.
Отже, мені треба було написати щось своє.
Я собі спростив задачу:
Мій шейпер (тм,-) використовує хеш-таблиці; ці таблиці створює вищезгаданий «окремий скрипт», а заповнюються вони вже скриптами, які генеруються автоматично, засобами django, через специфічні представлення даних.
Отже, «схема» містить такі сутності:
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:
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.