ポリシング

以前 egress も police でできるのでは? と書いて、試してみた。

# tc qdisc add dev eth1 root handle 10: prio
# tc filter add dev eth1 parent 10: protocol ip prio 20 u32 match u8 0 0 police rate 1Mbit buffer 64Kb drop flowid :1
# iperf -c toptor4
------------------------------------------------------------
Client connecting to toptor4, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 172.27.129.1 port 57260 connected with 172.27.129.2 port 5001
[  3]  0.0-10.0 sec  1.26 MBytes  1.05 Mbits/sec

それなり。ingress も同様で burst の値でだいぶ変わるけど、まぁそれなり....
あと flowid :1 も ingress 同様どうでも良いのか?

ポリシング

ingress の qdisc 例を探していたところホストを SYN フラッドから守るなるものがあった。filter を理解していないので、すっごい adhoc だけど eth0 の ingress ポリシングは

tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol ip prio 20 u32 match u8 0 0 police rate 1Mbit buffer 20Kb drop flowid :1

みたいな感じで OK っぽい。ただ最後の flowid :1 って何かわからん。
結局何が言いたいかと言うと、先日の TBF って頑張らなくても filter - police - action drop で同じことができるのでは? とゆー話。

有益そうなリンク。以前 netdev でアナウンスされたことがあった記憶が...で IFB って使うとデバイスにヒモ付かなくても qdisc 使えるの?

TBF

ポリシングとシェーピングあたりが違いがわかりやすかった。加えて Linux 特化な部分があるけど このあたりにある
Other info: very good paper about tbf (6 pages, 17 May 2001)
からの図もわかりやすい。意訳すると...

バケツがトラフィックフローの平均送信レートを表すトークンによって補充されるレートである rate。トークンバケツが貯めることができるトークン数である bucket size あるいは burst size。limit はバケツのサイズとキューのサイズの合計。これによって TBF がポリシングするかシェーピングするか決める。limit が bucket size と同じならばキューのサイズは 0 となり、(descipline に) 従わないパケットはドロップされる。つまりポリシング。limit が bucket size より大きいならば...

で、ポリシングの場合は

tc qdisc add dev eth1 root tbf rate 1Mbit burst 20Kb limit 20Kb

で iperf 使って測ると見事ソレらしい数値になった。
もう一回。limit と burst が同じならばポリシング、limit が burst より大きくなると、それなりにシェーピング。