Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've written a script that shapes traffic into 3 pipes. The first pipe needs to be high priority and always be send first. This works perfectly now on 1 condition. I enter a correct ceil/max bitrate. This script is written to work an a device that will work with lots of different internet connections. The max bitrate can be set, but I prefer to have it working without the need to set a max bitrate. Or if I set a high value like 999mbps the prioritizing still works. Is this possible? And if, how?

Thank you!

Malic

Here is my script:

#!/bin/bash

DEV=$1
UPLINK=$2
DOWNLINK=$3
PORT_CLIENT=$4
PORT_TELNET=$5
PORT_SSH=$7
PORT_RTSP=$6

#erase previous qdiscs
tc qdisc del dev $DEV root
#tc qdisc del dev $DEV ingress


#set root qdisc
tc qdisc add dev $DEV root handle 1:0 htb
#set different pipes, rates and priorities        
tc class add dev $DEV parent 1:0 classid 1:1 htb rate ${UPLINK}kbit ceil ${UPLINK}kbit
tc class add dev $DEV parent 1:1 classid 1:10 htb rate $[7*${UPLINK}/10]kbit ceil ${UPLINK}kbit prio 1
tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[2*${UPLINK}/10]kbit ceil ${UPLINK}kbit prio 3
tc class add dev $DEV parent 1:1 classid 1:30 htb rate $[1*${UPLINK}/10]kbit ceil ${UPLINK}kbit prio 4
#unlimited access
#tc class add dev $DEV parent 1:0 classid 1:90 htb rate 100000mbit burst 100000mbit


#stochastic fairness
#tc qdisc add dev $DEV parent 1:10 handle 100: sfq perturb 10
#tc qdisc add dev $DEV parent 1:20 handle 200: sfq perturb 10
#tc qdisc add dev $DEV parent 1:30 handle 300: sfq perturb 10
tc qdisc add dev $DEV parent 1:10 handle 100: pfifo limit 2
tc qdisc add dev $DEV parent 1:20 handle 200: pfifo limit 2
tc qdisc add dev $DEV parent 1:30 handle 300: pfifo limit 2


#filter data streams into pipe1
tc filter add dev $DEV parent 1:0 protocol ip prio 1 u32 match ip sport $PORT_CLIENT 0xffff flowid 1:10
tc filter add dev $DEV parent 1:0 protocol ip prio 1 u32 match ip sport $PORT_TELNET 0xffff flowid 1:10
tc filter add dev $DEV parent 1:0 protocol ip prio 1 u32 match ip sport $PORT_SSH 0xffff flowid 1:10
tc filter add dev $DEV parent 1:0 protocol ip prio 1 u32 match ip protocol 6 0xff match u8 0x10 0xff at nexthdr+13 flowid 1:10
tc filter add dev $DEV parent 1:0 protocol ip prio 1 u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 1:10
tc filter add dev $DEV parent 1:0 protocol ip prio 1 u32 match ip protocol 6 0xff match u32 0x52545350 0xffffffff at 40 flowid 1:10
#filter video streams into pipe2
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 match ip sport $PORT_RTSP 0xffff flowid 1:20
#filter rest into pipe3
tc filter add dev $DEV parent 1:0 protocol ip prio 18 u32 match ip dst 0.0.0.0/0 flowid 1:30
share|improve this question

1 Answer 1

Short Answer

Probably best to set the ceiling to (maybe just below) the maximum speed that the WAN interface will deliver traffic to your shaping device.

Theory and Explanation (and why a ceiling is required)

I note from your script that you are shaping inbound (ingress) traffic. Ideally, it would be best if the shaping could be applied at the source of the traffic (the ISP) before it hits your device. This is because, for inbound traffic, you effectively have no control over how it arrives to you. You can control it once it does reach you, which effectively helps manage traffic to an extent (and I appreciate this is what you are trying to do) but it's not strictly the "correct" way to be doing things.

But back to your original question. I will answer based on a setup using egress (outbound) shaping, which is not what you are doing, but hopefully it will put things in context. The main reason that a ceiling is required is due to some limit on the next medium/hop/whatever that the traffic is going to or being passed on to. Any device that receives/sends traffic will have a receive/send buffer that becomes full if the traffic rate reaches the maximum speed the medium can handle, or various buffers become full, at which point, latency starts creeping in, along with packet loss.

To solve this, if shaping is introduced and rate limited to just below the next medium's speed (and this shaping is applied correctly, that is, the correct rules are setup to match the protocols being used), this then improves the overall fluidity of the traffic flow. If shaping is applied but not limited to the next medium's maximum speed, any shaping that was applied previously is then lost and ultimately rendered useless because the receive/send buffer of that medium starts queuing and undoing all the hard work your kit did previously to shape it. This is why a ceiling is required; the shaper needs to know how much traffic it can pass onto the next step, without causing the next medium to upset its nicely packed (shaped) apple cart.

As for ingress shaping (which is what you are doing here), I hope you can now see that, effectively, the ceiling basically needs to be set at a sensible value if, and only if, the medium you are forwarding ingress traffic onto (the LAN) is slower than the maximum traffic rate arriving on the WAN side. This is about the only instance I can think of where shaping will truly help your situation. But I suspect, like most internet connections currently, the WAN speed is far slower than the LAN speed, so basically, the ceiling can be set to any sensible value you like (the speed of the LAN interface is probably a good choice) - but, having said that, it might make more sense to set the ceiling to just below the maximum rate of the WAN's arrival (download) speed. Doing this will mitigate the tendency for traffic to be queued at the ISP side because the shaper will slow and pacify traffic keeping it in check (like TCP connections, where the TCP protocol inherently tries to keep increasing speed up to the maximum rate possible during a transfer). This hopefully means intelligent queuing and shaping remains mostly managed by your shaper, rather than being first intercepted by any dumb limiting equipment at the ISP.

I have a HOWTO on traffic shaping which I wrote some years ago: http://phix.me/dm/ - many people have found this useful, including a chap in the US who has a MikroTik router and applied my methodologies onto his router, which consequently resolved every single traffic issue he was experiencing, from slow DNS lookups to jittery SSH sessions whilst torrenting etc etc. I use the same principles on my currently routed broadband setup also. Do note however that my HOWTO specifically talks about egress shaping, and does not touch ingress at all. The main reason for this is that I, personally, have no need for ingress shaping, and I realised (when researching all this years ago) that I have no control over inbound traffic that arrives to me (as I said earlier). I have recently gone with an ISP that offers some clever shaping their side, so coupled with my outbound shaping policies, and their basic inbound shaping policies, I know I probably have one of the slickest internet connections possible.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.