Admission

If you don't know NiceShaper, first of all take a look at included config files. It's pretty usable template and really gives you solid start to see how to build basic configuration. Next come back and read this documentation to figure out how to do it better, or what else you can do with this software.
Please be aware that NiceShaper has been written for polish Network Administrators since start of the project, so there is forum on the webpage but it is useless for you because of polish language. Also you should realize that this documentation can be language incorrect and even incomplete.

Requirements

NiceShaper require Linux router box with iptables and optional tc from iproute2 packet with fallback iproute mode. By default NiceShaper work with HTB by communicating with kernel by netlink protocol, but it's new feature and you my find bugs, so if you did find one, please give me a details. Linux Kernel with HTB, U32 filter is required, SFQ, ESFQ, FW filter, IMQ are optional and have specyfic options documented below. It's better if you have some knowledge about these modules and iptables.

Installation

Compile process required c++ compiler from gcc package, make program, Standard C++ Library and Linux kernel headers.
Downloaded and unbzipped package compiles in a fairly standard way (without ./configure):
$ make
$ su
# make install
if everything correct binary will be copied to /usr/local/bin. You can omit make install and manualy copy niceshaper binary everywhere you want.
If you do not have configuration files installed yet, just copy the sample files:
# mkdir /etc/niceshaper # cp etc/niceshaper/*.conf /etc/niceshaper/
Otherwise, make sure that between the old and installing current version, there were no syntax changes.

Configutation

Config files syntax.

Common and required configuration files are /etc/niceshaper/config.conf and /etc/niceshaper/class.conf.
include file /full/path - used in these files can include next ones. include file <sciezka> - dyrektywa include użyta w tych plikach pozwala włączać kolejne. Dyrektywa include obsługuje ścieżki absolutne (z rozpoczynającym znakiem slash) oraz relatywne do katalogu konfiguracyjnego (domyslnie /etc/niceshaper).
There are some syntax differencing directives:
- "directive" "value" ["value"] is directive with one or many values, e.g..:
rate 128kB/s
debug iptables iproute
- "directive" "parameter" "value" ["parameter" "value"] is directive with parameter-value list, e.g.:
stats file /var/www/stats/nsstats.txt unit kB/s mode 644
In these examples configuration parser will split values and parameters with values, so for your individual preferences you can write these directives like that:
rate 128kB/s
debug iptables
debug iproute
stats file /var/www/stats/nsstats.txt
stats unit kB/s
stats mode 644
Order of parameters does not matter, but collides may occur i.e. using esfq scheduler squeezing out others schedulers directives.
Directive match and include is parameter-value list too, but you can not split this beacuse it changes logic of filters. gdyż zburzyło by to sens/spójność więc i zachowanie tych dyrektyw o czym więcej w odpowiednich częściach dokumentacji.
Directive class have inflexible syntax.
Podstawowe jednostki przepustowości to b/s-bit na sekundę, oraz B/s-bajt na sekundę. Z przedrostkami k(K)-kilo, m(M)-mega. Jednak dopisek '/s' nie jest obowiązkowy a rozróżnienie między przepustowością a ilością przesłanych danych odbywa się na podstawie kontekstu użycia. Jednostką domyślną jest b/s (bit na sekundę).
NiceShaper udostępnia kilka znaków specjalnych:
- Znak '#' jest komentarzem i odnosi się do reszty linii za nim, również znaki <# komentarz #> tworzą komentarz, z tą różnicą że stosuje się je w parze a obejmują dowolnie duży wycinek konfiguracji. Zakomentowana część konfiguracji nie jest brana pod uwagę.
- Znak średnika zastępuje przejście do nowej linii konfiguracyjnej, pozwala zminimalizować długość pliku konfiguracyjnego klas, czasem pozytywnie a czasem negatywnie wpływa na czytelność.
Zmiany w konfiguracji wymagają zrestartowania programu.
Wszystkie konfiguracje dostarczone z pakietem są tylko przykładami i nie są optymalne dla każdej sieci. Proper bandwidth units are b/s (bits per second) and B/s (bytes per second). You can add prefixes 'k(K)-kilo, m(M)-mega' if needed. default unit is b/s.
Jednak dopisek '/s' nie jest obowiązkowy a rozróżnienie między przepustowością a ilością przesłanych danych odbywa się na podstawie kontekstu użycia. Jednostką domyślną jest b/s (bit na sekundę).
NiceShaper gives you some special chars:
- '#' char is using for comment rest of line. <# comment #> is using to affect sector of configuration. Commented configuration is not reading.
- ';' char is end of line equivalent, it give you way to minimalize length of config files by write a lot of directives in one line.
Zmiany w konfiguracji wymagają zrestartowania programu.
remember, all examples are only examples and might not be optimal for you.

