system toolbox » router

http://wiki.openwrt.org/MiniHowtos/QoSHowto

A qos script that really works!

Be sure to set the upload and download rate (slightly) lower than your ADSL or Cable rates to keep modem and ISP queues from filling up, killing interactivity. My measured download and upload rates are 900kb/s and 300kb/s respectively. Setting the speeds in the script to 800kb/s and 280kb/s did the trick.

#!/bin/sh

DEBUG=0

# To enable logging (requires iptables-mod-extra package)
[ $DEBUG -eq 1 ] && insmod ipt_LOG >&- 2>&-

#######################################################
DOWNLOAD=800
UPLOAD=280
D=100
BURST=1000

TCP_BULK="1024:" 
UDP_BULK="1024:" 

TCP_PRIO="22 23 53 80 443" 
UDP_PRIO="53" 

#BULK_PROTOS="edonkey bittorrent" 
#######################################################

WAN=$(nvram get wan_ifname)
LAN=$(nvram get lan_ifname)

U_M1_PRIO=$(($UPLOAD*90/100))
U_M1_NORM=$(($UPLOAD*10/100))
U_M1_BULK=$(($UPLOAD* 0/100))

U_M2_PRIO=$(($UPLOAD*50/100))
U_M2_NORM=$(($UPLOAD*30/100))
U_M2_BULK=$(($UPLOAD*20/100))

D_BURST=$(($BURST*$DOWNLOAD/8))

insmod cls_fw >&- 2>&-
insmod sch_hfsc >&- 2>&-
insmod sch_htb >&- 2>&-
insmod ipt_CONNMARK >&- 2>&-
insmod ipt_length >&- 2>&-
insmod ipt_limit >&- 2>&-
insmod ipt_tos >&- 2>&-
#insmod sch_ingress >&- 2>&-
#insmod ipt_layer7 >&- 2>&-
#insmod ipt_ipp2p >&- 2>&-
#insmod ipt_multiport >&- 2>&-
#insmod cls_u32 >&- 2>&-

iptables -t mangle -F
iptables -t mangle -X

tc qdisc del dev $WAN root >&- 2>&-
tc qdisc add dev $WAN root handle 1: hfsc default 30
tc class add dev $WAN parent 1: classid 1:1 hfsc sc rate ${UPLOAD}kbit ul rate ${UPLOAD}kbit
tc class add dev $WAN parent 1:1 classid 1:10 hfsc sc m1 ${U_M1_PRIO}kbit d ${D}ms m2 ${U_M2_PRIO}kbit ul rate ${UPLOAD}kbit
tc class add dev $WAN parent 1:1 classid 1:20 hfsc sc m1 ${U_M1_NORM}kbit d ${D}ms m2 ${U_M2_NORM}kbit ul rate ${UPLOAD}kbit
tc class add dev $WAN parent 1:1 classid 1:30 hfsc sc m1 ${U_M1_BULK}kbit d ${D}ms m2 ${U_M2_BULK}kbit ul rate ${UPLOAD}kbit
tc filter add dev $WAN parent 1: prio 1 protocol ip handle 1 fw flowid 1:10
tc filter add dev $WAN parent 1: prio 2 protocol ip handle 2 fw flowid 1:20
tc filter add dev $WAN parent 1: prio 3 protocol ip handle 3 fw flowid 1:30

#tc qdisc del dev $WAN ingress >&- 2>&-
#tc qdisc add dev $WAN handle ffff: ingress
#tc filter add dev $WAN parent ffff: protocol ip prio 50 handle 3 fw police rate $(($DOWNLOAD/2))kbit burst $D_BURST drop flowid :1
#tc filter add dev $WAN parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate $(($DOWNLOAD))kbit burst $D_BURST drop flowid :1

tc qdisc del dev $LAN root >&- 2>&-
# htb qdisc without default: all unmarked (mark 0) packages pass unlimited
tc qdisc add dev $LAN root handle 1: htb
tc class add dev $LAN parent 1: classid 1:1 htb rate ${DOWNLOAD}kbit ceil ${DOWNLOAD}kbit burst $D_BURST cburst $D_BURST
tc class add dev $LAN parent 1:1 classid 1:10 htb rate $(($DOWNLOAD*8/10))kbit ceil ${DOWNLOAD}kbit burst $D_BURST cburst $D_BURST prio 0
tc class add dev $LAN parent 1:1 classid 1:20 htb rate $(($DOWNLOAD*2/10))kbit ceil $(($DOWNLOAD/2))kbit burst $D_BURST cburst $D_BURST prio 1
tc filter add dev $LAN parent 1: prio 1 protocol ip handle 1 fw flowid 1:10
tc filter add dev $LAN parent 1: prio 2 protocol ip handle 2 fw flowid 1:10
tc filter add dev $LAN parent 1: prio 3 protocol ip handle 3 fw flowid 1:20

