Alcoma + PB10 nebo NB5 = problém?

[Spreamer]

Dobrý den,

již 1-2 roky mě trápí problém v síti, který je stále více cítit s ohledem potřeby klientů na vyšší linky. Mám spoj Alcoma Mp360 nyyní s licencí 160 Mb/s. Na ní je připojen rb850+CRS. Na switchi je propustnost stále 160 Mb/s. Na připojených lokalitách ( většinou UBNT PB10 nebo nanobridge M5) nedostanu více jak 30-40 Mb/s na jedno TCP spojení. Když řetězím třeba 3x PB10 za sebou, tak není takový dopad na propustnost a měřím na 11 spojení třeba 70Mb/s. Nevíte, co to způsobuje? Přechod v ethernetu z 1GB na 100 Mb/s? Když vypnu airmax na nanobridge, tak je výsledek stejný. Routery jsem už různě zkoušel měnit, stejně tak měnit verzi routeros. Určitě se s tím někdo setkal, Poradíte? To budu muset vše stavět na FDD spojích, když chci dosáhnout požadové propustnosti?

Děkuji za rady.

[Dalibor Toman]

s MT ke kterym je pripojena ALCOMA s vyssi eth rychlosti nez 100mbps nemame dobrou zkusenost. IMHO si MT s ALCOMOU nerozumi a nedohodnou se spravne kdo bude slave a kdo master na gigabit ethernetu. Pak dochazi k tomu, ze se na jedne ci druhe strane zahazuji prijimane packety (pocet zavisi zrejme mimo jine na tom jak moc se rozsynchronizuje casovani). Cili kontrolovat chybovost na receive strane.

Dalsi mozny problem je klasika (pisu o tom furt dokola) - bursty versus male buffery. Switchem pribehnou data na 1gbps a odejit maji nejakou mensi rychlosti, sswitch nema prostor na ulozeni a packet se zahodi. Nejmarkantnejsi/nejzakernejsi to je prave u radiovych tras, ktere sice maji na eth link 1gbps ale prenesou vyrazne mene. V tom pripade to switch ani nevi a packety zahazuje az radio. Tady pomoze zapnout flowcontrol na radiu - problem se prenese na switch (zarizeni pred radiem). Tady je potreba aby to k cemu je pripojene radio alespon umoznovalo delat graf z packetu zahozenych kvuli ucpane odchozi fronte (outDiscards). To aby se o velikosti problemu alespon vedelo. Sem tam se nejaky packet discardne prakticky vsude, ale jsou pripady, kdy uz to nejsou jednotky za 5 minut ale vyssi cisla za sekundu a pak je to treba resit (protoze uz to bude ovlivnovat provoz) = nastavit vetsi buffery ci vymenit switch za lepsi, rychlejsi radio radio, ktere samo ma vetsi buffery atd.

[Spreamer]

Takže raději nasazujete jiné rádia, například Racomy?

Případně na těchto místech s Alcomou neroutujete a používáte switche, případně doporučíte značku v rozumné cenové hladině?

Na všech ethernetech nevidím nevidím TX/RX drops ani jiné chyby.

Vellice děkuji

[ludvik]

Problém Master/Slave Alcoma vyřešila už před docela dlouhou dobou ... viewtopic.php?t=11839&start=30

Problém s bursty je schopen si vyzkoušet sám a ten bandwidth test pustit omezený na rychlost nižší, než je nejhorší spoj. Tipnu si, že tím to nebude. I když pomoc QOSem na obou stranách bude určitě vítaná. Čítače na eth u mikrotiků jsou otázka náhody. Při správné kombinaci switch čipu, verze firmware a ROS, konfigurace a možná i předpovědi počasí to něco ukáže. Ve výsledku ovšem nevím, jestli to mám bezchybné, nebo mi to jen neukazuje.

Řetězení half-duplexů je prostě pakárna. Když to zkombinuješ s různými rychlostmi spojů, lowcost zařízeními po cestě ... máš zábavu na zimní večery.

[Dalibor Toman]

Takže raději nasazujete jiné rádia, například Racomy?

Případně na těchto místech s Alcomou neroutujete a používáte switche, případně doporučíte značku v rozumné cenové hladině?

