2
This documented is slightly dated but should give you idea of how things
8
An extension to the filtering/classification architecture of Linux Traffic
10
Up to 2.6.8 the only action that could be "attached" to a filter was policing.
11
i.e you could say something like:
14
tc filter add dev lo parent ffff: protocol ip prio 10 u32 match ip src \
15
127.0.0.1/32 flowid 1:1 police mtu 4000 rate 1500kbit burst 90k
18
which implies "if a packet is seen on the ingress of the lo device with
19
a source IP address of 127.0.0.1/32 we give it a classification id of 1:1 and
20
we execute a policing action which rate limits its bandwidth utilization
23
The new extensions allow for more than just policing actions to be added.
24
They are also fully backward compatible. If you have a kernel that doesnt
25
understand them, then the effect is null i.e if you have a newer tc
26
but older kernel, the actions are not installed. Likewise if you
27
have a newer kernel but older tc, obviously the tc will use current
28
syntax which will work fine. Of course to get the required effect you need
29
both newer tc and kernel. If you are reading this you have the
32
A side effect is that we can now get stateless firewalling to work with tc.
33
Essentially this is now an alternative to iptables.
34
I wont go into details of my dislike for iptables at times, but
35
scalability is one of the main issues; however, if you need stateful
36
classification - use netfilter (for now).
38
This stuff works on both ingress and egress qdiscs.
43
1) new additional syntax and actions enabled. Note old syntax is still valid.
45
Essentially this is still the same syntax as tc with a new construct
46
"action". The syntax is of the form:
47
tc filter add <DEVICE> parent 1:0 protocol ip prio 10 <Filter description>
48
flowid 1:1 action <ACTION description>*
50
You can have as many actions as you want (within sensible reasoning).
52
In the past the only real action was the policer; i.e you could do something
54
tc filter add dev lo parent ffff: protocol ip prio 10 u32 \
55
match ip src 127.0.0.1/32 flowid 1:1 \
56
police mtu 4000 rate 1500kbit burst 90k
58
Although you can still use the same syntax, now you can say:
60
tc filter add dev lo parent 1:0 protocol ip prio 10 u32 \
61
match ip src 127.0.0.1/32 flowid 1:1 \
62
action police mtu 4000 rate 1500kbit burst 90k
64
" generic Actions" (gact) at the moment are:
65
{ drop, pass, reclassify, continue}
66
(If you have others, no listed here give me a reason and we will add them)
67
+drop says to drop the packet
68
+pass says to accept it
69
+reclassify requests for reclassification of the packet
70
+continue requests for next lookup to match
72
2)In order to take advantage of some of the targets written by the
73
iptables people, a classifier can have a packet being massaged by an
74
iptable target. I have only tested with mangler targets up to now.
75
(infact anything that is not in the mangling table is disabled right now)
78
*ingress is mapped to pre-routing hook
79
*egress is mapped to post-routing hook
80
I dont see much value in the other hooks, if you see it and email me good
81
reasons, the addition is trivial.
83
Example syntax for iptables targets usage becomes:
84
tc filter add ..... u32 <u32 syntax> action ipt -j <iptables target syntax>
87
tc filter add dev lo parent ffff: protocol ip prio 8 u32 \
88
match ip dst 127.0.0.8/32 flowid 1:12 \
89
action ipt -j mark --set-mark 2
91
3) A feature i call pipe
92
The motivation is derived from Unix pipe mechanism but applied to packets.
93
Essentially take a matching packet and pass it through
94
action1 | action2 | action3 etc.
95
You could do something similar to this with the tc policer and the "continue"
96
operator but this rather restricts it to just the policer and requires
97
multiple rules (and lookups, hence quiet inefficient);
99
as an example -- and please note that this is just an example _not_ The
100
Word Youve Been Waiting For (yes i have had problems giving examples
101
which ended becoming dogma in documents and people modifying them a little
104
i selected the metering rates to be small so that i can show better how
107
The script below does the following:
108
- an incoming packet from 10.0.0.21 is first given a firewall mark of 1.
110
- It is then metered to make sure it does not exceed its allocated rate of
111
1Kbps. If it doesnt exceed rate, this is where we terminate action execution.
113
- If it does exceed its rate, its "color" changes to a mark of 2 and it is
114
then passed through a second meter.
116
-The second meter is shared across all flows on that device [i am suprised
117
that this seems to be not a well know feature of the policer; Bert was telling
118
me that someone was writing a qdisc just to do sharing across multiple devices;
119
it must be the summer heat again; weve had someone doing that every year around
120
summer -- the key to sharing is to use a operator "index" in your policer
121
rules (example "index 20"). All your rules have to use the same index to
124
-If the second meter is exceeded the color of the flow changes further to 3.
126
-We then pass the packet to another meter which is shared across all devices
127
in the system. If this meter is exceeded we drop the packet.
129
Note the mark can be used further up the system to do things like policy
130
or more interesting things on the egress.
132
------------------ cut here -------------------------------
134
# Add an ingress qdisc on eth0
135
tc qdisc add dev eth0 ingress
137
#if you see an incoming packet from 10.0.0.21
138
tc filter add dev eth0 parent ffff: protocol ip prio 1 \
139
u32 match ip src 10.0.0.21/32 flowid 1:15 \
141
# first give it a mark of 1
142
action ipt -j mark --set-mark 1 index 2 \
144
# then pass it through a policer which allows 1kbps; if the flow
145
# doesnt exceed that rate, this is where we stop, if it exceeds we
146
# pipe the packet to the next action
147
action police rate 1kbit burst 9k pipe \
149
# which marks the packet fwmark as 2 and pipes
150
action ipt -j mark --set-mark 2 \
152
# next attempt to borrow b/width from a meter
153
# used across all flows incoming on eth0("index 30")
154
# and if that is exceeded we pipe to the next action
155
action police index 30 mtu 5000 rate 1kbit burst 10k pipe \
156
# mark it as fwmark 3 if exceeded
157
action ipt -j mark --set-mark 3 \
158
# and then attempt to borrow from a meter used by all devices in the
159
# system. Should this be exceeded, drop the packet on the floor.
160
action police index 20 mtu 5000 rate 1kbit burst 90k drop
161
---------------------------------
163
Now lets see the actions installed with
164
"tc filter show parent ffff: dev eth0"
166
-------- output -----------
167
jroot# tc filter show parent ffff: dev eth0
168
filter protocol ip pref 1 u32
169
filter protocol ip pref 1 u32 fh 800: ht divisor 1
170
filter protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:15
172
action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING
173
target MARK set 0x1 index 2
175
action order 2: police 1 action pipe rate 1Kbit burst 9Kb mtu 2Kb
177
action order 3: tablename: mangle hook: NF_IP_PRE_ROUTING
178
target MARK set 0x2 index 1
180
action order 4: police 30 action pipe rate 1Kbit burst 10Kb mtu 5000b
182
action order 5: tablename: mangle hook: NF_IP_PRE_ROUTING
183
target MARK set 0x3 index 3
185
action order 6: police 20 action drop rate 1Kbit burst 90Kb mtu 5000b
187
match 0a000015/ffffffff at 12
188
-------------------------------
190
Note the ordering of the actions is based on the order in which we entered
191
them. In the future i will add explicit priorities.
193
Now lets run a ping -f from 10.0.0.21 to this host; stop the ping after
194
you see a few lines of dots
197
[root@jzny hadi]# ping -f 10.0.0.22
198
PING 10.0.0.22 (10.0.0.22): 56 data bytes
199
....................................................................................................................................................................................................................................................................................................................................................................................................................................................
200
--- 10.0.0.22 ping statistics ---
201
2248 packets transmitted, 1811 packets received, 19% packet loss
202
round-trip min/avg/max = 0.7/9.3/20.1 ms
203
-----------------------------
205
Now lets take a look at the stats with "tc -s filter show parent ffff: dev eth0"
208
jroot# tc -s filter show parent ffff: dev eth0
209
filter protocol ip pref 1 u32
210
filter protocol ip pref 1 u32 fh 800: ht divisor 1
211
filter protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1
214
action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING
215
target MARK set 0x1 index 2
216
Sent 188832 bytes 2248 pkts (dropped 0, overlimits 0)
218
action order 2: police 1 action pipe rate 1Kbit burst 9Kb mtu 2Kb
219
Sent 188832 bytes 2248 pkts (dropped 0, overlimits 2122)
221
action order 3: tablename: mangle hook: NF_IP_PRE_ROUTING
222
target MARK set 0x2 index 1
223
Sent 178248 bytes 2122 pkts (dropped 0, overlimits 0)
225
action order 4: police 30 action pipe rate 1Kbit burst 10Kb mtu 5000b
226
Sent 178248 bytes 2122 pkts (dropped 0, overlimits 1945)
228
action order 5: tablename: mangle hook: NF_IP_PRE_ROUTING
229
target MARK set 0x3 index 3
230
Sent 163380 bytes 1945 pkts (dropped 0, overlimits 0)
232
action order 6: police 20 action drop rate 1Kbit burst 90Kb mtu 5000b
233
Sent 163380 bytes 1945 pkts (dropped 0, overlimits 437)
235
match 0a000015/ffffffff at 12
236
-------------------------------
241
Wanna write an action module?
242
------------------------------
243
Its easy. Either look at the code or send me email. I will document at
244
some point; will also accept documentation.
249
Lotsa goodies/features coming. Requests also being accepted.
250
At the moment the focus has been on getting the architecture in place.
251
Expect new things in the spurious time i have to work on this
252
(particularly around end of year when i have typically get time off