Main configuration file, for example of asymmetric 4Mbit/512kbit.

Main configuration file /etc/niceshaper/config.conf is divided into sections, one called global, and any number of sections for shape on appointed interfaces. for each section (except global one) there will be one process in system which will control attached classes
<global>
<download>

Opcje globalne:

run - list of configured sections you want to run.
mark-on-ifaces - list of interfaces on which run fw filter in place of u32. Packets outs by this interfaces will be marked by iptables mark destination. It's needed for control upload within network using private IP addresses and NATs outgoing packets, or to use advanced filters.
lang {en|pl} - specifies messages language. (domyślnie pobierany jest ze zmiennej środowiskowej LANG. Aktualnie poza domyślnym językiem angielskim, obsługiwana jest wartość pl_PL.UTF-8 tej zmiennej)
stats {unit|classes|sum|file|owner|group|mode|listen} <> - how to display work statistics.
log {syslog|terminal|file} <> - logging.
fallback [iproute] - .

Section configuration:

match test <> [test <>]
+Jest to dyrektywa filtra. Umieszczona w ramach konfiguracji sekcji przyporządkowuje jej określony ruch IP. +Najczęściej określana tu będzie cała podsieć/podsieci lokalne, +stąd powyższe przykłady są w zasadzie na ten moment wystarczającym tłumaczeniem. +Pełny opis filtrów NiceShapera znajduje się w dalszej części dokumentacji.
+Filtry sekcji w przeciwieństwie do filtrów klas, nie mają żadnego wpływu na HTB, +ich rolą jest umieszczenie w tabeli mangle odpowiednich wpisów, +kierujących pasujące pakiety do utworzonego przez NiceShapera +łańcucha (z przedrostkiem ns_) w którym rezydują filtry klas tej sekcji.
+Konstrukcja ta ma za zadanie umożliwienie zliczania ruchu generowanego przez klasy, +i ew. dodatkowo przypisywania znaczników mark lub przekierowywanie na interfejsy IMQ.
+Nie występuje już wzorem NiceShapera 0.6 dyrektywa iface której częścią były właśnie filtry.
+Należy zadbać by zadeklarowane klasy NiceShapera obsługiwały cały przypisany sekcji ruch +w przeciwnym razie pojawią się niemożliwe do kontrolowania przecieki. +Np. w przypadku gdy nie wszystkie hosty w sieci lokalnej zostaną przypisane do klas, +te nie kontrolowane będą odbierały pasmo pozostałym.
section {speed|shape} <> - parameters of section (in most cases bandwidth of your internet access).
reload - how frequency renew HTB configuration. default 4s is safe and quite good. If you have idle power try to reduce. It will boost interaction with users caprice. Allowable value is in 0.1s to 600s and step is 0.1s.
mode {download|upload} - parametr ten jest bardzo ważny, gdyż sekcje integrują się z łańcuchami tabeli mangle iptablesów, w sposób odmienny by kontrolować pakiety płynące w kierunku z internetu do sieci lokalnej/serwera, oraz odwrotnie dla tych podążających z sieci lokalnej/serwera do internetu. Dla mode download następuje ulokowanie filtrów głównych sekcji w łańcuchu POSTROUTING, a dla mode upload w łańcuchu PREROUTING. Parametr ten ma w pewnych sytuacjach wpływ na inne zachowania programu, więc zmiany łańcucha tabeli mangle jeśli zajdzie taka potrzeba nie należy dokonywać za jego posrednictwem, służy temu dyrektywa iptables z parametrem hook.
iptables {hook|hook-mode} <> - parametry odnoszące się bezpośrednio do iptables w systemie.
debug [iptables][iproute] - echoes system commands before execute it.
default - default parameters for each defined classes. All classes can override this default settings. It's not required, but gives you better reading.