pouzivame prakticky jen ALCOMy. Pripojene k ciscu. Jednu MP165 jsme nedavno pripojili k RB2011 a abychom se zbavily problemu, musel do SFP sachty metalicky eth modul - na nem ALCOMA nechybovala (na rozdil od 1gbps portu na te 2011).
Z 'levnych' cisco switchu mam nejradeji 2960X, ktere konecne uz maji relativne dost bufferu. relativne dobre na tom jsou jeste 2960, ktera maji 100vkove porty a 2 gigove uplinky. Tam je tusim 2MB bufferu takze spravbne vytuneny (alokace bufferu) QoS na tech portech dokaze nejake ty bursty vyhladit.

PS: problem neni o tom, zda se routuje nebo switchuje. Je to jen o tom jestli je (kdekoliv na spravnem miste) dost bufferu na pozdrzeni packetu.

Na všech ethernetech nevidím nevidím TX/RX drops ani jiné chyby.

Vellice děkuji

dulezite je vedet, ze ten switch je schopen ty ztraty opravdu zaznamenat. v SNMP je to (alespon u cisca) Discard counter (i kdys show interface to zobrazuje jako drops). Nektere starsi IOSy to take neumely. MT vsechny, co mame tak na zverejnovani chyb v SNMP kaslou.

[Dalibor Toman]

Problém Master/Slave Alcoma vyřešila už před docela dlouhou dobou ... viewtopic.php?t=11839&start=30

tim, ze pridala moznost nastavit master ci slave natvrdo. Ale to problem nemusi resit. Pomohlo nam to pri reseni problemu s ciscem ale v pripade nedavnych potizi MP165 versus RB2011 nikoliv. Pomohlo az pouziti toho SFP metalickho modulu (cili jina 'fyzicka vrstva' na strane MT). Nas problem nebyla nemoznost navazat link ale v tom, ze se ztraci packety.

Problém s bursty je schopen si vyzkoušet sám a ten bandwidth test pustit omezený na rychlost nižší, než je nejhorší spoj. Tipnu si, že tím to nebude.

dosahnout po TCP neburstovaneho toku neni uplne trivialni takze to se mu zrejme nepovede ani snizenim rychlosti v BW testu. TCP prenos je z principu burstovany - pokud se rozumne rychle zaplni prenosove okno posle se najednou plnou rychlosti portu v zarizeni, ktere je zdrojem dat. A to nemluvim o tom, ze by se musel zbavit ostatniho trafficu.
Pokud ale bude generovat UDP prozovoz (a vylouci dalsi traffic linkou) s omezenou max rychlosti nizsi jez je nejslabsi clanek linky, pak ma sanci dosahnout bezchybneho stavu. Pokud by na lince existoval problem s bufffery tak se v tomto pripade neprojevi (packety se ale nesmi nikdo hromadit coz u half duplex spoju neplati).

[Insider]

To nemá Flowc ontrol?

[Dalibor Toman]

To nemá Flowc ontrol?

ALCOMA? ma (TX).
CISCO? ma (RX)

a ?

[Spreamer]

Podle mě tedy nemá smysl kupovat cisco switch za 30k, pokud je k němu stejně připojen laciný half duplex spoj. Budu to muset řešit FDD pojítkem za úplně jiné peníze. Pak se uvidí, jestli budou nutné další zásahy.

[Insider]

Řešil jsme to v případě přechodu z jednoho o hodně rychlejšího rozhraní, do pomalejšího. Typicky Gbit CCR do radia (i přes switch) do nějakého standardního MT, nebo i do klasického PDH, který díky tomu, že to je není simplex, tak to tam umí narvat pěkně po sobě. U klasickýho simplexu, ale přepínáním dochází k plnění bufferů na MAC vrstvě, ale nezabezpečuje to mezipaketové mezery na ETH. Po aktivaci Flowcontrolu problémy zmizí, protože vstupní ETH si řekne jenom o takové množství dat a mezipaketových mezer, které dovede MAC vrstva simplexniho radia odbavit. Velké buffery jsou fajn, ale jsou doménou právě dražších routovacích platforem. Pokud to není ošetřené, tak se není čemu divit. Pak je jasné, že stavová logika pakety zahazuje, protože přetečou vstupní buffery ETH, který to nemá kam dál podat a holt to zahodí. K tomu ale právě slouží flow control který domluví s adapterem protější strany dávkování dat pouze s takovou mezipaketou mezerou, která zajistí jejich vypravení dalším aktivním prvkem, protože ten si o data "žádá" rychlostí a dávkováním, aby to vyhovělo MAC radia.

