|Version 1 (modified by 14 years ago) ( diff ),|
Workpage for Traffic Shaping support in Vuurmuur
http://lartc.org/ http://gentoo-wiki.com/HOWTO_Packet_Shaping http://lartc.org/manpages/tc-htb.html http://lartc.org/manpages/tc-sfq.html http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm http://www.digriz.org.uk/jdg-qos-script/
Type of Shaping
Outgoing only. Why? Basically it is the only kind of shaping that works well. Vuurmuur is designed to be a gateway firewall, and gateway firewalls can work fine this way.
If we have a setup like this:
LAN — <eth0-FW-ppp0> — WAN
We can shape all traffic by only using outgoing shaping. A LAN-client downloading can be shaped on the eth0 interface of the firewall. A LAN-client uploading can be shaped on the ppp0 interface.
3 types of shaping:
- priority: e.g. ssh is more important than http
- hard limits: e.g. cap bittorrent to 100kb/s
- soft limits: e.g. cap bittorent to 100kb/s, unless there is no other traffic
VJ: i would like to use the CLASSIFY iptables target for this. See: http://iptables-tutorial.frozentux.net/iptables-tutorial.html#CLASSIFYTARGET
- enables TS to be controlled as much from iptables rules as possible
- works well with conntrack helpers such as ftp, irc, sip, h323
- is easy to implement in the current Vuurmuur rules structure
- only in 2.6 kernel
- only outgoing traffic
The way CLASSIFY works is like this.
iptables -t mangle -A FORWARD -i ppp0 -o eth0 -p tcp -s 0.0.0.0 -d 192.168.0.0/255.255.255.0 --sport 80 --dport 1024:65535 -j CLASSIFY --set-class 1:20
This classifies the traffic flowing from a webserver to the lan-clients to class 1:20. It uses this class from the outgoing interface (eth0 in this case), but this interface does not have to be set in the rule. The Linux routing engine will select the interface and use class 1:20 there (if it exists on that interface). This brings an interesting question: how to deal with classes. I think there are two options:
- use unique classes every where. So 1: for ppp0, 2: eth0, etc.
- define all classes exactly the same on all interfaces. This of course is a problem when interfaces have different speeds.
So defining unique class id's sounds best.
DiffServ is a method commonly used to attempt guarantee Quality of Service to the networks, through the use of "classes", which are defined in the header of the IP packet through DSCP (DiffServ Code Point). To these classes, several priorities (larger the number, larger the priority) are attributed, so the routers/switches can apply several queuing strategies to satisfy the necessary requirements.
DSCP can be considered an "evolution" of packet priorization defined in RFC791, IP Precedence. Actually, DSCP uses the same IP Header octet, "Type of Service", with the difference that 6 bits are used for signaling, instead 3. As follows RFC2474, the definition of this field, now called DS Field, "is intended to supersede the existing definitions of the IPv4 TOS octet". However, the DSCP backward compatibility with the ToS is maintained.
Currently, the number of routers that implement DSCP for classification and priorization around the Internet are increasing plenty, at the same time with are already largely used in big corporate networks. This way, becomes interesting the possibility of marking DSCP codes on packets using Vuurmuur, once it makes possible the definition of quality of service patterns usable for any enviroment.
iptables -t mangle -A FORWARD -i eth0 -o ppp0 -p tcp -s 192.168.0.0/255.255.255.0 -d 0.0.0.0 --sport 1024:65535 --dport 5060 -j DSCP --set-dscp 46
We can also use the pre-defined DiffServ? classes:
iptables -t mangle -A FORWARD -i eth0 -o ppp0 -p tcp -s 192.168.0.0/255.255.255.0 -d 0.0.0.0 --sport 1024:65535 --dport 5060 -j DSCP --set-dscp-class EF
The two examples above demonstrate marking SIP packets in the way Lan --> Internet with the DSCP code "46". Again, in this case, we are just talking about egress traffic.
Seemingly there exists the possibility to use DSCP with tc to priorization in linux, using the "DSMARK" discipline. (?)