Class in NiceShaper

File /etc/niceshaper/class.conf holds classes definitions, we can assume that NiceShaper class is a HTB class equivalent/extension. Class is build by header, at least one filter and optionally options.
Each packet conforms to running section conforms to first matched class.

Class strukture

Class definition starts with his header and ends with next class header or end of file:
class <section> <interface> <name>
section - section to whose class belongs.
interface - interface on which HTB queue operates.
name - your class name, for stats and others.
Interfejs jest tu niezwykle ważny a poprawnego wskazanie tego na którym należy założyć kolejkę HTB może sprawić pewien problem.
Co ważne!! Pomijąc zabiegi typu użycie interfejsów wirtualnych IMQ, które są opisane w odpowiedniej części dokumentacji, kernel z HTB kształtuje ruch na interfejsie którym pakiet OPUSZCZA router i ten interfejs należy tu wskazać.
Przykładowo jeśli łącze internetowe podłączone jest do interfejsu eth0 a sieć lokalna do eth1. Przy kształtowaniu pasma downloadu klientów poprawnym interfejsem klasy będzie eth1, zaś przy kształtowaniu pasma wychodzącego z sieci czyli uploadu klientów będzie to eth0.
Iptables i Iproute nie rozróżniają aliasów interfejsów. Które nawiasem mówiąc są przestarzałym rozwiązaniem z czasów powszechnego stosowania ifconfig zastąpionego przez polecenie ip. Stąd w przypadku takich interfejsów z aliasami, w konfiguracji NiceShapera pomijamy część aliasową czyli dwukropek i liczbę za nim.
Natomiast vlany zapisywane w formie ethX.vid są w pełni obsługiwane.

Iptables and iproute does not know what is interface alias, so put here only physical interface part and it will works good.
Vlans handling works in standard linux notation e.g. ethX.vid.

And filter:

match test <> [test <>]
Filter conforms packets to classes.
Each class can have unlimited number of filters.
Each filter can have list of tests to be more detailed.
-Filtry definiują ruch którym dana klasa będzie zarządzać. -W skład klasy może wchodzić dowolna liczba filtrów. -Naturalnie testy można ze sobą łączyć by uzyskać bardziej szczegółowe filtry. +Filtry definiują ruch którym dana klasa będzie zarządzać.
+Odpowiednie wpisy tworzone są przez NiceShapera zarówna w łańcuchu iptables sekcji, +jak i tworzony jest filtr HTB U32 lub FW jeśli interfejs klasy został wymieniony w dyrektywnie mark-on-ifaces.
+Te pierwsze za zadanie mają zliczanie pasma wykorzystywanego przez klasę, +te drugie kierowanie do odpowiedniej klasy HTB kształtującej pasmo.
+Naturalnie testy można ze sobą łączyć by uzyskać bardziej szczegółowe filtry, +zaś w skład klasy wchodzić może dowolna liczba filtrów.
Simplest class looks like:
class download eth1 pc55
match dstip 192.168.0.55
Everywhere in configuration you can use semi-colon instead of new line:
class download eth1 pc55; match dstip 192.168.0.55
class download eth1 pc58; match dstip 192.168.0.58

Class parameters:

low - minimal rate for class (default: 0)
ceil - maximal rate for class (default is equal section shape).
rate - static rate (ceil is equal low).
strict {0 do 100} - określa jak bardzo nie lubimy przeginających (domyślnie: 70). Wartości niskie będą skutkowały bardziej restrykcyjnym traktowaniem tychże delikwentów. Wartości bliskie 100 przy przeciążeniu łącza, "współodpowiedzialnością ogółu".
hold - Inactive time after that class is unloaded from HTB (default: 30s).
iptables {target} <> - parametry odnoszące się bezpośrednio do iptables w systemie.
htb {prio|scheduler} <> - HTB parameters.
sfq {perturb} <> - SFQ scheduler parameters if used in classes.
esfq {perturb|hash} <> - ESFQ scheduler parameters if used in classes.
imq {autoredirect} <> - IMQ interface options.
type {standard-class|wrapper|do-not-shape|virtual} - do dyspozycji poza standardową klasą standard-class, mamy 3 dodatkowo predefiniowane typy:
Each class options can (and even should) be defined in section configuration, it will become as defaults to not repeat the same values for each class. In this case you can use default flag but it is not mandatory. Next this defaults can be overwrite in each class with individual values;

Basics filters tests:

proto {tcp|udp|icmp} - protocol.
srcip - source IP address.
dstip - destination IP address.
srcport|sport - source port. Needs to choose tcp or udp protocol.
dstport|dport - destination port. Needs to choose tcp or udp protocol.
in-iface - interfejs którym pakiet przychodzi do routeru.
out-iface - interfejs którym pakiet opuszcza router.
to-local - umożliwia kontrole pasma pobierania przez router, zastępuje dstip. Szczegółowy opis w rozdziale "Jak traktować ruch z i do routera". Wymaga wskazania interfejsu wchodzącego in-iface.
from-local - umożliwia kontrole pasma wysyłania przez router, zastępuje srcip. Patrz opis szczegółowy jak wyżej. Wymaga wskazania interfejsu wychodzącego out-iface.
srcip oraz dstip can match ip address or network with subnet mask (bits like /24 or doted like 255.255.255.0). Mask can be not continuous (ie. 255.255.128.255) but mogą wskazywać adres ip lub podsieć adresów o zasięgu zdefiniowanym w standardowy sposób przez maskę, zapisaną w formacie bitowym lub kropkowo-dziesiętnym. Maska nie musi być ciągła ( np. 255.255.128.255 ) jednak należy pamiętać że takiej sytuacji nie obsługuje filtr u32 i dla masek nieciągłych trzeba posłużyć się markowaniem pakietów. example filters:
match srcip 192.168.0.77 - packets with source ip address 192.168.0.77.
match srcip 217.74.65.69 srcport 110 dstip 192.168.0.0/29 proto tcp - mail retrieving by pop3 from 217.74.65.69 to 192.168.0.0/29 subnet.

Tests requiring marking enabled on an interface:

Iptables został zaopatrzony w olbrzymią liczbę filtrów, które nie są niestety możliwe do zrealizowania przy użyciu filtra U32. Dlatego też poniższe filtry wymagają mark'owania przez mark-on-ifaces. Każdy wychwycony i oznaczony przez iptables pakiet może już być bez problemu skolejkowany do odpowiedniej klasy HTB dzięki filtrowi fw który zostaje użyty w miejsce filtra u32 ten aspekt będzie szczególnie rozbudowywany w kolejnych wersjach testowych i zależny jest od możliwości iptables w systemie.
not-srcip - source address other than specified.
not-dstip - destination address other than specified.
not-srcport|not-sport - source port other than specified (specify tcp or udp protocol needed).
not-dstport|not-dport - destination port different than specified (specify tcp or udp protocol needed).
length - długość pakietu w bajtach, np. 500, :500( od 0 do 500), 500: ( 500 i większe ), 128:500 ( 128 do 500 ).
state {new|established|related|invalid|untracked} - packet state:
tos - TOS field value.
ttl - TTL equal to the specified value.
ttl-lower - TTL smaller than a given value.
ttl-greater - TTL greater than the specified value.
mark - packets associated with given mark.

Packet marking:

When you enabled packet marking on given interface belongs to a section by mark-on-ifaces. NiceShaper for each filter belongs to section will associate mark value. The are new options for managing packets marking. You need to remembar that each mark used with these parameters will be protected and never used automatically by NiceShaper. Jeśli w danej sekcji na danym interfejsie przez mark-on-ifaces włączone zostanie markowanie pakietów. NiceShaper dla każdego filtra wchodzącego wraz ze swoją klasą do tej sekcji, automatycznie przypisze niepowtarzalny znacznik w iptables. By uzyskać możliwość operowania znacznikami pojawiają się odpowiednie parametry.
Trzeba tu pamiętać że każdy znacznik użyty w ramach tych parametrów zostanie poddany ochronie i NiceShaper nigdy nie użyje go we własnym zakresie, daje to gwarancje tego że żaden inny filtr nie otrzyma go automatycznie.
mark - wychwytuje pakiety oznaczone tym znacznikiem a podana wartość zostanie zachowana.
set-mark - podmienia przypisaną do filtra (automatycznie lub przez mark) wartość znacznika. Parametr ten jeśli użyty zostanie w ciele klasy (samodzielnie poza filtrem) przeniesie to oznaczenie na wszystkie filtry należące do danej klasy, dając jednak możliwości nadpisania w ramach konkretnego filtra.
Przykład:
class download eth1 pc77-79
First and second filter gets associated with 6 mark value and third with 11.
In situation where there are not first standalone set-mark, first and second filter gets their mark automatic. Pierwsze dwa filtry zostaną oznaczone znacznikiem 6 a ostatni 11. Gdyby pierwsza opcja set-mark nie została użyta dwa pierwsze filtry otrzymały by znacznik automatycznie.

Wykorzystanie interfejsów IMQ

Od strony konfiguracji NiceShapera, interfejsów IMQ używa się analogicznie jak tych fizycznych. Praktycznie zapomnieć można o ich wirtualności, z pełną swobodą mieszać klasy z kolejkami na interfejsach fizycznych oraz IMQ.

NiceShaper automatycznie przekierowuje ruch na interfejs IMQ a zachowanie to jest konfigurowalne z poziomu sekcji oraz klas:

imq autoredirect {yes|no}
W przypadku wyłączenia automatycznego przekierowania na IMQ, należy takowe wykonać dla NiceShapera: iptables ... -j IMQ --todev ...
Najwygodniej jest umieścić tą dyrektywe w konfiguracjach odpowiednich sekcji, tym spobem stanie się ona domyślną dla wszystkich przynależnych do tych sekcji klas.
Co oczywiste zachowanie to znów można niezależnie modyfikować w ramach poszczególnych klas.
Przykładowy wycinek pliku config.conf:

<upload>
Oraz pliku class.conf:

class upload imq5 pc5.82
class upload imq5 pc5.83

Jak traktować ruch z i do routera