iptables -t mangle -N mark_chain
iptables -t mangle -N ingress_chain

iptables -t mangle -A POSTROUTING -o $WAN -j mark_chain
iptables -t mangle -A PREROUTING -i $WAN -j ingress_chain

###################################### INGRESS CHAIN #################################################
# Restore any saved connection mark
iptables -t mangle -A ingress_chain -j CONNMARK --restore-mark

# Default is normal priority (to make sure every packet on wan interface gets marked)
iptables -t mangle -A ingress_chain -m mark --mark 0 -j MARK --set-mark 2

# Mark *any* p2p package (first package in connection only)
#iptables -t mangle -A ingress_chain -m mark --mark 0 -m ipp2p --ipp2p -j MARK --set-mark 1

# Mark bulk packets according to Layer 7 match. Works for first package only!
#for PROTO in $BULK_PROTOS; do
#  iptables -t mangle -A ingress_chain -m mark --mark 0 -m layer7 --l7proto $PROTO -j MARK --set-mark 1
#done

# Save mark onto connection
#iptables -t mangle -A ingress_chain -j CONNMARK --save-mark
######################################################################################################

######################################## MARK CHAIN ##################################################
# Restore any saved connection mark
iptables -t mangle -A mark_chain -j CONNMARK --restore-mark

# Mark prio packets based on port numbers and protocol
for PORT in $UDP_PRIO; do
  iptables -t mangle -A mark_chain -m mark --mark 0 -p udp --dport $PORT -j MARK --set-mark 1
done
for PORT in $TCP_PRIO; do
  iptables -t mangle -A mark_chain -m mark --mark 0 -p tcp --dport $PORT -j MARK --set-mark 1
done

# Mark bulk packets based on port numbers and protocol
for PORT in $UDP_BULK; do
  iptables -t mangle -A mark_chain -m mark --mark 0 -p udp --dport $PORT -j MARK --set-mark 3
done
for PORT in $TCP_BULK; do
  iptables -t mangle -A mark_chain -m mark --mark 0 -p tcp --dport $PORT -j MARK --set-mark 3
done

# Save mark onto connection
iptables -t mangle -A mark_chain -j CONNMARK --save-mark

# Make sure ACK packets get priority
iptables -t mangle -A mark_chain -p tcp -m length --length :128 --tcp-flags SYN,RST,ACK ACK -j MARK --set-mark 1

# Default is normal priority
iptables -t mangle -A mark_chain -m mark --mark 0 -j MARK --set-mark 2
######################################################################################################

[ $DEBUG -eq 1 ] && iptables -t mangle -A mark_chain -m mark --mark 0 -j LOG --log-prefix mark_0::
[ $DEBUG -eq 1 ] && iptables -t mangle -A mark_chain -m mark --mark 0 -j ACCEPT
[ $DEBUG -eq 1 ] && iptables -t mangle -A mark_chain -m mark --mark 1 -j LOG --log-prefix mark_1::
[ $DEBUG -eq 1 ] && iptables -t mangle -A mark_chain -m mark --mark 1 -j ACCEPT
[ $DEBUG -eq 1 ] && iptables -t mangle -A mark_chain -m mark --mark 2 -j LOG --log-prefix mark_2::
[ $DEBUG -eq 1 ] && iptables -t mangle -A mark_chain -m mark --mark 2 -j ACCEPT
[ $DEBUG -eq 1 ] && iptables -t mangle -A mark_chain -m mark --mark 3 -j LOG --log-prefix mark_3::
[ $DEBUG -eq 1 ] && iptables -t mangle -A mark_chain -m mark --mark 3 -j ACCEPT
[ $DEBUG -eq 1 ] && iptables -t mangle -A mark_chain -j LOG --log-prefix mark_other::

[ $DEBUG -eq 1 ] && iptables -t mangle -A ingress_chain -m mark --mark 0 -j LOG --log-prefix ingress_0::
[ $DEBUG -eq 1 ] && iptables -t mangle -A ingress_chain -m mark --mark 0 -j ACCEPT
[ $DEBUG -eq 1 ] && iptables -t mangle -A ingress_chain -m mark --mark 1 -j LOG --log-prefix ingress_1::
[ $DEBUG -eq 1 ] && iptables -t mangle -A ingress_chain -m mark --mark 1 -j ACCEPT
[ $DEBUG -eq 1 ] && iptables -t mangle -A ingress_chain -m mark --mark 2 -j LOG --log-prefix ingress_2::
[ $DEBUG -eq 1 ] && iptables -t mangle -A ingress_chain -m mark --mark 2 -j ACCEPT
[ $DEBUG -eq 1 ] && iptables -t mangle -A ingress_chain -m mark --mark 3 -j LOG --log-prefix ingress_3::
[ $DEBUG -eq 1 ] && iptables -t mangle -A ingress_chain -m mark --mark 3 -j ACCEPT
[ $DEBUG -eq 1 ] && iptables -t mangle -A ingress_chain -j LOG --log-prefix ingress_other::

