Sávszélesség dinamikus elosztás

Hálózatok általános

Sziasztok!

 

Egy irodaházban vettek közösen egy nagyobb sávszélességet (300/300 Mbit) és felmerült, hogy megoldható-e az, hogy az érintett 4 cég a 4 vlanból szabadon használhatja a teljes elérhető sávszélességet, de lenne mind a 4 cégnek egy garantált 75/75, amit minden körülmények között megkap. Tudom, a bejövőt nem lehet garantálni, inkább csak az érdekelne, hogy ne vegyék el egymás elől a fenti minimumot. A project annyiban zöldmezős, hogy bármilyen router/megoldás szóba jöhet a fenti feladat megoldására. Tudom QoS megoldás lehetne, de itt 4 külön cég van, aki elvileg a ráeső részével azt csinál, amit akar.

 

Előre is köszi az ötleteket.

  • 456 megtekintés

( asm v | 2023. 01. 19., cs – 22:20 )

Ha jol tudom a QoS az inkabb arrol szol, hogy kulonfele prioritasu csomagok vannak es annak figyelembevetelevel tortenik a route-olas.

De ezesetben 4 azonos prioritasrol van szo, azonos szavszelesseg igennyel, igy lenyegeben a szabadrablasbol is pont ez alakul ki.

( kubi | 2023. 01. 19., cs – 22:28 )

Szerkesztve: 2023. 01. 19., cs – 22:30

Meg 20+ eve jatszottam ilyet Linuxon. Mar nem megy fejbol, de a Traffc Control howto eleg jo tampont. Talan SFQ HTB, ami neked kell.

De nyilvan jobb valami normalis router, ami tamogatja.

Öööö... de ennek nem csak akkor van értelme, ha a drót túlsó (szolgáltató felőli) végén van? Mert az user felőli oldalon max droppolhat. Meghát a túlsó végén is, ha koppra megy a queue.

Megoldásnak nem megoldás, de ha a cégek jó viszonyban vannak, akkor egy mrtg diagram a teljes és per cég elhasznált sávszélességről talán segítene. Pl. akkor, ha az Á user tőtene de lassú, akkor meg tudja nézni, hogy azért, mert tényleg lassú, vagy mert a Bé user épp arányt javít.

Kb.  mindegy, hogy hova rakod, ha nagyreszt jol viselkedo TCP forgalmad van. Mindenhol dobni fog elobb utobb (beffermeret veges), persze valamelyest jobb a szuk keresztmetszet elott. Volt valami olyan queue is, mi nem csak akkor dobott, amikor betelt, hanem a valoszinuseget novelte, ahogy telitodni kezdett. A veletlen dobalas jobb volt nehany regi TCP algoritmusnak. Manapsag talan mar mindegy, elvannak a burstos vesztessel is.

UDP flood ellen nem ved, foleg, ha customer oldalra rakod. De ilyenkor jon jol egy mely hangu ITs kollega, aki kimondja jol erthetoen, hogy ez bizony tulterheleses tamadas volt.

Szoval nem artana tudni, hogy milyen a forgalom, ha optimizalni akarjak a QoS megoldast. De viszonylag olcson is lehet elfogadhato megoldast kesziteni. Persze, remelem, nem egy taviranyitott szivsebesz robot log rajta...

--- szerk ---

Kis erdekesseg: net.ipv4.tcp_allowed_congestion_control = reno cubic
A reno valami kompatibilitasi problema miatt maradhatott ott?

Hátde oké, de nem mindegy, hogy amit eldobott az már elhasználta a sávszélességet, vagy még a szolgáltató felőli végén eldobja, az meg legyen az ő bajuk. És így nem sorvasztja a 300-as uplinket.

Na, de ezt írták lejjebb is.

Anno ezt - már a shapinget - úgy oldottam meg (vagy 20 év előtt), hogy volt két vonal, egy bérelt és egy ADSL. Az ADSL-en ment a letőtés, a bérelt vonalon a késleltetésre érzékeny forgalom. De ugye ez teljesen más eset volt.

