On 11/25/2016 7:19 PM, Andy Furniss wrote:
Yassen Damyanov wrote:
On 11/25/2016 1:29 AM, Andy Furniss wrote:
I've never used ematch so don't know if this is correct or not, but -
http://serverfault.com/questions/231880/how-to-match-port-range-using-u32-filter
Thanks much, Andy. Would be great if this solves the problem, but it
doesn't seem to work, unfortunately:
# tc qdisc add dev $DEV root handle 1:0 htb
# tc class add dev $DEV parent 1:0 classid 1:1 htb rate 2mbit
# tc filter add dev $DEV parent 1:0 protocol ip prio 1 basic match
"cmp(u16 at 0 layer transport gt 4000) and cmp(u16 at 0 layer transport
lt 6000)" flowid 1:1
dport would be u16 at 2
Thanks so much, Andy (and stupid me). Yep, that was it, works like a
charm! (Rodney, no need to look that up, problem solved, thanks buddy.)
For anyone else who might be stumbling on this: here's the correct
sequence for my case (where I tried to shape tcp traffic with a dport
range 5000-6000, excl.):
# tc qdisc add dev $DEV root handle 1:0 htb
# tc class add dev $DEV parent 1:0 classid 1:1 htb rate 2mbit
# tc filter add dev $DEV parent 1:0 protocol ip prio 1 basic match
"cmp(u16 at 2 layer transport gt 5000) and cmp(u16 at 2 layer transport
lt 6000)" flowid 1:1
$DEV is the network device name (e.g. eth0) and the root qdisc is left
w/o a default so that we do not shape unclassified traffic.
(thumbs up!)
After running an iperf client against another machine in the local net,
there's no shaping happening, and the 1:1 class is not visited:
class htb 1:1 root prio 0 quantum 25000 rate 2000Kbit ceil 2000Kbit
linklayer ethernet burst 1600b/1 mpu 0b overhead 0b cburst 1600b/1 mpu
0b overhead 0b level 0
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
lended: 0 borrowed: 0 giants: 0
tokens: 100000 ctokens: 100000
If I use a single port match:
# tc qdisc add dev $DEV root handle 1:0 htb
# tc class add dev $DEV parent 1:0 classid 1:1 htb rate 2mbit
# tc filter add dev $DEV parent 1:0 protocol ip prio 1 u32 match ip
dport 5001 0xffff flowid 1:1
then the traffic is indeed limited to 1.9 Mbits/sec and the class stats
look different:
class htb 1:1 root prio 0 quantum 25000 rate 2000Kbit ceil 2000Kbit
linklayer ethernet burst 1600b/1 mpu 0b overhead 0b cburst 1600b/1 mpu
0b overhead 0b level 0
Sent 1507824 bytes 1000 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
lended: 484 borrowed: 0 giants: 0
tokens: -3139 ctokens: -3139
Does anyone know what might be wrong with that ematch use?
-Y.
On 11/25/2016 1:29 AM, Andy Furniss wrote:
Yassen Damyanov wrote:
Hello LARTC guys,
I am working on an OSS Python wrapper library intended to help with
expressing a traffic control structure as a tree of Python objects.
This
structure should later be able to represent itself as a series of tc
commands. (Your suggestions for getting this thing useful would be
invaluable.)
I have questions, inevitably. Currently heaviest part seems to be the
issue of classifying a set of tcp or udp ports to get shaped under a
common rate limit. (I need to later simulate packet loss for flows on
these ports, but first things first.)
Can you help me get on the right direction here? Using u32 seems
daunting for this particular case. Is there another way to do the
match?
I've read the relevant parts of the LARTC HowTo and couple more
documents but still cannot get it right.
Any help would be much appreciated!
Thanks in advance,
Yassen D.
I've never used ematch so don't know if this is correct or not, but -
http://serverfault.com/questions/231880/how-to-match-port-range-using-u32-filter
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Yassen Damyanov
M: +359-888-665-235
E: <yd@xxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