http://www.voip-info.org/wiki/view/Asterisk+QoS

http://www.voip-info.org/wiki/view/QoS+Linux

#!/bin/sh

TCOP="add" 
IPTOP="-A" 

if [ "$1" == "stop" ]; then
       echo "Stopping..." 
       TCOP="del" 
       IPTOP="-D" 
fi

#          +---------+
#          | root 1: |
#          +---------+
#               |
# +----------------------------+
# |         class 1:1          |
# +----------------------------+
#   |           |           |
# +----+      +----+      +----+
# |1:10|      |1:20|      |1:30|
# +----+      +----+      +----+
#               |
#      +--------+--------+
#      |        |        |
#   +-----+  +-----+  +-----+
#   |1:100|  |1:101|  |1:102|
#   +-----+  +-----+  +-----+

# 1:10 is the class for VOIP traffic, pfifo qdisc
# 1:20 is for bulk traffic (htb, leaves use sfq)
# 1:30 is the class that interactive and TCP SYN/ACK traffic (sfq qdisc)

# 1:20 is further split up into different kinds of bulk traffic: web, mail and
# everything else.  1:100-102 fight amongst themselves for their slice of excess
# bandwidth, and in turn 1:10,20 and 30 then fight for any excess above their
# minimum rates.

# which interface to throw all this on (DSL)
IF=eth2

# ceil is 75% of max rate (768kbps)
# rate is 65% of max rate
# we don't let it go to 100% because we don't want the DSL modem (Pairgain MegaBit Modem 300S)
# to have a ton of packets in their buffers.  *we* want to do the buffering.
RATE=576
CEIL=640
#RATE=450
#CEIL=500

tc qdisc ${TCOP} dev ${IF} root handle 1: htb default 102
tc class ${TCOP} dev ${IF} parent 1:   classid 1:1 htb rate ${RATE}kbit ceil ${CEIL}kbit

tc class ${TCOP} dev ${IF} parent 1:1  classid 1:10 htb rate 64kbit ceil ${RATE}kbit prio 1
tc class ${TCOP} dev ${IF} parent 1:1  classid 1:20 htb rate 64kbit ceil ${RATE}kbit prio 2

tc class ${TCOP} dev ${IF} parent 1:20 classid 1:100 htb rate ${RATE}kbit
tc class ${TCOP} dev ${IF} parent 1:20 classid 1:101 htb rate ${RATE}kbit
tc class ${TCOP} dev ${IF} parent 1:20 classid 1:102 htb rate ${RATE}kbit

tc qdisc ${TCOP} dev ${IF} parent 1:10  handle 10:  pfifo
tc qdisc ${TCOP} dev ${IF} parent 1:100 handle 100: sfq perturb 10
tc qdisc ${TCOP} dev ${IF} parent 1:101 handle 101: sfq perturb 10
tc qdisc ${TCOP} dev ${IF} parent 1:102 handle 102: sfq perturb 10

tc filter ${TCOP} dev ${IF} parent 1:0 protocol ip prio 1 handle 1 fw classid 1:10   <<<<<<<<<< prioritet 1
tc filter ${TCOP} dev ${IF} parent 1:0 protocol ip prio 4 handle 4 fw classid 1:100  <<<<<<<<<< prioritet 4

# IAX2 prio 0.
iptables -t mangle ${IPTOP} PREROUTING -p udp -m udp --dport 4569 -j MARK --set-mark 0x1   <<<<<<<<<<<<< markiranje IAX-a
iptables -t mangle ${IPTOP} PREROUTING -p udp -m udp --dport 4569 -j RETURN

# everything else goes into lowest priority (best effort).
iptables -t mangle ${IPTOP} PREROUTING -j MARK --set-mark 0x4  <<<<<<<<<<<<<<<<< ostali saobracaj
iptables -t mangle ${IPTOP} OUTPUT -j MARK --set-mark 0x4

e sad ja sam ovaj paket instalirao

root@router-wan-sa-1:~# ipkg files dsl-qos-queue

Package dsl-qos-queue (0.9.3-1) is installed on root and has the following files:
/
/usr/
/usr/sbin/
/usr/sbin/dsl_qos_queue
/usr/sbin/ipt_rules
/usr/sbin/dsl_qos_train

Done.

treba vidjeti šta on radi

VoIP through VPN

Sean Atkinson sean at netproject.com
Wed May 19 07:14:59 PDT 2004

    * Previous message: [adsl-qos] ISP is the bottleneck
    * Next message: [adsl-qos] VoIP through VPN
    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi,