Ha TCP kapcsolatokon megy a forgalom nagy resze, akkor szepen beall a rendszer (lasd TCP congestion control). Fair modon megkapjak a 75-75 Mbps-t, illetve a szabadon marado savszelesseget is a megfelelo aranyban, a HTB tokeletes erre. Szimplan csak be kell tenni egy routert (akar egy PC-bol ganyolt megoldas is jo, de azert inkab ne), amelyen mindket iranyba felepiti a megfelelo HTB fat, beallitja a szuroket, illetve a levelekre a qdisc-et. Persze nem art tisztaban lenni a burst es cburst parameterek hatasaval.

A hitetlenek levehetik a root ceil savszelesseget 300-X-re, igy a szuk keresztmetszet nem a 300 lesz, es akkor tuti nem az dugul el, hanem a shaping bufferek (ez a dolguk). Majd, miutan hinni kezd, X-->0, es akkor az elofizetok se sirnak, hogy a draga penzuket pazarolja a rendszergazda.

Ha elcseszett forgalmi mintak vannak, pl. valaki ezrevel nyit egyszerre TCP kapcsolatokat, akkor lehetnek atmeneti egyenlotlensegek. De ez par masodperc alatt kisimul.

Ha valamelyik jokepessegu kontrollalatlan/nem kooperativ/visszacsatolas nelkuli protokollal tolja meg kivulrol a linket, azzal el kell szepen beszelgetni.

( vl v | 2023. 01. 20., p – 01:57 )

Amennyiben a bejövő drót másik végén nem tudsz semmilyen QoS-t csinálni (márpedig egy szolgáltatói eszközön nem tudsz), akkor a problémának nincs igazi megoldása. A működő megoldás: egy hosting centrumban elhelyezni a saját készülékedet, és onnan dedikált vonalon jönni. Ennél persze nagyságrendileg olcsóbb venni 4 db kvázi-lakossági internet kapcsolatot.

Ha be tudsz tenni egy gépet a hostingba (ideális esetben a net szolgáltatónál), a router meg VPN-t húz ehhez és az irodaház teljes net felé menő forgalmát ebbe a VPN-be tolja, akkor van a szolgáltatói oldalon is eszköz a sávszélesség korlátozására.

Ezzel együtt tetszik a lentebb írt ötlet is: kártya 100MBPS-re korlátozása - ami kevésbé szép benne, hogy amikor más épp nem használ semmit, akkor hiába mehetne a 300 is, akkor is ott a limit, hogy 100.

a bejövő oldalnak lesz egy kimenő oldala, ahol már tudsz korlátozni.

Kérdés, hogy mind a 4 cégnek van-e saját IPcíme, vagy azon is osztoznak?

Egy mikrotik 4011-el, de még agy hAP ac3-al is vígan be lehetne ezt állítani.

ps: igen, tudom: ha kintről elárasztják a csövet, arra nincs megfejtés (nem, a 100mbps portsebesség sem az) - de első körben tételezzünk fel üzemszerű használatot.

( cadmagician | 2023. 01. 20., p – 09:45 )

én inkább úgy csinálnám,hogy 290mbitet dedikáltan porno letöltésre tennék, a többit meg simán elosztanám. a maradék 10en nincs mit balanszirozni...

Aki másnak vermet ás, az stack pointer.

( neutrino v | 2023. 01. 20., p – 09:47 )

100 Mbit-es portokra kell rakni a 4 cégedet és meg is van oldva a dolog, igaz nem pont 75 lesz, de nem igényel semmi agysebészetet.

1904.04.08.
RIP Jákub.
neut @

Komolyan mondtam. Ez a task nem igazán tűnik olyannak, hogy megérje a posztolónak kitalálni/megtanulni a terheléselosztást / szabályozást. Persze lehet ágyúval verébre menni meg mindenféle adaptív megoldással próbálkozni, de szerintem kurvára nem éri meg ezért.

1904.04.08.
RIP Jákub.
neut @

Csak ha az irodaban van mondjuk NAS cloud synckel/backuppal, vagy barmi hasonlo, akkor miert lennenek fixen 100Mbps-re korlatozva, mikor 300-zal is mehetne. Nyilvan csak akkor kellene korlatozni, amikor telitett a cso, nem mindig.

Vagy a masik megoldas, hogy nem kell csinalni semmit. Ez a 300Mbps van olyan sok, hogy ha vki fullba nyomja a torrentet, akkor is hasznalhato mellette a halozat a tobbieknek.

Es ha a NAS-rol toljak a torrentet? (amit az osszes SOHO NAS tud ugye)