Přetečený buffer na ETH i u TCP znamená zahozený paket a jeho znovu vyžádání na základě absence ACK, to trvá .. - to bere čas a ten znamená malou propustnost, nehledě na špatné pořadí paketů. Když se to zřetězí, nené se čemu divit.

[Spreamer]

Řešil jsme to v případě přechodu z jednoho o hodně rychlejšího rozhraní, do pomalejšího. Typicky Gbit CCR do radia (i přes switch) do nějakého standardního MT, nebo i do klasického PDH, který díky tomu, že to je není simplex, tak to tam umí narvat pěkně po sobě. U klasickýho simplexu, ale přepínáním dochází k plnění bufferů na MAC vrstvě, ale nezabezpečuje to mezipaketové mezery na ETH. Po aktivaci Flowcontrolu problémy zmizí, protože vstupní ETH si řekne jenom o takové množství dat a mezipaketových mezer, které dovede MAC vrstva simplexniho radia odbavit. Velké buffery jsou fajn, ale jsou doménou právě dražších routovacích platforem. Pokud to není ošetřené, tak se není čemu divit. Pak je jasné, že stavová logika pakety zahazuje, protože přetečou vstupní buffery ETH, který to nemá kam dál podat a holt to zahodí. K tomu ale právě slouží flow control který domluví s adapterem protější strany dávkování dat pouze s takovou mezipaketou mezerou, která zajistí jejich vypravení dalším aktivním prvkem, protože ten si o data "žádá" rychlostí a dávkováním, aby to vyhovělo MAC radia.

Přetečený buffer na ETH i u TCP znamená zahozený paket a jeho znovu vyžádání na základě absence ACK, to trvá .. - to bere čas a ten znamená malou propustnost, nehledě na špatné pořadí paketů. Když se to zřetězí, nené se čemu divit.

Takže doporučujete zapínat flow control hlavně při přechodu z 1G ethernetu na 100M nebo zapnout F.C. i například mezi routerem a switchem, které jsou v gigabitu (např. v jednom racku). Díky

[Insider]

Řešil jsme to v případě přechodu z jednoho o hodně rychlejšího rozhraní, do pomalejšího. Typicky Gbit CCR do radia (i přes switch) do nějakého standardního MT, nebo i do klasického PDH, který díky tomu, že to je není simplex, tak to tam umí narvat pěkně po sobě. U klasickýho simplexu, ale přepínáním dochází k plnění bufferů na MAC vrstvě, ale nezabezpečuje to mezipaketové mezery na ETH. Po aktivaci Flowcontrolu problémy zmizí, protože vstupní ETH si řekne jenom o takové množství dat a mezipaketových mezer, které dovede MAC vrstva simplexniho radia odbavit. Velké buffery jsou fajn, ale jsou doménou právě dražších routovacích platforem. Pokud to není ošetřené, tak se není čemu divit. Pak je jasné, že stavová logika pakety zahazuje, protože přetečou vstupní buffery ETH, který to nemá kam dál podat a holt to zahodí. K tomu ale právě slouží flow control který domluví s adapterem protější strany dávkování dat pouze s takovou mezipaketou mezerou, která zajistí jejich vypravení dalším aktivním prvkem, protože ten si o data "žádá" rychlostí a dávkováním, aby to vyhovělo MAC radia.

Přetečený buffer na ETH i u TCP znamená zahozený paket a jeho znovu vyžádání na základě absence ACK, to trvá .. - to bere čas a ten znamená malou propustnost, nehledě na špatné pořadí paketů. Když se to zřetězí, nené se čemu divit.

Takže doporučujete zapínat flow control hlavně při přechodu z 1G ethernetu na 100M nebo zapnout F.C. i například mezi routerem a switchem, které jsou v gigabitu (např. v jednom racku). Díky

Zapnout jakmile je tam po cestě medium, které má menší než nativní kapacitu rychlejší linky.. CCR se s tím vůbec nemydlí a pakety skládá v podstatě bez mezer stejně jako HW switche od MT, chce to vyzkoušet, ale my sjme s tím slavili celkem úspěchy.. U PDH radia co vyrábíme, tak bez FC na adapteru, který má kapacitu 750 Mbit protlačíme max. 710-720Mbit se zaplym FC 748,9 stabilně, U AirBQ bez FC propustnost na 1 peer cca 30-35Mbit s FC 100+.