I'm trying to add quality of service to voice-over-IP packets through
our virtual private network.

We have an OpenVPN server with several remote clients tunnelling through
it, and amongst other things it helps makes NAT, routing and encryption
of VoIP packets easier, although it introduces extra latency with the
additional hop.  It runs on a gateway machine with local ADSL (ppp0),
LAN (eth0), and a VPN interface per client (e.g. tun0).

Following the README, I'm using the following configuration:

iptables -t mangle -I POSTROUTING -o ppp0 -j MYSHAPER-OUT
iptables -t mangle -A MYSHAPER-OUT -j MARK -p udp --sport 5001
--set-mark 20
iptables -t mangle -A MYSHAPER-OUT -j MARK -p udp --dport 5001
--set-mark 20
iptables -t mangle -A MYSHAPER-OUT -j MARK -p udp --sport 5005
--set-mark 20
iptables -t mangle -A MYSHAPER-OUT -j MARK -p udp --dport 5005
--set-mark 20
iptables -t mangle -A MYSHAPER-OUT -j MARK -m mark --mark 0 --set-mark
26

I'm using ppp0 instead of eth0 since the media channel is between 2
remote VPN peers, so the LAN shouldn't be involved.  OpenVPN is
configured to use UDP port 5001 for one peer, and 5005 for another.  I
use similar rules for eth0 on both VPN peers.

This all appears to be accepted, and the daemons start fine.  However I
notice that the peer PID in /proc/net/ip_queue is always a few below the
live PID.  Also the queue length is always 0, even during active
traffic.

I've tested voice data with Gnomemeeting between VPN peers, listening to
the output and watching the real-time TX/RX graphs while saturating the
link with "yes" output through SSH.  Unfortunately I can't notice any
difference in performance with or without the queue - in both cases the
sound breaks and packet plots jump all over the place.

Am I missing something with how I should use this, or is there some
better way of doing this?

Thanks,

Sean.

ovo je odgovor na predhodni upit:

> difference in performance with or without the queue - in both cases the
> sound breaks and packet plots jump all over the place.
> 
> Am I missing something with how I should use this, or is there some
> better way of doing this?

Are you placing the VoIP traffic in a higher priority band than the SSH 
traffic you were sending?  If you have them in the same band then it 
defeats the purpose.  I would think that VoIP should probably go in band 
1 (with band zero being the ping-only band).  This is in a scheme with 
the lower numbered bands having highest priority.

I've never used dsl_qos_queue for VoIP but it should work just fine. 
Does VoIP use UDP or TCP?  Truthfully, it shouldn't matter, as long as 
the network layer protocol is IP - you can classify it into bands with 
ipfilter.

-Dan

http://www.ibiblio.org/pub/Linux/docs/HOWTO/ADSL-Bandwidth-Management-HOWTO

...

In order to keep things simple, all references to network devices and
configuration in this document will be with respect to the following network
layout diagram:

+----------------------------------------------------------------------------+
|               <-- 128kbit/s      --------------     <-- 10Mbit -->         |
|  Internet <--------------------> | ADSL Modem | <--------------------      |
|                1.5Mbit/s -->     --------------                     |      |
|                                                                     | eth0 |
|                                                                     V      |
|                                                         -----------------  |
|                                                         |               |  |
|                                                         | Linux Router  |  |
|                                                         |               |  |
|                                                         -----------------  |
|                                                          | .. | eth1..ethN |
|                                                          |    |            |
|                                                          V    V            |
|                                                                            |
|                                                       Local Network        |
|                                                                            |
+----------------------------------------------------------------------------+
-----------------------------------------------------------------------------

2.3. Packet Queues

Packet queues are buckets that hold data for a network device when it can't
be immediately sent. Most packet queues use a FIFO (first in, first out) discipline unless they've been specially configured to do otherwise. What this means is that when the packet queue for a device is completely full, the
packet most recently placed in the queue will be sent over the device only after all the other packets in the queue at that time have been sent.

2.3.1. The Upstream

With an ADSL modem, bandwidth is asymmetric with 1.5Mbit/s typical downstream and 128kbit/sec typical upstream. Although this is the line speed, the
interface between the Linux Router PC and the ADSL modem is typically at or above 10Mbit/s. If the interface to the Local Network is also 10Mbit/s, there
will typically be NO QUEUING at the router when packets are sent from the Local Network to the Internet. Packets are sent out eth0 as fast as they are
received from the Local Network. Instead, packets are queued at the ADSL modem since they are arriving at 10Mbit/s and only being sent at 128kbit/s.
Eventually the packet queue at the ADSL modem will become full and any more packets sent to it will be silently dropped. TCP is designed to handle this and will adjust it's transmit window size accordingly to take full advantage of the available bandwidth.

