Thanks for this help, I think the marks are getting saved/restored
successfully, and I can successfully classify request traffic from the
proxy server based on the mark (statistics on the eth0.2 classes are
incrementing) but response traffic from the origin server isn't getting
classified yet (statistics on the ifb0 classes remain zero).
Here is my complete work in progress script. How can I investigate why
response traffic isn't getting classified? Are there any more details
that would help explain why not?
How can I classify traffic based on the restored mark? or is there
another way to classify response traffic from the origin server based on
the TOS/DSCP field of the request?
1: # Save/restore connection mark based on TOS field
2: iptables -A PREROUTING -t mangle -j CONNMARK --restore-mark
3: iptables -A PREROUTING -t mangle -m tos --tos 12 -j MARK --set-mark 1
4: iptables -A PREROUTING -t mangle -m tos --tos 28 -j MARK --set-mark 2
5: iptables -A PREROUTING -t mangle -j CONNMARK --save-mark
6:
7: ifconfig ifb0 up
8:
9: insmod sch_ingress
10: tc qdisc add dev eth0.2 ingress
11:
12: # Classify response traffic from origin server based on restored mark
13: insmod cls_fw
14: insmod act_mirred
15: tc filter add dev eth0.2 parent ffff: protocol ip pref 1 handle 1
fw flowid 2:1 action mirred egress redirect dev ifb0
16: tc filter add dev eth0.2 parent ffff: protocol ip pref 1 handle 2
fw flowid 2:3 action mirred egress redirect dev ifb0
17:
18: # Send unmarked traffic to class 2:2
19: insmod cls_u32
20: tc filter add dev eth0.2 parent ffff: protocol ip pref 1 u32
match u32 0 0 flowid 2:2 action mirred egress redirect dev ifb0
21:
22: # Limit up and downstream to 1mbit, to "own" the queue
23: insmod sch_tbf
24: tc qdisc add dev eth0.2 root handle 1 tbf rate 1mbit burst 5k
latency 70ms
25: tc qdisc add dev ifb0 root handle 1 tbf rate 1mbit burst 5k
latency 70ms
26:
27: # High, low, and "other" priority
28: insmod sch_prio
29: tc qdisc add dev eth0.2 parent 1: handle 2 prio
30: tc qdisc add dev ifb0 parent 1: handle 2 prio
31:
32: # Classify request traffic from proxy server based on mark
33: tc filter add dev eth0.2 parent 2: protocol ip pref 1 handle 1 fw
flowid :1
34: tc filter add dev eth0.2 parent 2: protocol ip pref 1 handle 2 fw
flowid :3
On 05/12/12 01:12 AM, Eliezer Croitoru wrote:
Thanks Anatoly,
My idea was that based on a mark he will jump the packets to another
table which HE will mark TOS/DSCP.
Eliezer
On 12/5/2012 4:39 AM, Anatoly Muliarski wrote:
Hi Jack,
--restore-mark should be used for existing connections and to mark new
ones you may use something like that:
iptables -t mangle -A PREROUTING -i eth0.2 -m tos --tos 1 -m conntrack
--cstate NEW,RELATED -j MARK --set-mark 1
The main idea consists in marking packets on the physical input
interface and shaping them on ifb0( where they arrive already marked
).
iptables' packet marks exist only in memory of one computer, TOS/DSCP
may be used for transmitting a map of them to another one.
BTW, use --restore-mark on the output interface of your shaper too.
2012/12/3, Jack Bates <uo4zau@xxxxxxxxxxxxxxxx>:
Thanks a lot for your help, how can I evaluate --restore-mark before I
classify and shape response traffic from the origin server?
I think you mean something like:
# Copy ctmart to nfmark (e.g. 1, 2)
iptables -A PREROUTING -t mangle -i eth0.2 -j CONNMARK
--restore-mark
# Classify by nfmark (e.g. 1, 2), send unmarked traffic to class 2:2
tc filter add dev eth0.2 parent ffff: protocol ip handle 1 fw flowid
2:1 action mirred egress redirect dev ifb0
tc filter add dev eth0.2 parent ffff: protocol ip handle 2 fw flowid
2:3 action mirred egress redirect dev ifb0
tc filter add dev eth0.2 parent ffff: protocol ip u32 match u32 0 0
flowid 2:2 action mirred egress redirect dev ifb0
Just how can I get --restore-mark to evaluate before tc filter?
Another way I can imagine is with the CLASSIFY target:
# Send unmarked traffic to class 2:2
iptables -A PREROUTING -t mangle -i eth0.2 -m connmark --mark 1 -j
CLASSIFY 2:1
iptables -A PREROUTING -t mangle -i eth0.2 -m connmark --mark 2 -j
CLASSIFY 2:3
iptables -A PREROUTING -t mangle -i eth0.2 -j CLASSIFY 2:2
But I have the same challenge, how can I evaluate the CLASSIFY target
before I shape traffic?
Or is there another way to classify and shape response traffic from the
origin server based on the TOS/DSCP field of the request?
On 03/12/12 03:52 AM, Eliezer Croitoru wrote:
You use iptables mark + restore mark based on connection tracking.
you can mark the TOS on the outgoing postrouting table.
you can take a look at the iptabes man pages:
http://ipset.netfilter.org/iptables.man.html
which has --restore-mark exaple.
Eliezer
On 12/3/2012 10:43 AM, Jack Bates wrote:
I can imagine a couple ways of classifying traffic from our proxy
server
based on the TOS/DSCP field, and also how to set the connection mark
based on this field. But how do I classify and shape response traffic
from the origin server based on the connection mark?
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