Poza forwardowaniem ruchu między siecią lokalną a internetem, router również na własne potrzeby pobiera i wysyła dane, np. rozwiązując nazwy dns czy przydzielając adresy ip poprzez dhcp.
Najczęściej są to pomijalnie małe w stosunku do przepustowości kontrolowanego łącza ilości danych. Jednak w realnym świecie małych firm i sieci osiedlowych, router z Linuksem pełni często również rolę serwera usługowego, chociażby serwując stronę www czy obsługując firmową pocztę i zasoby plikowe.
Ze względu na to że kształtowanie ruchu odbywa się na interfejsie którym pakiety opuszczają router kontrola pasma pobierania danych jest utrudniona, wymaga wykorzystania interfejsów IMQ.
Kontrola pasma między routerem a siecią lokalną wymaga za to, no właśnie... pominięcia kontroli, przecież nie należy ograniczać transferów lokalnych po wydajnym ethernecie nie obciążających łącza, ba dużym błędem byłoby zakwalifikowanie ich do wykorzystania pasma przez sekcje.
Jeśli komputery w sieci lokalnej na zewnątrz maskowane są do adresu routera może pojawić się problem odróżnienia ruchu klientów od generowanego i odbieranego przez samą maszynę routera.
Już po tych kilku zdaniach wstępu widać że zagadnienie staje się ciut bardziej zawiłe niż mogło by się wydawać na pierwszy rzut oka.
Ze względu na architekturę NiceShapera wykorzystującego iptables w celu zliczania ruchu, ew. markowania i przekierowywania na IMQ oraz całkowicie przecież niezależny od iptablesów QOS, potrzeba trochę akrobacji by spiąć te 2 mechanizmy w współpracujący duet.
By praktycznie rozpatrzyć ten temat, najwygodniejsze będzie rozbicie zagadnienia na 4 niezależne scenariusze:
a) Wymiana ruchu routera z internetem (angażuje pasmo łącza). b) Wymiana ruchu routera z siecią lokalną (nie angażuje pasma łącza).
We wszystkich przypadkach należy do filtrów dodać parami - tzn. from-local z out-iface a to-local z in-iface - testy:
from-local <ip> - zastępuje test srcip a wskazany adres ip musi być poprawnie skonfigurowany na którymś z interfejsów routera. W sytuacji kiedy iptables hook sekcji to PREROUTING, zmienia sposób konfigurowania filtra w iptables. Zostaje utworzony duplikat filtra w łańcucha OUTPUT z celem w łańcuchu sekcji. Zabieg ten jest niezbędny gdyż pakiety wychodzące z serwera nie pojawiają się w łańcuchu PREROUTING.
to-local <ip> - analogicznie jak from-local z tą różnicą że zastępuje test dstip a dodatkowe dowiązanie tworzonego jest w łańcuchu INPUT, jesli iptables hook sekcji to POSTROUTING.
out-iface <iface> - do reguł iptables zostaje dodany podany interfejs jako interfejs wychodzący.
in-iface <iface> - do reguł iptables zostaje dodany podany interfejs jako interfejs wchodzący.
Należy pamiętać że najczęściej klasy tego typu powinny znajdować się na samym początku listy klas, chyba że chcemy osiągnąć inny efekt niż jestem w stanie przewidzieć w ramach poniższych przykładów.
Przechodząc do przykładów. Przyjmujemy że łącze internetowe podłączone jest do interfejsu eth0 a sieć lokalna do eth1.
Adres zewnętrzny routera to 80.53.211.226 a sieci lokalnej 192.168.0.0/24 oraz że zostały skonfigurowane sekcje o nazwach download i upload z trybami pracy analogicznymi jak ich nazwy czyli mode download i mode upload.

1. Internet => Router - pobieranie danych przez router z internetu.

Ruch z internetu do routera (np. strony pobierane przez serwer proxy, czy aktualizacje systemu mogące zabierać pasmo klientom):
class download eth0 z_internetu
Użycie klasy typu download i filtrowania to-local nie wymaga tutaj szerszego komentarza.
Adres lokalny oraz interfejs wejściowy dają pewność że ruch do routera zostanie poprawnie zakwalifikowany w fazie przetwarzania papietów przez łańcuchy iptables. Klasy należące do sekcji typu download rezydują w łańcuchu dowiązanym z POSTROUTING'u gdzie interesujące nas pakiety nigdy się nie pojawią więc za pomocą to-local tworzymy dowiązanie z łańcucha INPUT. Dodatkowo wykorzystywane jest pasmo przychodzące klientów więc naturalnie należy ten ruch wliczyć do całkowitego wykorzystania pasma download, by nie dopuścić do rozregulowania dynamicznego podziału czemu służy umieszczenie klasy w odpowiedniej sekcji.
Jednak pojawia się kłopot, jeśli nie wykorzystujemy interfejsów IMQ nie mamy kontroli nad pasmem klasy. Można zauważyć że wskazanie interfejsu eth0 nie ma najmniejszego sensu, występuje tu tak naprawdę tylko dlatego że testy poprawności konfiguracji NiceShapera wymagają żeby jakis interfejs został podany... Klasa HTB na tym interfejsie nie spełni swojej roli a router uzyska bezwzględny priorytet nad hostami użytkowników. Sytuacja ta może być akceptowalna w sytuacji gdy najbardziej cenimy sobie ruch www, który udostępniamy klientom za pomocą serwera proxy, wtedy można rozważyć akceptacje faktu że każdy inny ruch będzie dyskryminowany na korzyść serwera proxy.
Użycie IMQ sprowadza się do wskazania tego interfejsu w dyrektywnie class. NiceShaper dokona przekierowania na ten interfejs, utworzy na nim klasę HTB która spełni swoją rolę.
class download imq0 z_internetu
Ważny jest fakt że w ramach testu in-iface niezmieniony pozostaje interfejs fizyczny eth0.
Filtry iptables muszą wychwycic pakiety na podstawie fizycznego interfejsu, którym pakiet przychodzi do routera a nie jest to przecież interfejs IMQ. Przekierowanie na IMQ sygnalizuje dyrektywa class.