While packet queues combined with TCP result in the most effective use of bandwidth, large FIFO queues can increase the latency for interactive
traffic.

Another type of queue that is somewhat like FIFO is an n-band priority queue. However, instead of having just one queue that packets line up in, the n-band priority queue has n FIFO queues which packets are placed in by their classification. Each queue has a priority and packets are always dequeued
from the highest priority queue that contains packets. Using this discipline FTP packets can be placed in a lower priority queue than telnet packets so
that even during an FTP upload, a single telnet packet will jump the queue and be sent immediately.

This document has been revised to use a new queue in linux called the Hierarchical Token Bucket (HTB). The HTB queue is much like the n-band queue
described above, but it has the capability to limit the rate of traffic in each class. In addition to this, it has the ability to set up classes of
traffic beneath other classes creating a hierarchy of classes. Fully describing HTB is beyond the scope of this document, but more information can
be found at http://www.lartc.org

...

nađoh i html verziju gornjeg dokumenta http://www.faqs.org/docs/Linux-HOWTO/ADSL-Bandwidth-Management-HOWTO.html

tc instalacija

root@router-wan-sa-1:~# ipkg install -d net tc

Installing tc (2.6.20-070313-1) to net...
Downloading http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/brcm-2.4/packages/./tc_2.6.20-070313-1_mipsel.ipk
Nothing to be done
Done.
Collected errors:
Package tc md5sum mismatch. Either the ipkg or the package index are corrupt. Try 'ipkg update'.

root@router-wan-sa-1:~# ipkg update

Downloading http://openwrt.bring.out.ba/packages/brcm-2.4/Packages
Updated list of available packages in /usr/lib/ipkg/lists/b-out-ba
Downloading http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/brcm-2.4/packages/Packages
Updated list of available packages in /usr/lib/ipkg/lists/X-Wrt
Done.

root@router-wan-sa-1:~# ipkg install -d net tc

Installing tc (2.6.25-1) to net...
Downloading http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/brcm-2.4/packages/./tc_2.6.25-1_mipsel.ipk
Configuring tc
Done.

e sad kako sam shvatio tc je jedna varijanta, a dsl_qos_queue je druga varijanta podešenja QoS-a

nisam mogao uloviti šta raja više voli ... međutim u većini slučajeva pominje se tc kao alat za klasifikaciju saobraćaja

sad nešto razmišljam, a kako mjerivit saobraćaj, ako tog alata nemamo instaliranog na router-u ?

vjerovatno treba sav saobraćaj nekako usmjeriti na mjerni linux router na kojem ćemo instalirati recimo wireshark

home page dsl_qos_queue-a

This program implements a user space QUEUE processor which controls outbound traffic over a DSL modem using a pseudo- token-bucket-filter style queue with starvation protection.

Main feature of this outbound rate limiter is it's ability to rate limit based on the calculated raw bandwidth used rather than just the IP bandwidth used. This provides a MUCH more accurate way to prevent packet queueing in the network device (in this case, ADSL modem).

• This has been tested on Redhat 7.3.
• You must be using iptables.
• You must have libipq installed to compile. (attempting to avoid this requirement by supplying my compiled libipq.a in the distribution package.)
• Package now includes a compiled binary for i386 Linux 2.4.x
• Version 0.9.3 updated to improve stability. See README for more details.
• Download here: dsl_qos_queue-0.9.3.tar.gz - v0.9.3
• If you're trying to control bandwidth in Windows, try this: http://www.bandwidthcontroller.com

Miracleshaper¶

What is it?¶

• Processes both up- and downstream.
• Accounts for the encapsulation overhead on DSLs.
• Achieves MTU granularity for IP packets bigger than the MTU.
• Does automatic configuration parameter switching based on the encountered traffic.
• Allows for joint shaping of multiple PPPoE sessions.
• Enables the use of multiple PPPoE sessions on a single DSL even when only one session per MAC address is allowed.
• Can do ECN marking.
• Works in userspace, interfaces to the kernel networking code through tap interfaces and a packet socket.
• Is configured in the sourcecode, so you should know a little C if you want to use it.
• Was written on i386 Linux, but should be easily portable to other architectures as well as operating systems.

...

Achieves MTU Granularity for IP Packets Bigger than the MTU¶

As the Miracleshaper processes link-layer frames rather than network-layer packets, it in particular sees IP packets when they are already fragmented. This means that if someone, for some reason, decides to send an IP packet that's larger than the PPP interface's MTU, the Miracleshaper can let slip through some high-priority packet in between the fragments of the oversized packet, thus guaranteeing that the line cannot be blocked by low-priority traffic for longer than one MTU worth of data takes to transfer. This in particular is a potential problem with dsl_qos_queue, which does the prioritization at the network layer.

ADSL Bandwidth management¶

14.10.2007

1. Introduction¶

The purpose of this document is to suggest a way to manage outbound traffic on an ADSL (or cable modem) connection to the Internet. The problem is that many ADSL lines are limited in the neighborhood of 128kbps for upstream data transfer. Aggravating this problem is the packet queue in the ADSL modem which can take 2 to 3 seconds to empty when full. Together this means that when the upstream bandwidth is fully saturated it can take up to 3 seconds for any other packets to get out to the Internet. This can cripple interactive applications such as telnet and multi-player games.

1.1. New Versions of This Document¶

You can always view the latest version of this document on the World Wide Web at the URL: http://www.tldp.org.

New versions of this document will also be uploaded to various Linux WWW and FTP sites, including the LDP home page at http://www.tldp.org.

...

3. How it Works¶

There are two basic steps to optimize upstream bandwidth. First we have to find a way to prevent the ADSL modem from queuing packets since we have no control over how it handles the queue. In order to do this we will throttle the amount of data the router sends out eth0 to be slightly less than the total upstream bandwidth of the ADSL modem. This will result in the router having to queue packets that arrive from the Local Network faster than it is allowed to send them .

The second step is to set up priority queuing discipline on the router. We'll investigate a queue that can be configured to give priority to interactive traffic such as telnet and multi-player games.

By using the HTB queue we can accomplish bandwidth shaping and priority queuing at the same time while also assuring that no priority class is starved by another. Avoiding starvation wasn't possible using the method outlined in the 0.1 revision of this document.

The final step is to configure the firewall to prioritize packets by using fwmark.

...

3.5.1. Why Inbound Traffic Limiting isn't all That Good¶

We want to limit our inbound traffic to avoid filling up the queue at the ISP, which can sometimes buffer as much as 5 seconds worth of data. The problem is that currently the only way to limit inbound TCP traffic is to drop perfectly good packets. These packets have already taking up some share of bandwidth on the ADSL modem only to be dropped by the Linux box in an effort to slow down future packets. These dropped packets will eventually be retransmitted consuming more bandwidth. When we limit traffic, we are limiting the rate of packets which we will accept into our network. Since the actual inbound data rate is somewhere above this because of the packets we drop, we'll actually have to limit our downstream to much lower than the actual rate of the ADSL modem in order to assure low latency. In practice I had to limit my 1.5mbit/s downstream ADSL to 700kbit/sec in order to keep the latency acceptable with 5 concurrent downloads. The more TCP sessions you have, the more bandwidth you'll waste with dropped packets, and the lower you'll have to set your limit rate.

A much better way to control inbound TCP traffic would be TCP window manipulation, but as of this writing there exists no (free) implementation of it for Linux (that I know of...).

4.1. Caveats¶

Limiting the actual rate of data sent to the DSL modem is not as simple as it may seem. Most DSL modems are really just ethernet bridges that bridge data back and forth between your linux box and the gateway at your ISP. Most DSL modems use ATM as a link layer to send data. ATM sends data in cells that are always 53 bytes long. 5 of these bytes are header information, leaving 48 bytes available for data. Even if you are sending 1 byte of data, an entire 53 bytes of bandwidth are consumed sent since ATM cells are always 53 bytes long. This means that if you are sending a typical TCP ACK packet which consists of 0 bytes data + 20 bytes TCP header + 20 bytes IP header + 18 bytes Ethernet header. In actuality, even though the ethernet packet you are sending has only 40 bytes of payload (TCP and IP header), the* minimum payload for an Ethernet packet is 46 bytes of data, so the remaining 6 bytes are padded with nulls*. This means that the actual length of the Ethernet packet plus header is 18 + 46 = 64 bytes. In order to send 64 bytes over ATM, you have to send two ATM cells which consume 106 bytes of bandwidth. This means for every TCP ACK packet, you're wasting 42 bytes of bandwidth. This would be okay if Linux accounted for the encapsulation that the DSL modem uses, but instead, Linux only accounts the TCP header, IP header, and 14 bytes of the MAC address (Linux doesn't count the 4 bytes CRC since this is handled at the hardware level). Linux doesn't count the minimum Ethernet packet size of 46 bytes, nor does it take into account the fixed ATM cell size.

What all of this means is that you'll have to limit your outbound bandwidth to somewhat less than your true capacity (until we can figure out a packet scheduler that can account for the various types of encapsulation being used). You may find that you've figured out a good number to limit your bandwidth to, but then you download a big file and the latency starts to shoot up over 3 seconds. This is most likely because the bandwidth those small ACK packets consume is being miscalculated by Linux.

I have been working on a solution to this problem for a few months and have almost settled on a solution that I will soon release to the public for further testing. The solution involves using a user-space queue instead of linux's QoS to rate-limit packets. I've basically implemented a simple HTB queue using linux user-space queues. This solution (so far) has been able to regulate outbound traffic SO WELL that even during a massive bulk download (several streams) and bulk upload (gnutella, several streams) the latency PEAKS at 400ms over my nominal no-traffic latency of about 15ms. For more information on this QoS method, subscribe to the email list for updates or check back on updates to this HOWTO.

evo skripte koja se pominje

#!/bin/bash
# add MYSHAPER-OUT chain to the mangle table in iptables - this sets up the table we'll use
#                                                      to filter and mark packets.

DEV=eth0

# Reset everything to a known state (cleared)
iptables -t mangle -D POSTROUTING -o $DEV -j MYSHAPER-OUT 2> /dev/null > /dev/null
iptables -t mangle -F MYSHAPER-OUT 2> /dev/null > /dev/null
iptables -t mangle -X MYSHAPER-OUT 2> /dev/null > /dev/null

if [ "$1" != "install" ] 
then 
        exit
fi

iptables -t mangle -N MYSHAPER-OUT
iptables -t mangle -I POSTROUTING -o $DEV -j MYSHAPER-OUT

# add fwmark entries to classify different types of traffic - Set fwmark from 20-26 according to
#                                                             desired class. 20 is highest prio.
iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 0:1024 -j MARK --set-mark 23 # Default for low port traffic 
iptables -t mangle -A MYSHAPER-OUT -p tcp --dport 0:1024 -j MARK --set-mark 23 # "" 
iptables -t mangle -A MYSHAPER-OUT -p tcp --dport 20 -j MARK --set-mark 26     # ftp-data port, low prio
iptables -t mangle -A MYSHAPER-OUT -p tcp --dport 5190 -j MARK --set-mark 23   # aol instant messenger
iptables -t mangle -A MYSHAPER-OUT -p icmp -j MARK --set-mark 20               # ICMP (ping) - high prio, impress friends
iptables -t mangle -A MYSHAPER-OUT -p udp --dport 123 -j MARK --set-mark 20    # NTP should be low-lag
iptables -t mangle -A MYSHAPER-OUT -p udp --dport 53 -j MARK --set-mark 21     # DNS name resolution (small packets)
iptables -t mangle -A MYSHAPER-OUT -p tcp --dport ssh -j MARK --set-mark 22    # secure shell
iptables -t mangle -A MYSHAPER-OUT -p tcp --sport ssh -j MARK --set-mark 22    # secure shell
iptables -t mangle -A MYSHAPER-OUT -p tcp --dport telnet -j MARK --set-mark 22 # telnet (ew...)
iptables -t mangle -A MYSHAPER-OUT -p tcp --sport telnet -j MARK --set-mark 22 # telnet (ew...)
iptables -t mangle -A MYSHAPER-OUT -p ipv6-crypt -j MARK --set-mark 24         # IPSec - we dont know what the payload is though...
iptables -t mangle -A MYSHAPER-OUT -p udp --dport 10000 -j MARK --set-mark 24  # IPSec (udp tunnel) - we dont know what the payload is though...

iptables -t mangle -A MYSHAPER-OUT -p tcp --sport http -j MARK --set-mark 25   # Local web server
iptables -t mangle -A MYSHAPER-OUT -p tcp -m length --length :64 -j MARK --set-mark 21 # small packets (probably just ACKs)
iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 3389 -j MARK --set-mark 23   # windows remote computer connection
iptables -t mangle -A MYSHAPER-OUT -m mark --mark 0 -j MARK --set-mark 26      # redundant- mark any unmarked packets as 26 (low pri

znači ova skripta uz pomoć iptables/mangle markira pakete, a protokol se određuje sa source port-om.

baš ne kontam, kako se ovdje utvrđuje šta je upload a šta download saobraćaj ??

pogledajmo postojeće stanje na našem router-u vezano za vanjski voip saobraćaj
root@router-wan-sa-1:~# iptables -L -t nat

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination   
DNAT       udp  --  anywhere             se400.pppoe-8216.sa.bih.net.ba udp dpts:5060:5078 to:192.168.45.4 
DNAT       udp  --  anywhere             se400.pppoe-8216.sa.bih.net.ba udp dpts:8000:11000 to:192.168.45.4 

ali u našem slučaju ovaj udp saobraćaj treba prioretizirati bez obzira da sli se radi o dolaznom ili odlaznom saobraćaju

vezano za dilemu implementacije sa tc ili sa dsl_qos_queue, autor ovog materijala je ustavri napisao howto, pretpostavljam da bi trebalo pokušati sa dls_qos_queue-om

http://archives.free.net.ph/message/20071106.101439.dace7708.en.html

Author: Fog_Watch
Date: 2007-11-06 11:14 +100
To: lartc
Subject: [LARTC] Re: HFSC and that ATM overhead problem (Another VOIP QoS post. Ahhhh)
On Sun, 4 Nov 2007 23:04:19 +1100
Fog_Watch <db5@???> wrote:

HFSC appears to be the queueing discipline of choice for VOIP.

In http://www.lartc.org/lartc.html it is stated that users of CBQ might suffer from the 'sendmail effect' - "which teaches us that any
complex technology which doesn't come with documentation must be the best available." Purhaps I was suffering from 'sendmail effect' when
considering HFSC.

At http://forum.openwrt.org/viewtopic.php?pid=27049#p27049 there is an interesting passage that compares HTB and HFSC, and states how the
priority setting of HTB in effect decouples latency and bandwidth.

Based on this and the standard documentation (http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm) I think I'll have a crack at HTB first.

does that mean that the next best
solution would be HTB coupled with the newly updated
http://www.adsl-optimizer.dk/?

In addition to the above I've looked at:
http://www.adsl-optimizer.dk/
http://ace-host.stuart.id.au/russell/files/tc/tc-atm/
http://edseek.com/archives/2006/03/13/linux-qos-tc-and-accounting-for-atm-overhead/

I am none the wiser about what I do to make adsl-optimizer go. What I'm going to do is establish sub-optimal shaping (probably Shorewall)
and then maybe optimise later.

Interestingly, adsl-optimizer is now established under sourceforge (https://sourceforge.net/projects/adsl-optimizer/)

Regards

Fog_Watch.

• da se radi o podešenjima baš rađenim za openwrt
• dosta je ljudi koliko sam pročitao zadovoljno učincima
• u primjeru se pominje voip

dio qos.conf-a (izvukao iz ipk-a)

## User configuration of the QoS script
##
## At a minimum, set the DOWNLOAD and UPLOAD variables below. Setting these
## slightly slower than the actual line speeds is critical to good QoS
## performance. With download and upload speeds set too high, the traffic queues
## in the modem (upload) and on the ISP side (download) will quickly fill up. As
## these queues can be very long --on the order of several seconds-- filling
## them will prohibit any meaningful traffic shaping.
##
## The default configuration, with the proper upload and download speeds set,
## should be adequate for most situations to separate out low-priority peer-to
## -peer traffic (eMule, Bittorrent, etc.) from interactive traffic such as web
## browsing and SSH sessions.
##
## The configuration can be refined by modifying the settings below. As an
## example, consider including support for VoIP. This may be accomplished by        <<<<<<<<<<<<<<<<<<<<<<<<<<< VoIP
## adding the IP address of a VoIP adapter to the IP_EXPR variable (e.g.
## IP_EXPR="192.168.1.10"). Doing so will elevate the status of traffic to and
## from the VoIP box to 'express'.
##
## In general, the configuration of the QoS script requires the setting of
## several variables. Most variables expect a space separated list of elements
## (ports, IP addresses, protocols). Adding an element to a list will, based on
## the variable name, either promote a certain connection to 'express' (highest
## priority) or 'priority' status, or demote it to 'bulk' status. The default
## status for all traffic is 'normal'. An example of setting a configuration
## variable to classify traffic is the statement
##
## TCP_PRIO="80 443" 
##
## Including this line in the configuration will ensure that all TCP traffic to
## the listed ports (in this particular case for the http and https protocols)
## will be treated as 'priority' traffic.
##
## Another example (from the default configuration) is:
##
## TCP_BULK="1024: 21" 
##
## which adds port 21 (the port used for ftp) and all ports 1024 and up to the
## list of destination ports for 'bulk' traffic. The result is that ftp
## downloads get a low priority, as does traffic to non-reserved ports (mostly
## peer-to-peer protocols). The notation '1024:' indicates a port range, in this
## case including all ports 1024 and higher. Another example of a port range is
## ':10' which means all ports from 0 to 10. A range from 10 to 20 is denoted as
## '10:20'.
##
## It is important to note that some variables take precedence over others. This
## becomes significant in cases where the same traffic is identified by
## different rules. An example is adding a UDP game port above 1024 to the
## express list. In the default configuration, all high ports (1024:) are
## included in the UDP_BULK variable. Without knowing the order of the rules, it
## is not possible to determine what the status of traffic to the game port will
## be. It turns out, the traffic will be classified as priority, since UDP_EXPR
## takes precedence over UDP_BULK.
##
## The order of the variables is (lowest precedence first): L7_BULK, L7_PRIO,
## L7_EXPR, IPP2P_BULK, IPP2P_PRIO, IPP2P_EXPR, TCP_BULK, UDP_BULK, TCP_PRIO,
## UDP_PRIO, TCP_EXPR, UDP_EXPR,  TOS_BULK, TOS_PRIO, TOS_EXPR, DSCP_BULK,
## DSCP_PRIO, DSCP_EXPR, IP_BULK, IP_PRIO, IP_EXPR