From: Stef Coene <stef.coene@docum.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Am I correct?
Date: Wed, 18 Dec 2002 21:32:40 +0000 [thread overview]
Message-ID: <marc-lartc-104024724330110@msgid-missing> (raw)
In-Reply-To: <marc-lartc-104024602828802@msgid-missing>
On Wednesday 18 December 2002 22:12, LARTC@VLMINTERNATIONAL.COM wrote:
> I've got some customers that have lots of bandwidth that are uploading and
> downloading files to our https:// help desk and are using up all of my T-1
> at times. This leaves other customers sucking wind. I've taken a look at
> the '15.10. Example of a full nat solution with QoS' section. Would it work
> for me if I change the section that says eth0 to my internet adapter
> Serial0? If I can do that, will that allow fair sharing between all my
> customers of the https:// help desk?
>
> My setup:
>
> ////////// ///////////////// ///////
> https:// |-- |eth0 * Serial0 |-- |INET |
> ////////// ///////////////// ///////
>
> My proposed script:
>
> CEIL=1020 # actual is 1024Kbit
> IFACE=Serial0
>
> tc qdisc add dev $IFACE root handle 1: htb default 15
> tc class add dev $IFACE parent 1: classid 1:1 htb rate ${CEIL}kbit ceil
> ${CEIL}kbit
> tc class add dev $IFACE parent 1:1 classid 1:10 htb rate 170kbit ceil
> 170kbit prio 0
> tc class add dev $IFACE parent 1:1 classid 1:11 htb rate 170kbit ceil
> ${CEIL}kbit prio 1
> tc class add dev $IFACE parent 1:1 classid 1:12 htb rate 170kbit ceil
> ${CEIL}kbit prio 2
> tc class add dev $IFACE parent 1:1 classid 1:13 htb rate 170kbit ceil
> ${CEIL}kbit prio 2
> tc class add dev $IFACE parent 1:1 classid 1:14 htb rate 170kbit ceil
> ${CEIL}kbit prio 3
> tc class add dev $IFACE parent 1:1 classid 1:15 htb rate 170kbit ceil
> ${CEIL}kbit prio 3
>
> tc qdisc add dev $IFACE parent 1:12 handle 120: sfq perturb 10
> tc qdisc add dev $IFACE parent 1:13 handle 130: sfq perturb 10
> tc qdisc add dev $IFACE parent 1:14 handle 140: sfq perturb 10
> tc qdisc add dev $IFACE parent 1:15 handle 150: sfq perturb 10
>
> tc filter add dev $IFACE parent 1:0 protocol ip prio 1 handle 1 fw classid
> 1:10
> tc filter add dev $IFACE parent 1:0 protocol ip prio 2 handle 2 fw classid
> 1:11
> tc filter add dev $IFACE parent 1:0 protocol ip prio 3 handle 3 fw classid
> 1:12
> tc filter add dev $IFACE parent 1:0 protocol ip prio 4 handle 4 fw classid
> 1:13
> tc filter add dev $IFACE parent 1:0 protocol ip prio 5 handle 5 fw classid
> 1:14
> tc filter add dev $IFACE parent 1:0 protocol ip prio 6 handle 6 fw classid
> 1:15
>
> iptables -t mangle -I PREROUTING -p icmp -j MARK --set-mark 0x1
> iptables -t mangle -I PREROUTING -p icmp -j RETURN
> iptables -t mangle -I PREROUTING -p tcp -m tcp --sport ssh -j
> MARK --set-mark 0x1
> iptables -t mangle -I PREROUTING -p tcp -m tcp --sport ssh -j RETURN
> iptables -t mangle -I PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK
> SYN -j MARK --set-mark 0x1
> iptables -t mangle -I PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK
> SYN -j RETURN
> iptables -t mangle -I PREROUTING -p tcp -m tcp --sport https -j
> MARK --set-mark 0x3
> iptables -t mangle -I PREROUTING -p tcp -m tcp --sport https -j RETURN
>
> iptables -t mangle -I PREROUTING -m tos --tos Minimize-Delay -j
> MARK --set-mark 0x1
> iptables -t mangle -I PREROUTING -m tos --tos Minimize-Delay -j RETURN
> iptables -t mangle -I PREROUTING -m tos --tos Minimize-Cost -j
> MARK --set-mark 0x5
> iptables -t mangle -I PREROUTING -m tos --tos Minimize-Cost -j RETURN
> iptables -t mangle -I PREROUTING -m tos --tos Maximize-Throughput -j
> MARK --set-mark 0x6
> iptables -t mangle -I PREROUTING -m tos --tos Maximize-Throughput -j RETURN
>
> Thanks in advance for any suggestions
I think this is a good script.
But different prio's for filters are not usefull. They only determine the
order the filters are matched. And in your case, there is no specific order.
In fact, if you add 1 fw filter with no handle parameter, the mark will be
used as filter key. So packets marked with 16 will end up in class 1:16. I
think this will save more CPU cycles.
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
prev parent reply other threads:[~2002-12-18 21:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-18 21:12 [LARTC] Am I correct? LARTC
2002-12-18 21:32 ` Stef Coene [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-104024724330110@msgid-missing \
--to=stef.coene@docum.org \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox