Re: How to classify a port range?

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 [email protected]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 

Yassen Damyanov
M: +359-888-665-235
E: <[email protected]>