Router z NAT-em na Linuksie to nie tylko problem odpowiednich reguł firewalla, ale i problem “równego i równiejszego” podziału pasma łącza. I tu wkracza traffic shaper.

Zagadnienie nie jest banalne, ponieważ:

• możemy kształtować i kontrolować tylko ruch wychodzący od nas;
• asynchroniczne łącza (ADSL, kablówka) mają wyraźną tendencję utraty zdolności ściągania przy wysyłaniu dużej liczby danych (czyli upload zabija download).

Jak zatem osiągnąć taki podział całego ciastka:

• SSH (w różne strony) ma mieć wysoki priorytet, by dało się swobodnie zdalnie zarządzać (inny przypadek: komputer XXX ma mieć wysoki priorytet).
• Ruch wysokotransferowy HTTP czy POP3 jest pożądany (głównie zachodzi w naszą stronę), więc nie należy go ograniczać jakoś specjalnie.
• Z kolei ruch generowany przez sieci p2p nie jest istotny, więc niech ciurka sobie nieprzeszkadzając innym.
• Generalnie wszyscy powinni mieć równorzędny dostęp do pasma up i down, czyli nikt nie powinien zmonopolizować całego łącza.
• Duże wysyłanie nie powinno zawalać całego łącza w naszą stronę (upload nie może zabijać downloadu).

Bazując na długich próbach, wielu testach, różnych poradach (trzy linki na końcu), wyprodukowałem konfigurację - jako konfigurowalny skrypcik traffic shapera - dla Neostrady (6114/512 kbit/s) “mniej więcej” spełniającą powyższe kryteria. Bazuje na iproute2, HTB oraz SFQ, a filtry na u32 (nie wymaga żadnych reguł firewalla). Niestety są problemy, których nie rozwiązałem.

Po pierwsze nawet niewygórowany transfer wychodzący (16-32 kbit/s) może dać w efekcie spory transfer przychodzący (kilka mbit/s). Wobec tego traffic shaper nawet nie zaczyna przeciwdziałać, bo dla niego pasmo wychodzące jest praktycznie wolne. Powoduje to utratę responsywności np. po SSH przy zdalnej pracy. Nie dotyczy to sytuacji intensywnego wysyłania - tutaj shaper działa dobrze i upload nie przeszkadza downloadowi.

Nie ma pełnej sprawiedliwości podziału łącza na X osób, gdyż SFQ (Stochastic Fairness Queueing) dzieli wedle sesji, a jeden IP może mieć ich kilka do różnych serwerów. Rozwiązaniem byłoby wydzielenie każdego klienta do osobnej klasy HTB (Hierarchy Token Bucket), ale nie da się tego zrobić przy nieznanej i zmiennej liczbie maszyn.

Mimo powyższych dwóch małych wad skrypt uważam za udany - spełnia większość założeń.

Co lepsze materiały:

• Linux Advanced Routing & Traffic Control HOWTO
• Traffic shaping and bandwidth management
• HOWTO Packet Shaping