sub_zero píše:Po obědě zkusím zavolat na "vyšší místa", tak vydrz.
oki, thx
❗️Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
Test a analýza hraničních routerů
Re: Test a analýza hraničních routerů
oki, thx
0 x
Hapi, chlape, Cisco nemůžeš házet do popelnice, je to nebezpečný elektroodpad, to se musí likvidovat jinak! 
Ale názoru, že jde o předražené krabice s poddimenzovanými procesy se nebráním...
Reagoval jsme primárně na to, že máme výpadky, strčím mezi Cisco a rádio nějaký switch a ono to přestane. Pokud vynechám variantu, že si rádio s Ciscem nesedlo signalizačně, což by snad i tupá opice na dohledu mohla poznat podle té tuny blábolů, co to obvykle generuje, tak jako pravděpodobné vychází to ne/použití flowcontrol.
Budeš se divit, ale Cisco umí flowcontrol i shaping...
Flowcontrol se z principu vypíná, protože ve většině případů škodí, proto ho mají ty Cisco bedny default vypnuté a kdo chce, musí si ho zapnout. Je pár situací, kde má přínos. Tohle spojení switche rychlou linkou do pomalého rádia, které nemá dost paměti na případné bursty, je jedno z mála z nich, kde má smysl, pokud se ten burst vejde do bafrů. Jde to udělat i jinak, můžu v Ciscu nastavit, že nemá tlačit do rádia data gigabitem ale třeba jen 200 Mbps (pokud mám konektivitu pod 200 Mbps a rádio umí dát víc jak 200 Mbps), tím využiju opět případné bafry ve switchi a nepotřebuji flowcontrol. V Ciscu něco jako "srr-queue bandwidth limit 20" na gigabitovém portu nastaví posílání dat rychlostí cca 200 Mpbs (zadávají se procenta z nativní přenosovky v kroku 10%). Flowcontrol má proti tomuhle plus v tom, že umožní využít sloučeně bafr v rádiu i switchi a nevýhodu v horší odezvě a plynulosti toku linky, pokud bude docházet k jeho aktivaci.
Pokud si pamatuji, tak jsi psal, že nakonec něco zapli na rádiu a ono se to napravilo a odmítli říci co. Možná na tom Caregonu nastavili, že má použít a generovat pause rámce, když bude plné (nebo to má konfigurovatlenou velikost front a natáhli ji na max)? Nevím, je to jedna z možností. Samozřejmě ti z Práglu nejlépe neměli posílat víc, než co dokáže trasa zpracovat.
Souhlasím, že asi dojdeš k tomu, že má větší výpadky ten, kdo má router až za rádiem u sebe, než ten s routerem na POPu, pokud je oblažován podobnými bursty jako ty. Ten router ti plní funkci toho bafru na pochytání burstů, obvykle operuje s podstatně větší RAMkou než switch/rádio a dokáže burst pobrat a pak rovnoměrné to rozpustí dál do pomalejší linky.
K té myšlence, aby si POPové Cisco při zaplnění zabrzdilo další předchozí switch, kdyby mu došly bafry - proto krám, že je neumí generovat. To je jen dobře. Jednak ten poslední switch před tvým Caregonem není asi jen pro tebe. Asi by ti nepoděkovali ostatní klienti připojení ke stejnému POPu, že se jim zasekává konektivita dle toho, jak tvůj Caregon se zakucká burstem paketů a při nestíhání si vynutí zastavení toku od uplinkového switche pro všechny klienty.
Druhý důvod je relativní debilita toho flowcontrol. Není to stop-start komunikace, ale jen stop na oznámený čas, kdy zahlcený prvek posíla pause rámec a v něm na jak dlouho se má zastavit vysílání (v násobcích doby odpovídající přenosu 512 bitů na linkové rychlosti). Čeasto se to posílá defenzivně, takže se zahlcená strana zcela vyprázdní a odesílající strana ještě nějakou dobu čeká, než obnoví posílání. Pokud se takto dá víc prvků za sebe a dojde k řetězovému zastavení, tak se to rozbíhá jak Čech na křižovatce a data protékají v přískocích, proto je nežádoucí víc 802.3x aktivních prvků za sebe.
Exisutje novější veze flowcontrol, než je 802.3x stopující celý port. Existuje 802.3bd, který umí zastavovat jednotlivé toky, ale ty jsou definovány dle CoS priorit provozu (802.1p) a ne volitelně dle klientů. Ale skoro nikdo to nepodporuje, Cisco možná v Nexusech, je to určeno pro specifickou oblast datových center.
Korektní otázka, zda flow cotrol ti pomůže pochytáním dat do bafrů. Nevím jak ty bursty byly objemově veliké (max mohl mít tak 1 MB dat). Předpokládám na tom POPu něco jako model 3650 (i kdyby 2650, tak je to stejné). Nevím přesně vnitřní strukturu plně gigové verze, ale je to praděpodoně stejné se stovkou, kde jeden ASIC řídí 24 linek místo 8 u giga. Takže v jednom ASICu na 8 linek je pro egress fronty cca 2 MB, ta je dělena na bafry o 256 bajtech, kde každý port má privátních 200 bafrů a ze zbylého sdíleného poolu se může alokovat do celkového počtu 800 bafrů na port. Do jednoho bafru nejde dát data víc paketů (takže krátké pakety 64 až cca 240 bajtů vždy vezmou jeden bafr, plný 1500 obsadí 6 bafrů). Z toho se dá usuzovat, že reálně máš na výstupu portu 100 až 200 KB bafr v závislosti na velikosti paketů.
Jinak souhlas s tím, že pokud se potkají nad linkou 3 subjekty - jeden za konektivitu a uplink, druhý za last míli a třetí platí/reklamuje, tak se občas dobrat výsledku je pakárna, vždy je špatný ten třetí, který u komunikace dvou zrovna není....
K tomu shapingu. Shpang je na Cisuc podporován a kupodivu tam najdeš i realtivně pdoobné údaje tomu, co znáš z ROSu, co máš jako limit-at/max-limit je v protějšku shape average/shape peak. Je tam i ekvivalent burst režimu, který může být jak na average, tak i peak režimu (ale kratší bloky než v ROS), taktéž dělení do podtříd a náznaku QTčka....
Jenže na tebe neuplatňují shaping (i když by asi šel nastavit s blbým burst oknem, které by tě ubíjelo), ale je použit policing. Důvod bude prostý, jednak shaping podporují až velké bedny a vyžaduje dost protřeků v té bedně, musí mít dost RAM na bafry, podstatně větší nárok na CPU a pokud máš dráty na 10 Gbps a spousty klientů... Co ti udělal RB1100AHx2 po nasazení QT si asi ještě pamatuješ. Proti tomu policing je součástí i toho nejtupějšího zařízení a má minimální nároky na výkon a prostředky. Policing ale neomezuje rychlost jakou k tobě tečou data, nýbrž jen průměrné množství dat v čase.
Je k tomu kyblíková teorie a několik variant, ale prakticky je základem čítač, který čítá rychlostí průměrné povolené rychlosti, pokud máš 100 Mbps, tak 10 M/sec (v bajtech) a má horní storp odpovídající povolenému burstu (obvykle v limitu 8k až 1M bajtů). Čítač se zařezává na hodnotu burst. Pokud dojde paket, tak se od čítače zkusí odečíst délka paketu, jeli výsledek nezáporný, paket propuštěn, pokud by se šlo do záporna, paket je dropnut. Když tečou data cca kolem té definované rychlosti, tak čítač se drží poblíž nuly a sem tam ti tak dropne paket. Pokud máš provoz žádný nebo nízky, je udržován na tom maximu odpovídající burstu, pokud má limit třeba 256K a přiletí do switche gigabitem nesený burst o 256KB dat, tak je propuštěn nezměněnou rychlostí, jen kdyby byl delší, tak po těch 256 KB se bude dropovat na propustnost cca těch 10 MB/s. Tohle se asi dělo u toho tvého sběru netflow dat, jak jsi zmiňoval někoho, kdo měl větší bloky. A tento propuštěný burst ti zaházelo rádio, že ho neustálo. Pokud velikost burstu stáhli, tak to už vydropuje někde v centru a rádio už s tím problém nemá.... Narazil jsi na to, že máš trošku netradiční toky dat, běžnější je přeci jen plynulejší přenosu, než bursty od těch netflow sond, takže při takovémto blbém nastavení ti to ztrátovalo dost. U někoho jiného se to vůbec nemusí projevit.
Policing má plus v tom, že se dá realizovat v čemkoliv, díky nenáročnosit na implementaci, také nevnáší zpoždění do komunikace (což shaping s tím frontou obvkyle nějaké malé dělá), ale produkuje ty přenosové špičky, které by shaping urovnal. Pokud následná síť se s těma špičkama umí vyrovnat, tak je policing pro carriera ideál, protože to obsluží s tupějšíma krabicema.
Ale názoru, že jde o předražené krabice s poddimenzovanými procesy se nebráním...Reagoval jsme primárně na to, že máme výpadky, strčím mezi Cisco a rádio nějaký switch a ono to přestane. Pokud vynechám variantu, že si rádio s Ciscem nesedlo signalizačně, což by snad i tupá opice na dohledu mohla poznat podle té tuny blábolů, co to obvykle generuje, tak jako pravděpodobné vychází to ne/použití flowcontrol.
Budeš se divit, ale Cisco umí flowcontrol i shaping...
Flowcontrol se z principu vypíná, protože ve většině případů škodí, proto ho mají ty Cisco bedny default vypnuté a kdo chce, musí si ho zapnout. Je pár situací, kde má přínos. Tohle spojení switche rychlou linkou do pomalého rádia, které nemá dost paměti na případné bursty, je jedno z mála z nich, kde má smysl, pokud se ten burst vejde do bafrů. Jde to udělat i jinak, můžu v Ciscu nastavit, že nemá tlačit do rádia data gigabitem ale třeba jen 200 Mbps (pokud mám konektivitu pod 200 Mbps a rádio umí dát víc jak 200 Mbps), tím využiju opět případné bafry ve switchi a nepotřebuji flowcontrol. V Ciscu něco jako "srr-queue bandwidth limit 20" na gigabitovém portu nastaví posílání dat rychlostí cca 200 Mpbs (zadávají se procenta z nativní přenosovky v kroku 10%). Flowcontrol má proti tomuhle plus v tom, že umožní využít sloučeně bafr v rádiu i switchi a nevýhodu v horší odezvě a plynulosti toku linky, pokud bude docházet k jeho aktivaci.
Pokud si pamatuji, tak jsi psal, že nakonec něco zapli na rádiu a ono se to napravilo a odmítli říci co. Možná na tom Caregonu nastavili, že má použít a generovat pause rámce, když bude plné (nebo to má konfigurovatlenou velikost front a natáhli ji na max)? Nevím, je to jedna z možností. Samozřejmě ti z Práglu nejlépe neměli posílat víc, než co dokáže trasa zpracovat.
Souhlasím, že asi dojdeš k tomu, že má větší výpadky ten, kdo má router až za rádiem u sebe, než ten s routerem na POPu, pokud je oblažován podobnými bursty jako ty. Ten router ti plní funkci toho bafru na pochytání burstů, obvykle operuje s podstatně větší RAMkou než switch/rádio a dokáže burst pobrat a pak rovnoměrné to rozpustí dál do pomalejší linky.
K té myšlence, aby si POPové Cisco při zaplnění zabrzdilo další předchozí switch, kdyby mu došly bafry - proto krám, že je neumí generovat. To je jen dobře. Jednak ten poslední switch před tvým Caregonem není asi jen pro tebe. Asi by ti nepoděkovali ostatní klienti připojení ke stejnému POPu, že se jim zasekává konektivita dle toho, jak tvůj Caregon se zakucká burstem paketů a při nestíhání si vynutí zastavení toku od uplinkového switche pro všechny klienty.
Druhý důvod je relativní debilita toho flowcontrol. Není to stop-start komunikace, ale jen stop na oznámený čas, kdy zahlcený prvek posíla pause rámec a v něm na jak dlouho se má zastavit vysílání (v násobcích doby odpovídající přenosu 512 bitů na linkové rychlosti). Čeasto se to posílá defenzivně, takže se zahlcená strana zcela vyprázdní a odesílající strana ještě nějakou dobu čeká, než obnoví posílání. Pokud se takto dá víc prvků za sebe a dojde k řetězovému zastavení, tak se to rozbíhá jak Čech na křižovatce a data protékají v přískocích, proto je nežádoucí víc 802.3x aktivních prvků za sebe.
Exisutje novější veze flowcontrol, než je 802.3x stopující celý port. Existuje 802.3bd, který umí zastavovat jednotlivé toky, ale ty jsou definovány dle CoS priorit provozu (802.1p) a ne volitelně dle klientů. Ale skoro nikdo to nepodporuje, Cisco možná v Nexusech, je to určeno pro specifickou oblast datových center.
Korektní otázka, zda flow cotrol ti pomůže pochytáním dat do bafrů. Nevím jak ty bursty byly objemově veliké (max mohl mít tak 1 MB dat). Předpokládám na tom POPu něco jako model 3650 (i kdyby 2650, tak je to stejné). Nevím přesně vnitřní strukturu plně gigové verze, ale je to praděpodoně stejné se stovkou, kde jeden ASIC řídí 24 linek místo 8 u giga. Takže v jednom ASICu na 8 linek je pro egress fronty cca 2 MB, ta je dělena na bafry o 256 bajtech, kde každý port má privátních 200 bafrů a ze zbylého sdíleného poolu se může alokovat do celkového počtu 800 bafrů na port. Do jednoho bafru nejde dát data víc paketů (takže krátké pakety 64 až cca 240 bajtů vždy vezmou jeden bafr, plný 1500 obsadí 6 bafrů). Z toho se dá usuzovat, že reálně máš na výstupu portu 100 až 200 KB bafr v závislosti na velikosti paketů.
Jinak souhlas s tím, že pokud se potkají nad linkou 3 subjekty - jeden za konektivitu a uplink, druhý za last míli a třetí platí/reklamuje, tak se občas dobrat výsledku je pakárna, vždy je špatný ten třetí, který u komunikace dvou zrovna není....
K tomu shapingu. Shpang je na Cisuc podporován a kupodivu tam najdeš i realtivně pdoobné údaje tomu, co znáš z ROSu, co máš jako limit-at/max-limit je v protějšku shape average/shape peak. Je tam i ekvivalent burst režimu, který může být jak na average, tak i peak režimu (ale kratší bloky než v ROS), taktéž dělení do podtříd a náznaku QTčka....
Jenže na tebe neuplatňují shaping (i když by asi šel nastavit s blbým burst oknem, které by tě ubíjelo), ale je použit policing. Důvod bude prostý, jednak shaping podporují až velké bedny a vyžaduje dost protřeků v té bedně, musí mít dost RAM na bafry, podstatně větší nárok na CPU a pokud máš dráty na 10 Gbps a spousty klientů... Co ti udělal RB1100AHx2 po nasazení QT si asi ještě pamatuješ. Proti tomu policing je součástí i toho nejtupějšího zařízení a má minimální nároky na výkon a prostředky. Policing ale neomezuje rychlost jakou k tobě tečou data, nýbrž jen průměrné množství dat v čase.
Je k tomu kyblíková teorie a několik variant, ale prakticky je základem čítač, který čítá rychlostí průměrné povolené rychlosti, pokud máš 100 Mbps, tak 10 M/sec (v bajtech) a má horní storp odpovídající povolenému burstu (obvykle v limitu 8k až 1M bajtů). Čítač se zařezává na hodnotu burst. Pokud dojde paket, tak se od čítače zkusí odečíst délka paketu, jeli výsledek nezáporný, paket propuštěn, pokud by se šlo do záporna, paket je dropnut. Když tečou data cca kolem té definované rychlosti, tak čítač se drží poblíž nuly a sem tam ti tak dropne paket. Pokud máš provoz žádný nebo nízky, je udržován na tom maximu odpovídající burstu, pokud má limit třeba 256K a přiletí do switche gigabitem nesený burst o 256KB dat, tak je propuštěn nezměněnou rychlostí, jen kdyby byl delší, tak po těch 256 KB se bude dropovat na propustnost cca těch 10 MB/s. Tohle se asi dělo u toho tvého sběru netflow dat, jak jsi zmiňoval někoho, kdo měl větší bloky. A tento propuštěný burst ti zaházelo rádio, že ho neustálo. Pokud velikost burstu stáhli, tak to už vydropuje někde v centru a rádio už s tím problém nemá.... Narazil jsi na to, že máš trošku netradiční toky dat, běžnější je přeci jen plynulejší přenosu, než bursty od těch netflow sond, takže při takovémto blbém nastavení ti to ztrátovalo dost. U někoho jiného se to vůbec nemusí projevit.
Policing má plus v tom, že se dá realizovat v čemkoliv, díky nenáročnosit na implementaci, také nevnáší zpoždění do komunikace (což shaping s tím frontou obvkyle nějaké malé dělá), ale produkuje ty přenosové špičky, které by shaping urovnal. Pokud následná síť se s těma špičkama umí vyrovnat, tak je policing pro carriera ideál, protože to obsluží s tupějšíma krabicema.
0 x
ano, přesně tak to bude. Určitě tam maji tupější policing kterej řeže všechno směrem do nixu takže to větši bedna bude a bude spravovat tisíce zákaznků. Proto to nereagovalo na změnu front a do radia furt tekly peaky protože jak říkáš, policing vychází z průměrnýho datovýho toku a ten ceragon to neunes. 1MB peak rychlostí 1Gbit se fakt nedá ukočírovat. Takže skutečností je fakt, že je lepší rozmělnit datovej tok než začít používat shaping nebo flow control nebo něco řešit s buffery který stejně jednoho dne přetečou a ostatní věci budou časem blbout. S tim se nedá než souhlasit. Nicméně najít to co to způsobuje je porod
jinak výživný psaní
jinak výživný psaní
0 x
Jo, mám blábolivou, když je na stole vhodný podpůrný faktor: http://ararat.ru/en/ararat/akhtamar
K tvému provozu. Ano, nemáš moc na výběr, nezývá ti nic jiného, než nutit ty sondy plivat data po menších blocích a nedělat bursty, protože jinak ti to někde neproleze.
Měl jsi stav, že ti to neprobralo rádio, když byl velký burst povolen na policeru v Práglu - blbě. Pokud na oliceru stáhnou burst limit, tak ti to už zahází policer sám - opět blbě. OK, ukecáš je na shaper místo policeru. Super, nebud eproblém s rádiem, shaper to pošle normalizovaně v lajně, ale hraješ o velikost fornty v tom shaperu, menší bedny mají limit na 64 paketů, u větších se dá dosta tna 512 i více (záleží na využití bafrů). To už vypadá skoro pozitivně, ale pokud se ti to srazí i s normálním proozem tvých lidí, tak půjdeš opět rychle za frotnu a zaháže se to na její plnost a chybička se vloudí....
Je otázka, co se snažol v Práglu měnit. Za policerem ještě sedí egress fronty, tam se dá něco počarovat, ale nejsou velké a pokud bude na té lince víc klientů, tak dost klesají možnost tam provoz rozprostřít. Že by chtěl podobně pilovat bafry na prvcích po cestě dál pochybuji, nerozjebou si kvůli tobě celou síť a stejně jich tam moc nebude. Něoc by šlo i na ingress frontě na POPu, ale těch max cca 192 KiB, při větším počtu klientů POPu to nevytrhne...
Mohl se snažit stáhnout velikost toho burst limitu u policeru, tím by odstranil bursty zahlcující rádio, ale o data z pohledu netflow přijdeš. A pokud měli parametry policeru nastaveny dle doporučení Cisca, tak ten burst byl značný. Obecně mají, že zmíněný kyblíček počítající tokeny s právem pro odesílání se má zaplnit za 1,5 sec, což ti při 100 Mbps lajně dělá 18 MB dat (na řadě beden taková hodnota nepůjde nai nastavit, povolí max 1 M, větší asi dovolí přes 50 M). To můžeš snižovat dlouho a pořád to rádio ubiješ i switch před tím ubiješ, pokud burst bude zvenčí chodit v dostatečné velikosti..
Návic to ovlivní i typ policeru, v Ciscu jsou dva. Starší z dob Frame Relay (CAR a už nedoporučovaný k požití), ten si přímo říká o pravidlený příděl burstů, protože ten kyblík plní skokově. Pokud dodrží nastavení burstu dle doporučení Cisca pro 100 Mbps limit, tak bude schopen ti dělat každých 125 ms burst o velikosti až 1,5 MB. Novější (class) už plní kyblík rovnoměrně a je tomu odolnější.
Nicméně obecně je vražda stáhnout ten burst limit moc dolů. Má to dost dopad na maximálku TCP. Pokud dáš vedle sebe shaper se stjenými parametry, že oba mají mít teoreticky rychlost 100 Mbps, tak u policeru se jedno TCP dostane tak nad 50 Mbps a u shaperu na 90 Mbps. U policeru potřebuje burst nastavit na to, aby krátkofobě propustil rychlost k 200 Mbps, pak to TCP bude schopno nastoupat k tomu 100 Mbps stropu. To tkaé může být do toho bodu brblání o maximálce TCP.
Dá se říci, že když proháním lidi přes policer, měla by technologie schopna přenášet až na konec dvounásobek, aby se dlao vymačkat maximum z TCP...
Tupější policing... Nezatracoval bych, bez něj by byl carrier někde... A brzo budeš i ty. Brblal jsi nad zhroucením 1100AHx2 v tvé síti, kdyby v ROSu byl vedle shaperu (queue tree) i policer, tak dá to RBčko tvoji síť s levou zadní při stejných parametrech řízení toků... A bude třeba začít Mikrotiky mlátit, aby dodali podporu. Kdy potřebuješ shaper? Když linka dál přenosově je menší než co přichází, potřebuješ to prohnat frontou na rozporstření těch burstů. Pokud linka dál dává co příchod, stačí ti řezat celkovou obálku přenosové rychlosti policerem (a v delším časovém okně řádu sekund výsledek shaper/policer je stejný) a nemusíš bafrovat shaperem, což je mnohme náročnšější. Pokud máš FTTB síť, tak k tbě teorticky jdou nyní data 300 Mbps rádiem, i kdyby 1 gpbs optika, ale ta z tvého routeru jde a ž do baráku přes pár switchů a na konci je 100 Mbps port. Stačí ti to zařezat policerem, že tam budou krátké bursty neřešiš, tou lajnou projdou a nabafruje se to až na egress frontě na tom 100 Mbps portu koncáka, který udělá výstupní frontu jemu domů. Pokud v policeru budeš mít bursty cca na úrovni toho egress bafru koncového switche, tak není co řešit...
Jist,ě pro wifi část potřebuješ shaper, co ti dojde po 300 Mbps profiltorvané policereme a dál holé puštěné do 5 GHz wifiny by byl katastrofální paket loss. Tam musí být ta fronta, co to rozprostře do času a možnosti linky. A nemusí být ani v tom centrálním prvku, tam klidně stačí ten policer. Co jde optikou dál, jde už přímo, kde mám rádia, tak pak už ti stačí jen jendoduchá jedna queue, která došlé bursty zarovná a bez ztráty odwifinuje dál. A pokud chceš být echt kadet, tak v rámci toho policingu si třeba pakety označkuji na DSCP dle druhu provozu (VoIP, video, ...) a v tom frontovátku před wifinou použiju pár queue vedle pro priority a už neřeším pro koho to je, jen dle druhu provozu jen něco odvysílám dříve... tenot zplsob řešení s etýká i nějakého dalšího pláče velde, zda řídit porovz jen v jendom místě nebo víc a jak zvýšit výkon při proposutnosi tím centrálním bodem.
Jak ti posutpně rosotu datové toky a počty klientům budeš muset pomalu to řešit podobě jako ti data carrierové. I ten ROS na Xeonech má své limity.
Došly podpůrné faktory, není dpvod blábolit dál...
K tvému provozu. Ano, nemáš moc na výběr, nezývá ti nic jiného, než nutit ty sondy plivat data po menších blocích a nedělat bursty, protože jinak ti to někde neproleze.
Měl jsi stav, že ti to neprobralo rádio, když byl velký burst povolen na policeru v Práglu - blbě. Pokud na oliceru stáhnou burst limit, tak ti to už zahází policer sám - opět blbě. OK, ukecáš je na shaper místo policeru. Super, nebud eproblém s rádiem, shaper to pošle normalizovaně v lajně, ale hraješ o velikost fornty v tom shaperu, menší bedny mají limit na 64 paketů, u větších se dá dosta tna 512 i více (záleží na využití bafrů). To už vypadá skoro pozitivně, ale pokud se ti to srazí i s normálním proozem tvých lidí, tak půjdeš opět rychle za frotnu a zaháže se to na její plnost a chybička se vloudí....
Je otázka, co se snažol v Práglu měnit. Za policerem ještě sedí egress fronty, tam se dá něco počarovat, ale nejsou velké a pokud bude na té lince víc klientů, tak dost klesají možnost tam provoz rozprostřít. Že by chtěl podobně pilovat bafry na prvcích po cestě dál pochybuji, nerozjebou si kvůli tobě celou síť a stejně jich tam moc nebude. Něoc by šlo i na ingress frontě na POPu, ale těch max cca 192 KiB, při větším počtu klientů POPu to nevytrhne...
Mohl se snažit stáhnout velikost toho burst limitu u policeru, tím by odstranil bursty zahlcující rádio, ale o data z pohledu netflow přijdeš. A pokud měli parametry policeru nastaveny dle doporučení Cisca, tak ten burst byl značný. Obecně mají, že zmíněný kyblíček počítající tokeny s právem pro odesílání se má zaplnit za 1,5 sec, což ti při 100 Mbps lajně dělá 18 MB dat (na řadě beden taková hodnota nepůjde nai nastavit, povolí max 1 M, větší asi dovolí přes 50 M). To můžeš snižovat dlouho a pořád to rádio ubiješ i switch před tím ubiješ, pokud burst bude zvenčí chodit v dostatečné velikosti..
Návic to ovlivní i typ policeru, v Ciscu jsou dva. Starší z dob Frame Relay (CAR a už nedoporučovaný k požití), ten si přímo říká o pravidlený příděl burstů, protože ten kyblík plní skokově. Pokud dodrží nastavení burstu dle doporučení Cisca pro 100 Mbps limit, tak bude schopen ti dělat každých 125 ms burst o velikosti až 1,5 MB. Novější (class) už plní kyblík rovnoměrně a je tomu odolnější.
Nicméně obecně je vražda stáhnout ten burst limit moc dolů. Má to dost dopad na maximálku TCP. Pokud dáš vedle sebe shaper se stjenými parametry, že oba mají mít teoreticky rychlost 100 Mbps, tak u policeru se jedno TCP dostane tak nad 50 Mbps a u shaperu na 90 Mbps. U policeru potřebuje burst nastavit na to, aby krátkofobě propustil rychlost k 200 Mbps, pak to TCP bude schopno nastoupat k tomu 100 Mbps stropu. To tkaé může být do toho bodu brblání o maximálce TCP.
Dá se říci, že když proháním lidi přes policer, měla by technologie schopna přenášet až na konec dvounásobek, aby se dlao vymačkat maximum z TCP...
Tupější policing... Nezatracoval bych, bez něj by byl carrier někde... A brzo budeš i ty. Brblal jsi nad zhroucením 1100AHx2 v tvé síti, kdyby v ROSu byl vedle shaperu (queue tree) i policer, tak dá to RBčko tvoji síť s levou zadní při stejných parametrech řízení toků... A bude třeba začít Mikrotiky mlátit, aby dodali podporu. Kdy potřebuješ shaper? Když linka dál přenosově je menší než co přichází, potřebuješ to prohnat frontou na rozporstření těch burstů. Pokud linka dál dává co příchod, stačí ti řezat celkovou obálku přenosové rychlosti policerem (a v delším časovém okně řádu sekund výsledek shaper/policer je stejný) a nemusíš bafrovat shaperem, což je mnohme náročnšější. Pokud máš FTTB síť, tak k tbě teorticky jdou nyní data 300 Mbps rádiem, i kdyby 1 gpbs optika, ale ta z tvého routeru jde a ž do baráku přes pár switchů a na konci je 100 Mbps port. Stačí ti to zařezat policerem, že tam budou krátké bursty neřešiš, tou lajnou projdou a nabafruje se to až na egress frontě na tom 100 Mbps portu koncáka, který udělá výstupní frontu jemu domů. Pokud v policeru budeš mít bursty cca na úrovni toho egress bafru koncového switche, tak není co řešit...
Jist,ě pro wifi část potřebuješ shaper, co ti dojde po 300 Mbps profiltorvané policereme a dál holé puštěné do 5 GHz wifiny by byl katastrofální paket loss. Tam musí být ta fronta, co to rozprostře do času a možnosti linky. A nemusí být ani v tom centrálním prvku, tam klidně stačí ten policer. Co jde optikou dál, jde už přímo, kde mám rádia, tak pak už ti stačí jen jendoduchá jedna queue, která došlé bursty zarovná a bez ztráty odwifinuje dál. A pokud chceš být echt kadet, tak v rámci toho policingu si třeba pakety označkuji na DSCP dle druhu provozu (VoIP, video, ...) a v tom frontovátku před wifinou použiju pár queue vedle pro priority a už neřeším pro koho to je, jen dle druhu provozu jen něco odvysílám dříve... tenot zplsob řešení s etýká i nějakého dalšího pláče velde, zda řídit porovz jen v jendom místě nebo víc a jak zvýšit výkon při proposutnosi tím centrálním bodem.
Jak ti posutpně rosotu datové toky a počty klientům budeš muset pomalu to řešit podobě jako ti data carrierové. I ten ROS na Xeonech má své limity.
Došly podpůrné faktory, není dpvod blábolit dál...
0 x
jak myslíš, já budu shapovat centrálně dál protože to má svoje značný výhody a počet jader v procesorech narůstá takže problem nebude. Jo RB1100AHx2 se zakuckala ale taky dělala těch shaperů ne jeden ale rovnou 1500 (1500QT). Pokud potřebuji do posledního bitíku rozložit celou konektivitu, musí to tak bejt a žádnej policing neni možnej protože by to totálně rozbil.
0 x
Hapi, nazdarek, zmen u me v tvem testeru system z MK na PFSense, ucineno kvuli stabilite routeru, u MK nebylo mozne udrzet system v provozu dele jak 2dny, po zkouseni s pametmi, procesory atp. pomohla zmena systemu, nechapu, ale je to tak. Sorry, zmena byla provedena zacatkem ledna.
0 x
změněno... stejně tam máš nějaký modráky.
OT: já asi fakt budu muset k tomu smokepingu dopsat nějaký GUI pro zadávání.
OT: já asi fakt budu muset k tomu smokepingu dopsat nějaký GUI pro zadávání.
0 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků
hapi píše:změněno... stejně tam máš nějaký modráky.
Na to nemuzu dojit cim to je, ale bude se menit spoj, tak uvidim potom.
0 x
tak velký ne
0 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků
Tak probehl upgrade ze SAFu na optiku, tak uvidime ted co to udela, zatim to vypada OK. Takze to asi delal SAF.
to HAPI: Zmen tam prosim te u me konekt na 400Mbps
to HAPI: Zmen tam prosim te u me konekt na 400Mbps
0 x
hotovo
jo vždycky to je zařízením kolem a ne routerem samotným.
jo vždycky to je zařízením kolem a ne routerem samotným.
0 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků