Řízený switch na základní správu sítě

Řízený switch na základní správu sítě
« kdy: 09. 04. 2023, 11:57:39 »
Zdravím potřeboval bych potvrdit nebo vyvrátit zda řízený switch je to co potřebuji a předejít chybě nákupu.

Mám domácí sít: VDSL (Terminátor) -> Router (Mikrotik Hex S) -> Switch (Tp-link TP-LINK TL-SG1008 neřízený) -> Všechno ostatní napojeno zde (tv, pc, konzole, wifi, IPTV box )

I. Fáze
1) Potřeboval bych nastavit aby PC dostal maximální prioritu a přednostně přidělenou velkou šířku pásma když to bude nutné (budou tam probíhat video konference, výpadky zvuku/obrazu jsou nepřijatelné)
2) u IPTV boxu potřebuji nastavit minimální šířku pásma aby TV nekostičkovala (cca 7Mbit) když bude probíhat konference
3) pro konzoli nastavit prioritu hned za PC aby v případě používání PC nedocházelo ke škubání her
4) TV a Wi-Fi prioritu nepotřebuje ale v případě že vše bude vypnuto a půjde pouze wi-fi nebo TV tak aby bylo k dispozici celé pásmo

Stačí na tohle obyčejný řízený switch "D-Link DGS-1100-08V2" nebo TP-LINK TL-SG108E Metal case nebo je potřeba již něco kvalitnějšího případně jaká funkce je nezbytná abych to nastavil?
Vzhledem k tomu že zařízení pojede 24/7 tak bych chtěl zachovat zařízení bez ventilátoru, vypínání neaktivních portů a celkově nízkou spotřebu, vše GLAN, PoE netřeba.

II. Fáze
Vzhledem k tomu že mám nastaveno několik připojení Wireguard přímo do Mikrotiku, potřeboval bych omezit jejich rychlost a prioritu také v případě probíhající konference.
Je v tomto případě lepší například další Mikrotik, udělat z něj pouze VPN server, napojit za řízený switch, snížit prioritu a dále používat nebo přenastavit současný HEX S a upravit rychlost zde?

Podotýkám že nemám mnoho času řešit velmi komplikované nastavení a chci aby případné úpravy a korekce byly co nejsnadnější ale plně funkční.

Zkoušel jsem nastavit již teď queue podle návodů ale nic z toho nefungovalo, chybu jsem nezaznamenal tak jsem vše vrátil do původního stavu.
Chci cestou co nejmenšího odporu vyřešit vše dalším zařízením.



_Jenda

  • *****
  • 1 577
    • Zobrazit profil
    • https://jenda.hrach.eu/
    • E-mail
Re:Řízený switch na základní správu sítě
« Odpověď #1 kdy: 09. 04. 2023, 13:11:17 »
Stačí na tohle obyčejný řízený switch "D-Link DGS-1100-08V2" nebo TP-LINK TL-SG108E Metal case nebo je potřeba již něco kvalitnějšího případně jaká funkce je nezbytná abych to nastavil?

Ne, tohle vůbec nechceš řešit switchem (jako teoreticky by to switch mohl umět řešit, ale omezí tím rychlost komunikace i v rámci LAN a vůbec je divné to dělat takhle). Tohle musíš nastavovat na svém hraničním routeru - na tom Mikrotiku.

Managovatelný switch bys potřeboval jen v případě, že se bojíš, že si nějaké z těch zařízení změní IP adresu a bude tropit bordel. I pak bych ale zvážil, jestli kupovat chytrý switch, a nevyužít buď přímo porty na tom Mikrotiku (hEX i skoro všechny další mají ten vnitřní switch plně konfigurovatelný) a kdyby nestačily, tak koupit dva hloupé switche a rozdělit síť třeba na dvě (důvěryhodná a nedůvěryhodná zařízení atd.)

Je v tomto případě lepší například další Mikrotik, udělat z něj pouze VPN server, napojit za řízený switch, snížit prioritu a dále používat nebo přenastavit současný HEX S a upravit rychlost zde?
Pokud to ten hEX hardwarově stíhá (měl by, já jsem na něm Wireguardem saturoval stomegabit), tak bych to určitě udělal přímo na něm.

Re:Řízený switch na základní správu sítě
« Odpověď #2 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.

bmn

  • ***
  • 160
    • Zobrazit profil
    • E-mail
Re:Řízený switch na základní správu sítě
« Odpověď #3 kdy: 09. 04. 2023, 15:40:30 »
Pokud je rychlost internetu tak do 100Mb/s, tak bych na ten hex S hodil OpenWrt a zapnul tam SQM na wan rozhraní s vhodně nastavenou rychlostí uploadu a downloadu. Myslím, že by tohle samo o sobě mohlo stačit. Až kdyby se to ukázalo jako nedostačující, tak bych začal řešit vlastní klasifikaci a traffic shaping.

Ještě pár let zpátky jsem měl na routeru skript co konfiguroval HFSC, ale co existuje CAKE (používaný v SQM), tak je to asi ve většině případů už jen zbytečná práce. Zmeřím běžně dosahovanou rychlost internetu v obou směrech, nastavím SQM trochu pod a je hotovo. Jede to dobře, nikdo si nestěžuje, i když se stahuje něco plnou rychlostí, běží dva videohovory a film na televizi.

Důležité je taky pohlídat, aby brzdou nebyla wifi.

Re:Řízený switch na základní správu sítě
« Odpověď #4 kdy: 09. 04. 2023, 17:23:02 »
... ale co existuje CAKE (používaný v SQM), tak je to asi ve většině případů už jen zbytečná práce. Změřím běžně dosahovanou rychlost internetu v obou směrech, nastavím SQM trochu pod a je hotovo.

Koukám na cake (na konci odkázané stránky je PDF slideshow) ... to vypadá jako krok správným směrem. Automatická přednost pro "řídký provoz", SQM dělá shaping taky v uplinku...

Docela mě překvapila informace, že jsou někteří ISP schopni nafrontovat před úzkým hrdlem směrem do poslední míle klidně několik minut provozu. To je masakr. V tom případě chápu motivaci, proč cake původně vznikl.
« Poslední změna: 09. 04. 2023, 17:26:15 od František Ryšánek »