AToL: QoS and Traffic shaping

7.9.2011 16:54 | Přečteno: 1961× | Linux | poslední úprava: 7.9.2011 16:54

Autor: Jan Dosoudil
Nasledovný príspevok je študentskou prácou, ktorá vznikla v rámci predmetu Advanced Topics of Linux Administration. Predmet je vypisovaný na Fakulte informatiky MU v spolupráci so spoločnosťou Red Hat Czech. Vyučovacím jazykom je angličtina a preto je v nej aj nasledovný príspevok, študent nemá právo výberu iného jazyka. Komentáre k obsahu príspevku sú vítané v ľubovoľnom zrozumiteľnom jazyku.

QoS and Traffic shaping

This article describes problems in configuration of traffic shaping in unusual circumstances. These circumstances are not as unusual as may by seem on first view. It's about real life situations.

This article expects basic knowledge about traffic shaping in GNU/Linux and packet path in Linux kernel.

Cascades

Common usage of shaping in small network is traffic limiting on internet gateway. Company is connected to internet using DSL provider, WIFI or something similar, which doesn't have guaranteed quality. Configuring traffic shaping and QoS in this environment is hard. It may by impossible to guarantee anything.

The first problem is link quality. Internet service provider doesn't guarentee bandwidth, latency, nothing. Traffic shaping is typicaly based on slowing down packets. It handles TCP flow control. TCP sends packets as fast as client is able to send responses. Slowing down packets causes less inbound traffic, which is our mission. It's usual that there are many data streams which competes against. Each stream has its own data speed control and it is trying to take as much bandwidth as it is avaliable. Traffic shaping is applied at internet service provider's router, all data streams are same priority, when link capacity is filled up, all packets are delayed. It may be OK at home, but if you want to use IP telephony which quality will be realy bad, user will call for some solution.

Basic solution is to configure linux router, set traffic shaper, for example HTB and limit internet line. ISP limits our line to 1Mb/s so we configure shaper to 1Mb/s. (We follow only download part in this example.) One rule for basic internet traffic with limit to 512Mb/s and second one with limit to 512Mb/s for VoIP. There is too much unused conectivity for VoIP but there is reserve for more VoIP calls. But you want to use all your connectivity. It's possible with HTB, create one root rule with limit to 1Mb/s, one child rule with rate 128Mb/s and ceil 1Mb/s, next one child rule with rate 256Mb/s and ceil 512Mb/s. This configuration will work quite well - internet trafic will use first child rule, VoIP second one. If there is no VoIP traffic, internet traffic will use all available bandwidth. VoIP has guaranteed 256Mb/s which should be enought but if more VoIP traffic requirements occurs, it will be available with highier priority than common internet traffic. This is quite good solution, but there are some problems. When clients uses all available connectivity, VoIP quality suddenly drop. It will be close to quality without shaping. Where is problem? ISP does traffic shaping too and limitation of inbound traffic is firstly applied at ISP side and then by our router so ability to eliminate latency and priorize VoIP is minimal. Standard solution is to limit maximal bandwidth to 80 % or less of total bandwidth. It's usually the only one realizable sollution because it is realizable without ISP cooperation. It is nearly impossible to take some unusual configuration of ISP's traffic shaper.

Problem with shaping cascades is that there is no way to pass through traffic at not last shaper, it's solvable by underflow ISP's limitation, but it's not 100% solution in networks with aggregation of multiple clients, with speed unstable lines and so on.

Multiple network cards

If you are internet service provider, provides connectivity to your clients using multiple network cards and would share your unused connectivity between network cards, you hit limitation of linux shaping principles. Linux shaping usually uses output buffer of network card so it isn't possible to share bandwidth between more network cards. You can reserve bandwidth for each network card but you cannot share unused bandwidth between them.

There is solution which can help – IMQ. It creates special network interface used only for shaping. IMQ is not part of vanilla Linux kernel, it isn't included in distribution kernels, it's distributed only as patches. Installation requires patching kernel and iptables. IMQ is controlled using kernel module parameters – number of IMQ devices and iptables – packet routing. Typical solution uses two IMQ devices, one for upload and one for download. It is able to use iptables configuration to separate inbound and outbound traffic, separate networks, join and share network connectivity via many network cards.

Half-duplex lines

Many ISPs provides Half-duplex lines or your users are connected using half-duplex technology, for example IEEE802.11 wifi. Maximum line capacity is usually known but its limit is for upload and download together. Basic Linux kernel limits at outbound interface output buffer so limiting together is not possible. Solution is to use IMQ as described in chapter Multiple network cards.

You can configure one IMQ devices for all traffic and route there all traffic – inbound and outbound. Using iptables and tc you can configure root rule with total line capacity and child nodes for upload and download. It's possible to provide limits such as 2Mb/s download and 512kb/s upload for many clients and use as much bandwidth as is currently available.

NAT

If you are administrator of small company network your network is probably connected to internet using router with nat and you want configure this router to equalize clients so you configure linux shaping using tc. Simple solution is routing packets to shapper using tc filter's u32 filter. It will work well without nat, but not with it. Problem is packet path in Linux kernel – shaping is applied after iptables changes source address so all upload traffic is count as only one address. It's usually solved by marking packets by iptables before address modification.

Second solution is using IMQ – it allows compile time configuration of hook in packet path which is able to shape traffic before nat.

       

Komentáře

[David Watzke]

Nepsals náhodou, že ten příspěvek bude anglicky? A nic

[j0k3r]

elegantne receno

takovy politicky korektni clanek, naprosto stejne pristupny tem co anglictinou vladnou, tem co nevladnou a zrovna tak negramotnym

[petr_p]

IFB je vosk?

[atan]

Ja osobne s IFB bojoval dlouho, ale problem s natem, o kterem pise prace, jsem nevyresil. S IMQ vse funguje krasne.

[Max]

Asi není naráženo na to, že by mělo být IFB nějakou plnohodnotnou náhradou za IMQ, ale na to, že se autor mohlo zmínit, že něco takového existuje a je to přímo v jádře.
Zdar Max

[Tomáš]

Tenhle zápis je nejhorší shit, jakej sem tu viděl.

[Tetris]

A tvokj prispevok este horsi daj si facku a uninstall pls