Queue tree limit v x86 ros v7?

crazyape · 2023-01-02T16:31:17+00:00

Ahojte, měním centrální shaper a testoval jsem si ros v7 a narazil jsem na zajimavý problém s queue tree. Jakmile chci pridat vic než 4504 řádků tak mi to na...

ludvik

pgb Jemu to ovšem nadává na "too many packet marks". Ty tam máš jen jeden pro všechny QT.

pgb

ludvik ale zato hodně krát ... bez víc informací těžko říct

pgb

ludvik tak mi to nedalo a vylepšil jsem to, autor si může otevřít ticket u MK ....

[admin@MikroTik] /queue/tree> /system/script/run script1
failure: too many packet marks in system

:local MARK
:local OC3
:local OC4

:set MARK 1
:set OC3 1
:set OC4 1

for i from=1 to=6000 do={
   /ip firewall mangle add chain=postrouting src-address="192.168.$OC3.$OC4" action=mark-packet new-packet-mark=$MARK
   /ip firewall mangle add chain=prerouting src-address="192.168.$OC3.$OC4" action=mark-packet new-packet-mark=$MARK
   /queue/tree/add parent=global packet-mark=$MARK

    :set OC4 ($OC4 + 1)
    :set MARK ($MARK + 1)
    :if ( $OC4 = 254) do={
        :set OC3 ($OC3 + 1)
       :set OC4 1
    }
}

pgb

ludvik Jemu to ovšem nadává na "too many packet marks". Ty tam máš jen jeden pro všechny QT.

ip/mangle/ není problém přidat ve velkém množství, tam nedojde k zhavarování

ludvik U jakého čísla to fakt skončilo?

zhavaruje to při přídávání /queue/tree na maximálním přidaném počtu 4095 (2¹²) záznamů s unikátním markem (aniž by byly marky v /ip/mangle přidány)

pgb

Volejte sláva 🙂..... chyba i na CCR1036 v7.6

vdr

Tak jsem to také otestoval a problém tam bohužel opravdu je. 🙁

ludvik

Vtipný je, že packet mark je 32 bitová hodnota ...

U jakého čísla to fakt skončilo? Oni to berou jako string, nejspíš budou mít problém ve zpracování nějaké pomocné tabulky.

ludvik

to jsou pitomci :-)

crazyape

Díky, ja uz se bal ze je problem mezi zidli a klavesnici :/ na MK forum jsem napsal ale moc je to nezajima .. zatim jsem zjistil jen to ze mam pouzivat SQ 😃 ...
Takze u mě asi downgrade na ros 6 proběhne 🙁 ... to je skoda a ja si říkal že hecnu ros7 rovnou na shaper 🙂

pgb

Na mk fóru není úplně zvykem že by reagovali lidi ze supportu. Občas tam na to někdo koukne ale nic moc. Otevři ticket ... nebo jim to mám poslat?

byzak

Ticket ohledně problému s gryfy jsem otevřel a odpověď byla že se situace nepodařila nasimulovat. Dále chtěli zaslat konfig a log, ale také bez výsledku.

crazyape

byzak já jim nápisu přímo na Support v pondělí.

krystofklima

Dobrý večer všem,

ano je zde limit okolo 3000 pravidel. Tento dotaz jsme řešili už v říjnu. Netušil jsem, že ještě dnes někdo skutečně používá prastarý systém manglování každého prdu pomocí packet-marku a následně QT.

Kdo byl na školení na verzi 7 tak tam to také zmiňuji /nyní bude další na Vigvamu v lednu 24.1. před akcí Vigvam 2023/
Celosvětový směr k PPPoE ověření přípojky a nastavení SQ u každého zákazníka zřejmě určil směr i v MikroTiku.
Bohužel při dnes avizovaných rychlostech je vesměs už skoro každé omezení provozu kontraproduktivní.

Navíc posouzení a kvalifikace na základě IP header se nám na IPv6 zvyšuje z 32bit na 128bit, tedy 4krát vyšší zátěž CPU, tedy není divu, že se od tohoto typu omezení všichni odklání /teď nemyslím českou kotlinu s ISP v každé druhé vesnici, kde PPPoE mají jen ti, kteří už prostě musí a jinak to nejde/
Rámec PPPoE se detekuje daleko lépe, je na to vestavěný proces detekce, takže SQ na PPPoE je jednodušší proces.

Rád se s Vámi o tom pobavím na Vigvamu buď na školení 24.1. nebo na akci 25.1. www.mikroisp.cz ;-)

všichni jste zváni, těším se na Vás, ještě je i ubytování, kdo by chtěl přespat ;-)

pgb

krystofklima Dobrý den, já strašně rád diskutuji o čemkoliv ohledně sítí. V Hradišti na to nebyl čas. O vigvamu přemýšlím - nebýt pana Drázského tak o tom ani nevím (nějak tu chybí reklama nebo jsem to přehlédl 🙁 ). Na školení MK v7 jet neplánuji, strašně bych Vám ho naboural a to nechci. Od MK jakožto routovacího nástroje se odvracím, ale pokud by jste chtěl, tak můžu zkusit na Vigvam připravit porovnávací test propustnosti IMIX skrze queue-tree/SQ pro na x86/CCR1036 v7 vs. nftables hash map naživo. Ukázat si co s výkonem provede snat ... možností je mnoho. Výsledek může být překvapení pro všechny 🙂. Pokud by jste chtěl tak mi cinkněte, něco vymyslíme. Boltík

krystofklima

super, máte přednášku mít a vstup zdarma...stačí 20min ?

pgb

Prezentace připravena i s praktickou ukázkou x86 vs CCR1036 + ladění výkonu x86 .... bude ukázka instalace/použití Cisco TRex, porovnání Mk v7 SQ, HTB, Nftables map, co s tím udělá firewall ....

PS: Kdyby někoho zajímal VPP/Icinga, tak rád na Vigvamu podiskutuji.

crazyape

Jakým způsobem tedy řešíte shaping na MK v roce 2023 kdyz qt a mangle je prehistorie? Nějak nechápu jak bez QT + mangle můžete fungovat... 😁

Puski

crazyape žádný velký centrální shaping nemáme. O pppoe se stará Rádius s dynamickým Simple Queue per user. Na lokalitách kde pppoe nemáme používáme Simple Queue s packet markama a PCQ. Na každy tarif jedno SQ pravidlo a 4 Mangle pravidla. To pravidlo má třeba nastavenu maximální rychlost 2G/2G a PCQ per user na 100M/100M. Klienty se pak k těm pravidlum přiřazují adres listem. Takže reálně máme jen 4 SQ pravidla třeba 10M/100M/300M/1000M. Důležité v tomto setupu je to mít každý tarif jako sólo SQ pravidlo, aby fungovalo rozdělení mezi jádra. Když to hodíš do jednoho stromu tak to řeší pouze 1 jádro pokud se zase něco nezměnilo.

Na AP kde máme ty PPPoE nashapujeme zatím ale opět se do dá vyřešit SQ pravidlem na AP v případě potřeby, aniž by se muselo sahat do rádiusu.

A myslím si že tu bude 100 chutí a 100 konfigurací. Nám to stačí zatím takto.

hapi

crazyape není to prehistorie. To si jenom někdo vycucal z prstu. Problém je v mapování ve v7 na omezený počet 4096 unikátních manglů.

pgb

crazyape crazyape taky normálně používám htb strom a nic zastaralého v tom nevidím. Sice ne na MK ale to není podstatné. Ve vlastním stromu nevidím úplně problém, spíš je potřeba se při velkém počtu manglů důsledně zamyslet nad optimalizací. Limit který zmiňuje hapi snad časem padne (né že by mě to trápilo 🙂 )

krystofklima

Puski Přesně tam to spěje, také je to přesně to co dělají velcí operátoři....myslíte si, že se O2 patlá s nějakým QT ?? nebo Vodafone, či UPC, či další ??? Tkom nebo Orange
prostě Radius+PPPoE a queue každý balík jednotlivě za sebe

okoun

Puski zdá se mi že se tu matlá více věcí do sebe, centrální shaping může být na radiusu s SQ nebo může být bez radiusu třeba pomocí QT jako to má třeba Hapi. Každopádně tak i tak je to furt centrál, kde máte tisíce klientů. Výhoda Radiusu je v tom, že v tom centárlu můžete dát paralelně další koncentrátory pokud již dosavadní stroj nestíhá a krásně se vám rozloží zátěž. Pokud však ale někdo má nahozený konectrátor co site a nemá tak centrální shaping, tak jako sorry ale tohle leze dost do peněz jak za HW tak za elektřinu, nedovedu si předtsavit že bychom měli CCR co site vysílač 🙂 Ono totiž když má člověk na situ to RBčko jen na routing případně VPLS tak má zapnutej fast path a ten výkon je úplně jinde než na RBčku kde je vypnutý fast path jen třeba protože je tam jedna blbá SQ 🙂

krystofklima

hapi je to prehistorie, sami mi to potvrdili v ticketu, který jsme právě řešili. je to jeden z důvodů, proč nehodlají nijak zvýšit ten limit na počet mangle...není důvod na zvyšování téhle centrální zátěže ;-)

« Předchozí stránka Další stránka »