2. Router => Internet - wysyłanie danych z routera do internetu.

Np. zapytania generowane lokalnie słane w świat: poczta, www i inne usługi internetowe na naszym routero-serwerze:
class upload eth0 www_do_internetu
class upload eth0 mx_do_internetu
Użycie klasy typu upload i filtrowania z parametrem from-local nie wymaga tutaj szerszego komentarza. Daje nam pewność że właściwie zostanie zliczany ruch routera do internetu. Klasa upload posiada łańcuch dowiązany z PREROUTING'u gdzie interesujące nas pakiety generowane lokalnie nigdy się nie pojawią, więc from-local informuje NiceShapera by ten utworzył filtr w łańcuchu OUTPUT.
Wykorzystujemy pasmo wychodzące łącza, więc naturalnie by nie rozregulować dynamicznego podziału musimy ten ruch kontrolować i wliczać do całkowitego wykorzystania pasma upload
Jeśli hosty lokalne są maskowane do adresu zewnętrznego routera obowiązkowo interfejs wychodzący musi się pojawić na liście parametru mark-on-ifaces.

3. Router => Localnet - pobieranie danych z routera przez sieć lokalną.

Np. lokalny serwer ftp, samby, pop3.
Warto rozpocząć od wyjaśnienia że dla scenariuszy 3 i 4 czyli ruchu między routerem a siecią lokalną to czy klasy będą należeć do sekcji typu download czy upload jest drugoplanowe.
Przecież będziemy się starali takiego ruchu nie wliczać do ruchu generowanego przez wymianę z siecią internetową, więc przykładowe przyporządkowania do odpowiednich sekcji dokonano ze względu na to że intuicyjnie pasmo używane przy wysyłaniu danych z sieci lokalnej do routera to część uploadu klientów a w drugą stronę czyli z routera do klientów to ich download.
class download eth1 pop3_z_localhosta
Zalecane jest by klasa była jednym z poniższych predefiniowanych typów:
do-not-shape - transfery są lokalne więc nie tniemy i nie wliczamy do sumarycznego wykorzystania łącza
wrapper - transfery są lokalne ale boimy się przypchać radiówkę więc ograniczamy ale za pomocą statycznie przydzielonego pasma, lecz ciągle nie wliczamy do wykorzystania łącza.

4. Localnet => Router - wysyłanie danych na router przez sieć lokalną.

Ruch z sieci lokalnej do routera. Np. wysyłanie poczty za pomocą lokalnego serwera smtp, umieszczanie plików na lokalnym serwerze plików itd.
Sytuacja jest przejrzysta, intuicyjnie tworzymy klasę w sekcji upload gdyż nasze hosty lokalne wysyłają dane.
Tu znów pojawia się kłopot z scenariusza 1, filtry definiujemy standardowe lecz, jeśli nie wykorzystujemy interfejsów IMQ nie mamy kontroli nad transferem, klasa typu wrapper nie zadziała. Klasa może wyglądać następująco:
class upload eth1 smtp_do_localhosta
Tutaj problem jest mniejszy, ruch tu pasujący nie obciąża łącza internetowego, więc wystarczy nie wliczać go do niego, osiągnąć to można za pomocą dyrektywy do-not-shape.
Możemy jednak wpłynąć na transfer gdy np. nie chcemy przeciążyć linku radiowego, znów używając interfejsu IMQ:
class upload imq0 smtp_do_localhosta