markování provozu na routeru s NATem

[Pelirob]

Vím že už to tu bylo mnohokrát, ale buď jsem nenašel to správné téma, nebo jsem úplně mimo. Řeším markování provozu na routeru s NATem, kvůli hodně asymetrickému ADSL. Kamarád chtěl poradit, aby mu všechu konektivitu nevyžírali děti. Na Mikrotiku triviální úloha...

Pravidlo pro označování příchozího provozu :

Kód: Vybrat vše

/ip firewall mangle
add action=mark-connection chain=prerouting comment="Mark all VIP connections" disabled=no new-connection-mark=VIP_Connection-In src-address-list=VIP passthrough=yes
add action=mark-packet chain=prerouting comment="Mark all VIP packets In" connection-mark=VIP_Connection-In disabled=no new-packet-mark=QoS_2_In passthrough=no

Na routeru je NAT - odchozí provoz označuju v postroutingu :

Kód: Vybrat vše

/ip firewall mangle
add action=mark-connection chain=postrouting comment="mark Connection VIP upload" new-connection-mark=VIP_Connection-Out out-interface=WAN src-address-list=VIP passthrough=yes
add action=mark-packet chain=postrouting comment="Mark all VIP packets Out" connection-mark=VIP_Connection-Out new-packet-mark=QoS_2_Out out-interface=WAN passthrough=no

A mám tam ještě pravidlo, které označí všechen zbývající provoz :

Kód: Vybrat vše

/ip firewall mangle
add action=mark-packet chain=prerouting comment="----QoS_8 [Zbytek]----" in-interface=WAN new-packet-mark=QoS_8_In passthrough=no protocol=tcp
add action=mark-packet chain=postrouting new-packet-mark=QoS_8_Out out-interface=WAN passthrough=no protocol=tcp
add action=mark-packet chain=prerouting in-interface=WAN new-packet-mark=QoS_8_In passthrough=no protocol=udp
add action=mark-packet chain=postrouting new-packet-mark=QoS_8_Out out-interface=WAN passthrough=no protocol=udp
add action=mark-packet chain=prerouting in-interface=WAN new-packet-mark=QoS_8_In passthrough=no
add action=mark-packet chain=postrouting new-packet-mark=QoS_8_Out out-interface=WAN passthrough=no

Připravil jsem si jednoduchý strom pro testovací účely :

Kód: Vybrat vše

/queue tree
add limit-at=4M max-limit=4M name=QoS_Global_Upload parent=global queue=default
add limit-at=1024k max-limit=3M name="QoS_2_Out(WWW_VIP)" packet-mark=QoS_2_Out parent=QoS_Global_Upload priority=2 queue=pcq-upload-default
add limit-at=0 max-limit=1M name="QoS_8_Out(Default)" packet-mark=QoS_8_Out parent=QoS_Global_Upload queue=pcq-upload-default
add limit-at=8M max-limit=8M name=QoS_Global_Download parent=global queue=default
add limit-at=4096k max-limit=6M name="QoS_2_In(WWW_VIP)" packet-mark=QoS_2_In parent=QoS_Global_Download priority=2 queue=pcq-download-default
add limit-at=0 max-limit=2M name="QoS_8_In(Default)" packet-mark=QoS_8_In parent=QoS_Global_Download queue=pcq-download-default

Když nechám aktivní jen jedno z pravidel pro markování provozu (je jedno které), tak při návštěvě http://www.speedtest.net vidím, jak dokonale probíhá omezování, v Queue Tree nejdříve žloutnou a pak zčervenají indikátory omezování rychlosti - perfektně to funguje - když je zapnuté pravidlo pro download, funguje omezování downloadu. Když je zapnuté jen pravidlo pro upload, funguje omezování uploadu.
Ale v okamžiku, kdy jsou aktivní obě pravidla naráz, tak příchozí provoz je označován až tím posledním mangle pravidlem (tj. omezen na 1Mb), odchozí provoz je označován a omezován správně. A za žádnou cenu nemůžu přijít na to, kde je chyba.