Nem ismerjuk a reszleteket, de lehet hogy a telephelyen belul tavolabb vannak egymastol az irodak, tehat nem kozponti "szerverterem" lenne, hanem mindenki oldja meg magatol alapon. Ha 100M uplinket kapnak az irodak, akkor a NASuk is arra tud kerulni, ha 1G-t, akkor atmegy ilyen bizalmi dologba, hogy becsszo csak a NAS legyen direktbe kotve, tobbi kliens csak 100M utan.

Az egesz post errol szol kb. Mi van ha vmelyik iroda "tulterheli" a netet, a tobbieknek legyen garantalt savszele. Ha minden irodai Mancika csak levelezget es bongeszget lightosan, akkor nem all fenn ilyen helyzet. 300Mbps azert nem keves, YT/Netflix/HBOMax-bol is sok egyideju stream kell hogy telitodjon, talan a torrenttel lehet kimaxolni oly modon, hogy masok talan megerezhetik.

( lcsaszar v | 2023. 01. 20., p – 16:20 )

Arról még nem esett szó, hogy letöltés vagy feltöltés irányba, esetleg mindkettőbe kell-e ilyen korlátozás. A feltöltés irány az egyszerűbb de kevésbé hasznos. A letöltés irányra pedig tessék megkérni a szolgáltatót, vagy pedig be kell tenni egy routert, és annál már kimenő irány lesz a kliensek felé. Cisco-nál a priority parancs tud pl. garantált minimum sávszélességet biztosítani torlódás esetén. Ha nincs torlódás, akkor pedig megy a full sávszélesség. Ez működik WAN és LAN irányban is egy routeren belül, mindig kimenő irányban.

Más vendornál is biztosan van a priority-nek megfelelő QoS opció, más néven LLQ (low latency queuing). Ha az ember VLAN-onként akarja, akkor kicsit trükközni kell shaping-gel.

Befelé irányra hiába tesz akármit, az a forgalom, amit ott eldob, az már átment a vékony csövön - a cső túloldala a szolgáltatónál van, és tippelem, hogy a szolgáltató felé egy IP-n látszanak, tehát ott sem igazán van lehetőség a lefelé forgalmat a valódi cél alapján priorizálni.
Ahogy szó volt róla, egy saját kézben lévő "csövet" kell átdugni a 300-as vonalon, és annak a _két_ végén megvalósítani a priorizálást úgy, hogy már a csőbe _se_ menjen be az a forgalom, aminek nem kéne.

Pontosan ezt írtam, talán nem elég világosan: ingress QoS nem alkalmas a feladatra. Tehát be kell tenni egy saját Layer 3 eszközt, és azon már lehet konfigurálni a szolgáltató felé egress QoS-t, és a LAN felé szintén egress QoS-t. Az előbbi a kimenő forgalomra, az utóbbi a bejövő forgalomra.

Nyilvan jobb lenne, ha a szolgaltoto oldalan konfiguralhatna egy profi routert, tuzfalat, DPI-t es a vilagbeket. De ahol 4 ceg vesz egy olcso linket okosba, es meg egy rendes CPE sincs hozzaerto szemelyzettel, ilyen lehetoseg nem nagyon lesz.

Nem nagyon szamit, hogy bemegy-e a csobe a forgalom (TCP, vagy kb. barmi kooperativ protokoll eseten), ahogy ezt fentebb leirtam. Pont jo lesz nekik a customer oldali shaping mindket iranyra (ha megfizetik a szakertelmet hozza).

Ha szakerto sincs, akkor jo lesz a 100-as switchport :)

.

( zrubi v | 2023. 01. 20., p – 23:52 )

vettek közösen egy nagyobb sávszélességet (300/300 Mbit)

Ezeken mindig mosolygok :)

 

De magam is a 100Mbit-es fizikai porttal/linkkel korlátoznám.

Többet biztosan nem ér meg nekik sem, hiszen kici occó megoldást akartak, nem? :)

zrubi.hu

Ott a pont... Meg látott már olyat a világ, hogy 2*2M mikró, egyik 2M eladva ügyfélnek, másik eladva másik szolgáltatónak. Ügyfél tartalékvonalat is akart, másik szolgáltató eladta neki. Aztán jött a csodálkozás, hogy az ügyfélnek mindkét (éles és tartalék) vonalán egyszerre lesz karbantartás...