[Spreamer]

Řešil jsme to v případě přechodu z jednoho o hodně rychlejšího rozhraní, do pomalejšího. Typicky Gbit CCR do radia (i přes switch) do nějakého standardního MT, nebo i do klasického PDH, který díky tomu, že to je není simplex, tak to tam umí narvat pěkně po sobě. U klasickýho simplexu, ale přepínáním dochází k plnění bufferů na MAC vrstvě, ale nezabezpečuje to mezipaketové mezery na ETH. Po aktivaci Flowcontrolu problémy zmizí, protože vstupní ETH si řekne jenom o takové množství dat a mezipaketových mezer, které dovede MAC vrstva simplexniho radia odbavit. Velké buffery jsou fajn, ale jsou doménou právě dražších routovacích platforem. Pokud to není ošetřené, tak se není čemu divit. Pak je jasné, že stavová logika pakety zahazuje, protože přetečou vstupní buffery ETH, který to nemá kam dál podat a holt to zahodí. K tomu ale právě slouží flow control který domluví s adapterem protější strany dávkování dat pouze s takovou mezipaketou mezerou, která zajistí jejich vypravení dalším aktivním prvkem, protože ten si o data "žádá" rychlostí a dávkováním, aby to vyhovělo MAC radia.

Přetečený buffer na ETH i u TCP znamená zahozený paket a jeho znovu vyžádání na základě absence ACK, to trvá .. - to bere čas a ten znamená malou propustnost, nehledě na špatné pořadí paketů. Když se to zřetězí, nené se čemu divit.

Takže doporučujete zapínat flow control hlavně při přechodu z 1G ethernetu na 100M nebo zapnout F.C. i například mezi routerem a switchem, které jsou v gigabitu (např. v jednom racku). Díky

Zapnout jakmile je tam po cestě medium, které má menší než nativní kapacitu rychlejší linky.. CCR se s tím vůbec nemydlí a pakety skládá v podstatě bez mezer stejně jako HW switche od MT, chce to vyzkoušet, ale my sjme s tím slavili celkem úspěchy.. U PDH radia co vyrábíme, tak bez FC na adapteru, který má kapacitu 750 Mbit protlačíme max. 710-720Mbit se zaplym FC 748,9 stabilně, U AirBQ bez FC propustnost na 1 peer cca 30-35Mbit s FC 100+.

Velice děkuji za radu, je to již mnohem lepší! Zapnul FC jsem od brány (CCR) až po CRS, kde jsou již napojeny HD spoje a již dostanu stabilně 60/60 Mb/s (limit spoje). Ať se Vám daří!

[GRFS]

No ono to neni uplne jednoznacne. Velikost bufferu ma vliv na latenci a jitter. Navrhnout takovovou velikost, aby se zavdecila vsem, je nemozne. Zalezi hodne na provozu v siti a topologii site. Pokud si vystacite s netagovanym provozem, tak flow control problem resi. Jakmile aplikujete QoS a VLANy, budete muset flow control vypnout, pokud nechcete, aby vam FC diky tahani za dratky zabijel IPTV, VoIP atp. Flow control pracuje na fyzicke vrstve a bude vam ovlivnovat veskery VLAN provoz na portu.

Jinak TCP provoz sam o sobe je pri kongesci bufferu to nejvetsi zlo. Jakmile dojde k jeho preteceni, zariznou se vsechny TCP sessions jdouci radiem a nasledne dochazi ke kolisani v propustnosti/zateze az o 50%, tak jak dochazi k opakovani prenosu a obnovovani jednotlivych sessions. K tomu jsou pak u lepsich krabicek k disposici algoritmy jako Weighted Random Early Detection, ktere zamezi totalni kongesci bufferu nahodnym zarezavanim vybranych TCP sessions tak, jak se provoz blizi maximu.

Cili cesta ke stabilite site u flow control zacina, ale rozhodne si s tim v budoucnu nevystacite.

[Dalibor Toman]

DD,

myslim, ze to s tema VLANkama versus FlowControl je nesmysl. Jak by mohlo FlowControl udelat VLANce neco nepekneho (neco jineho nez nez packetum na portu bez VLANek)?