Pokud tam vidíte nějakou nesrovnalost, můžete mi prosím říct, kde...? Děkuji.

[Fang]

V mangle pravidlu si v akci odškrtni "passtrough".

[Rosak]

Jak píše Fang plus pro optimalizaci:
- nemusíš značit konexe, stačí Ti značit pouze pakety.
- pro up i down lze používat chain forward.
- do QT si vlož jednu queue společnou pro up i down, protože odchozí a příchozí rychlost na DSL imo nejde sčítat (tedy max-limit s rezervou podle toho, jak rychlý máš download). Do této hlavní queue pak vlož další dvě (jednu pro up a druhou pro down). A do nich pak vkládej koncové queue. Dál už je to jen o správném vyvážení pomocí priorit, max-limit a limit-at, případně queue-type.

[Pelirob]

To je mě napadlo taky jako první, bohužel to nefunguje.
Download směr je omezen na hodnotu uvedenou v QoS_8_In, upload to z nějakého důvodu neomezuje vůbec a běží stylem "co linka dá".

V mangle pravidlu si v akci odškrtni "passtrough".

[Pelirob]

Jak píše Fang plus pro optimalizaci:
- nemusíš značit konexe, stačí Ti značit pouze pakety.

To funguje pouze v případě, že nechci dalšími podmínkami (Mangle Rule - Advanced) řídit datový tok pro různé address listy nebo jiná pravidla. Navíc všechny oficiální návody manglují nejdříve konexe a až potom pakety - prý kvůli výkonu.

Jak píše Fang plus pro optimalizaci:
- pro up i down lze používat chain forward.

Tak jsem to měl doteď na svém domácím routeru, ale chtěl jsem se učit dál a ve většině Wiki a postupech k Mikrotiku se píše, že v případě NATu se má k markování odchozího provozu používat POSTROUTING, protože jen v něm jsou vidět zdrojové adresy klientů a ne přeložená veřejka.

Jdo QT si vlož jednu queue společnou pro up i down, protože odchozí a příchozí rychlost na DSL imo nejde sčítat (tedy max-limit s rezervou podle toho, jak rychlý máš download). Do této hlavní queue pak vlož další dvě (jednu pro up a druhou pro down). A do nich pak vkládej koncové queue. Dál už je to jen o správném vyvážení pomocí priorit, max-limit a limit-at, případně queue-type.

Zajímavá připomínka, vyzkouším hned jak mi to bude správně manglovat...

[ludvik]

Důležité je vědět, co je connection. Je to záznam o konexi v conntrack tabulce. Tam se to dostane s tím úplně prvním paketem, co jádro ještě nezná.
Čili značit conn-mark příchozí a odchozí nemá moc smyslu. Když to vznikne z venku, tak je to download ... a když zevnitř, tak upload. Jenže obě ty konexe posílají data oběma směry!

Čili buď úplně opusť connmark a dělej jen packetmark v závislosti na příchozím/odchozím interface. Nebo ho nech (mělo by to být trochu výkonnější, i když záleží na situaci a podmínkách), ale ve výsledném packetmark musíš rozlišit směr.
Také mysli na to, že prerouting/postrouting ještě nemá ponětí o NAT.
https://wiki.mikrotik.com/wiki/Manual:Packet_Flow_v6

Nebo to zkus možná udělat přes simple queue. Od jisté doby jsou dost optimalizované, takže ani stovky či tisíce pravidel nehrají moc roli.

[Pelirob]

Důležité je vědět, co je connection. Je to záznam o konexi v conntrack tabulce. Tam se to dostane s tím úplně prvním paketem, co jádro ještě nezná.
Čili značit conn-mark příchozí a odchozí nemá moc smyslu. Když to vznikne z venku, tak je to download ... a když zevnitř, tak upload. Jenže obě ty konexe posílají data oběma směry!

Máte pravdu, tady je ta blbá chyba, dvakrát mark-connection je špatně! Samozřejmě to vzniklo z toho, jak jsem nejdřív zkoušel pravidla samostatně a pak je tupě bez přemýšlení složil, když na to teď koukám, je to nebetyčná kravina. Předpokládám že jste myslel cca něco takového :

Kód: Vybrat vše

/ip firewall mangle
add action=mark-connection chain=postrouting comment="mark VIP Connection" new-connection-mark=VIP_Connection out-interface=WAN src-address-list=VIP passthrough=yes
add action=mark-packet chain=prerouting comment="Mark all VIP packets In" connection-mark=VIP_Connection disabled=no new-packet-mark=QoS_2_In in-interface=WAN passthrough=no
add action=mark-packet chain=postrouting comment="Mark all VIP packets Out" connection-mark=VIP_Connection new-packet-mark=QoS_2_Out out-interface=WAN passthrough=no

Čili buď úplně opusť connmark a dělej jen packetmark v závislosti na příchozím/odchozím interface. Nebo ho nech (mělo by to být trochu výkonnější, i když záleží na situaci a podmínkách), ale ve výsledném packetmark musíš rozlišit směr.
Také mysli na to, že prerouting/postrouting ještě nemá ponětí o NAT.
https://wiki.mikrotik.com/wiki/Manual:Packet_Flow_v6

Nebo to zkus možná udělat přes simple queue. Od jisté doby jsou dost optimalizované, takže ani stovky či tisíce pravidel nehrají moc roli.

Jo, jen s markováním paketů mi to fungovalo :

Kód: Vybrat vše

/ip firewall mangle
add action=mark-packet chain=postrouting comment="Mark all noVIP packets In" disabled=no new-packet-mark=QoS_2_In dst-address-list=noVIP passthrough=no
add action=mark-packet chain=postrouting comment="Mark all noVIP packets Out" new-packet-mark=QoS_2_Out out-interface=WAN src-address-list=noVIP passthrough=no

Na Packet Flow6 jsem se samozřejmě koukal, ale jak jsem psal výše, složil jsem dvě fungující pravidla a výsledek nefungoval...
A Simple Queue určitě vyzkouším, minimálně proto, že bych si ušetřil práci s markováním In/Out.

Děkuji za nakopnutí správným směrem.

[ludvik]

pokud přes connmark, tak bych na to šel asi ve forward chainu. Tedy před src-nat a po dst-nat.
Opět tam máš (tykej ...) vlastně tu chybu, že konexi markuješ dle interface - uteče ti ta vzniklá opačným směrem. Mám takový pocit.

Co tím chceš vlastně dosáhnout? Nějakého složitého, na službách založeného QOS, nebo prostě řízení provozu mezi jednotlivými IP? Čistě teoreticky stačí PCQ ...

[Pelirob]

Hlavní požadavek je prioritizovat data VIP skupiny (dospěláci - 4 lidi, 6 zařízení) před noVIP (3 puberťáci, 5 zařízení) na lince, která má necelých 8MB download. Pokud si puberťáci pustí nějaký downloader, aktualizace her, YT a nejlépe v mixu všichni všechno, tak dospělí prakticky nemají nárok.
Ne že by dospěláci nekoukali občas na YT, nebo Stream.cz, ale rozhodně to nemají puštěné celé odpoledne a večer nonstop. Tak chce kámoš prioritizovat VIP zařízení identifikovaná podle IP adresy. Nejlépe ještě stylem VIP-video, VIP-HTTP(s), děti-video, děti-http(s), IMAP+SMTP, Windows Update, P2P
No a to už se předpokládám bez pečlivého markování provozu neobejdu....

pokud přes connmark, tak bych na to šel asi ve forward chainu. Tedy před src-nat a po dst-nat.
Opět tam máš (tykej ...) vlastně tu chybu, že konexi markuješ dle interface - uteče ti ta vzniklá opačným směrem. Mám takový pocit.

Co tím chceš vlastně dosáhnout? Nějakého složitého, na službách založeného QOS, nebo prostě řízení provozu mezi jednotlivými IP? Čistě teoreticky stačí PCQ ...