141
« kdy: 09. 04. 2023, 13:53:57 »
Dobrý den,
v rámci síťovin je traffic shaping obecně jedna z nejsložitějších věcí na konfiguraci, s nevalnými vyhlídkami.
Low hanging fruit není "koupit geniální krabičku a ona to vyřeší".
Obecně pro Vás nemám dobré zprávy.
Managed switch Vám to nejspíš nevyřeší. Základní managed switche umí VLANy a třeba 802.1p (priorizace), ty lepší by možná dokázaly i IP DSCP apod. Ale traffic engineering s tím, že si rozdělíte provoz do tříd a pak jim dáte "prioritu do určité šířky pásma"... tohle bych v L2 switchi spíš nehledal. Některé lepší switche (midrange Cisco?) podle mého umí "rate limit" = omezit šířku pásma nějak definované "třídy provozu" na konkrétní hodnotu, na bázi zahazování tu a tam paketu (na což reaguje TCP) - ale toto Vám nezafunguje ve smyslu striktní priorizace.
Pokud hledáte šanci, ovlivnit priority různých tříd provozu, má to dvě nutné podmínky:
1) je třeba to řešit queueingem s dostatečnou délkou front a schopnostmi třídit druhy provozu, které jsou běžně k dispozici na routeru, běžně nikoli dostupné na switchi
2) ten queueing (s definovanými prioritami a pásmem) je třeba nasadit "směrem do úzkého hrdla". Tzn. egress do úzké linky.
Když porovnáte kapacitu LAN switche (1 Gb každým portem) s kapacitou Vaší DSL konektivity, hádejte, kde je úzké místo: na DSLAMu operátora, případně na "access koncentrátoru" někde ještě dál :-(
V situaci, kdy egress do úzkého hrdla nemáte pod vlastní kontrolou, máte ještě jednu šanci na "mizerné náhradní řešení": vyrobit si úzké hrdlo naschvál na svém konci = nastavit "agregátní třídě všeho provozu" ještě o něco užší pásmo, než je známá kapacita stávajícího úzkého hrdla, které máte typicky od operátora směrem k sobě. V tom případě řešíte především otázku, jaké procento kapacity downlinku obětovat na "uzmutí úzkého hrdla". V této úvaze hraje roli, do jaké míry se "tvarovaný" provoz skládá ze slušně vychovaného TCP, versus z jiných druhů provozu. Protože jiný traffic než zdvořilé TCP se Vám na to umělé úzké hrdlo vyprdne (i s jeho priorizací), a dál bude hltit úzké hrdlo klidně už u providera. Asi bych nepředpokládal, že se k Vám hrne větší objem UDP a dalšího connection-less trafficu. (Ačkoli, co třeba IPTV na bázi multicast UDP? Používá se to?) Spíš bych se obával provozu typu "bittorent a jeho následníci", kam patří třeba taky Windows Update = věci které rozpoutají vysoký počet TCP relací, mezi ně rozloží zátěž a snaží se tak uzmout neférové procento dostupného pásma na úzkém hrdle (které často praktikuje něco ve stylu "fair queueing", ale zřejmě k relativně "férovému" chování statisticky konverguje i prostý nerozlišený queueing bez connection trackingu).
Další problém je, že v ADSL máte sice nějaký strop na šířku pásma downlinku, ale reálně dostupná šířka pásma kolísá - v závislosti na aktivitě ostatních klientů v téže "agregaci" a v závislosti na odstupu signál/šum, což je složitá výslednice několika faktorů.
Takže: vyrobíte si umělé užší hrdlo = nasadíte na svém konci na routeru nějaký softwarový queueing. Naschvál trochu podrazíte pásmo oproti známému úzkému hrdlu (WAN spoj od ISP). Optimisticky předpokládejme, že Vám do toho nehodí vidle Bittorrent / Windows Update / nectnosti ADSL downlinku.
Z čeho to užší hrdlo vyrobit:
Nikdy jsem to nezkoumal na Mikrotiku.
Kdysi se dalo, takto konstruovat pravidla v Cisco CBWFQ (v IOSu na CPE routerech) a reálně to fungovalo. Samozřejmě to líp fungovalo směrem do skutečného úzkého hrdla na páteři ISP - což byl ale problém, protože ta věc tehdy žrala CPU.
Později jsem to zkoušel v HTB na Linuxu. Tam ale tuším nebylo k dispozici pravidlo "totální priorita, ale maximálně do objemu XY kbps". Je to už hodně let, možná proběhl nějaký vývoj.
Ať už se bavíme o Ciscu nebo o Linuxu, tuším se ten akrobatický queueing nasazoval vždycky na egressu do fyzického rozhraní. Tzn. muselo by se to nasadit "směrem do LAN". Což má smysl i ten, že pokud na CPE routeru zakončujete tunely, můžete do toho "tvarovacího frontování" sesypat i provoz, který jste zrovna vybalil z tunelu. (Čert vzal pár procent režie tunelové enkapsulace sem nebo tam.)
Celou dobu se bavím o downlinku.
Komunikace je ale obousměrná. Ztracený ACK může TCP relaci taky pěkně zadrhnout, navíc při videokonferenci je přenos obousměrný i z hlediska payloadu = jde Vám i o uplink už v principu. Štěstím v neštěstí je, že uplink představuje úzké hrdlo, od kterého držíte otěže. Špatná zpráva je, že uplink v ADSL/VDSL je jednak uzoučký (tato technologie má asymetrické pásmo), jednak oproti downlinku ještě více náchylný na problémy z důvodu sdílení více uživateli (kolísání dostupného pásma).
Zajímavou otázkou je shaping provozu baleného v tunelech. Třeba na Ciscu z dob H.323 si pamatuju možnost, značkovat kýžený provoz před zabalením, značku propisovat na vnější hlavičku po tunelové enkapsulaci, a ve finále podle této značky na egressu do uplinku priorizovat...
No a pak je tu otázka, jak se dnešní video-konferenční aplikace chovají k dostupné šířce pásma. Zda nějak hlídají, kolik dat reálně konektivitou proleze, a kolik už ne, a třeba podle toho nějak dynamicky cvičí s kvalitou přenosu. Pokud si videokonferenční aplikace jede nastaveou šířku pásma (rozlišení X komprese) a na nic se neohlíží, tak patrně nemá cenu, snažit se její pásmo omezovat v rámci queueingu na routeru, ale naopak je jediná šance, dát jí pokud možno neomezenou prioritu. Což zase znamená, že pokud videokonference vyžere všechno pásmo, tak nezabrowsíte po webu a nepošlete e-mail.
Suma sumárum:
Váš požadavek je netriviální. Existuje prostor pro ohavné přibližné náhradní řešení, kterému obětujete třeba 10-20% kapacity svého "ISP downlinku", ale to řešení ve finále stejně nebude stoprocentní, stojí na poměrně silných předpokladech, které Vám reálně můžou zhavarovat na nejméně třech různých faktorech.
Trochu spravit náladu Vám může možnost svobodně priorizovat uplink, který ale zase obecně trpí úzkou šířkou pásma a konkurencí uživatelů, prakticky napříč technologiemi pro "residential last-mile access" (relativně nejlíp je na tom PON = sdílená optika).
Celé je to ve finále o tom, že pokud nemáte dostatečnou šířku pásma pro videokonferenci + další věci, tak tam to pásmo sebedůmyslnějším shapingem nenahoníte. Snahou toto implementovat jistě odborně povyrostete, ale snadno strávíte několik dní času studiem těch technologií a laborováním - načež nad tím ve finále možná stejně zlomíte hůl (myslím poté, co jste pronikl do všech detailů technologie a dokonale ji pochopil). Otázkou je, zda to budete hodnotit jako ztracený čas, nebo jako užitečnou zkušenost a získané know-how. Osobně jsem to napoprvé zhodnotil jako doplnění svého vzdělání, ale od té doby s tím zájemce posílám do hodně nezdvořilých míst. Toto v situaci, kdy jsem měl pro sebe vyhrazené pásmo o jasně dané kapacitě = pevné číslo, symetrické ven i dovnitř.
=> Pokud chcete něco urvat penězi, a je možnost, tak je to kapacita konektivity.
Utratit hodně peněz za krabičku Vám nejspíš mnoho užitku nepřinese, spíš si do sítě zanesete netriviální chování a nutnost budoucích úprav konfigurace, pokud se podaří zvýšit kapacitu přípojky do inetu.
Zobrazit příspěvky
)