classic.ISPforum.cz

Urobil som dva eoip tunely nad dvoma bezdrôtovými nv2 sieťami.
router1-ap1----bezdrôt---ap2--router2
-ap3---bezdrot---ap4-
router1 ma v5.26, router2 ma v6.10....

vsetky 4ap maju routeros v6.19
v router1 a router2 som urobil bonding interface, kde som dal ako slave oba eoip tunely....
kazdy bezdrotovy spoj mi da samostatne v 20 tcp 70mbit/s....
ked to dam testovat cez bonding ip ide to 50mbit/s.....

pouzitim mode: balance tlb (pri teste idu data len jednym eiop tunelom)

balance-rr udp testom 160mbit/s (pricom ked pozeram samostatne eoip tunely tak idu priblizne rovnakou rychlostou, po 80mbit/s) avšak pouzitim testu 20 tcp to ide po 15mbit/s, cize dokopy 30mbit/s....

balance -alb - tcp testom 38mbit/s, avšak len cez jeden eoip tunel.... udp test ani nemozne urobit
balance -xor - tiez iba cez jeden tunel....

V pořádku, chová se ti to jak má. Nebo jsi čekal něco jiného? Je třeba nezapomínat, že bonding neslouží k zvýšení proputnosti jednoho spojení, to neumí zajistit.
Ten ALB v UDP je možná následek toho, že EoIP se nevyrovnává úplně OK s neustálým měněním MAC adresy, co na něm ten bond driver provádí.

ale test robim pouzitim 20tcp...nie jedneho....alebo som ta nepochopil?

ballance-rr přece zvýší propustnost na jedno tcp.

hapi píše:ballance-rr přece zvýší propustnost na jedno tcp.

Nezvýší, nebo jen s velkým štestím, častěji reálně sníží, a to i když to budou dva bod-bod ethernet propoje a ne bezdrát, v některých případech případě způsobí, že něktteré krabice se sprzněným TCP stackem nebude schopna přes takový bond komunikovat nebo při efektivní rychlosti X se bude tlačit mnohem víc dat jako opakování. V reálu, v takovéto konfiguraci, to round-robin po paketech sice rozhází spojení na střídačku do těch dovu linek, ale díky bafrování v řadě míst cestou to nevyleze na druhé straně přesně tak, aby se to složilo, polezou ti z toho pakety jednoho spojení zpřeházené. Což je jedna z technik brždění TCP spojení, pokud se provádí správně cíleně. Druhá strana musí na příjmu data bafrovat, přeuspořídávat pakety, což se jeví jako prodloužení odezvy linky pro potvrzování. Vztah dlouhé odezvy, velikosti TCP okn a a celkové propustnosti TCP se tu řešilo mockrát. Navíc u některých TCP stacků jsou ořezané a neumí zvláště u fragmentovaných paketů udělat reordering zpět a zařízení pak není schopno udržet TCP spojení nebo neustále bude žádat o opakování. Některé TCP stacky s podporou vyžádání chybejícího paketu začnou posílat předčasně žádost o zopaková í segmentu a zaserou zbytečně linku stjenýma daty několikrát....
Tohle funguje jen na HW, který byl k tomu udělán a počítá s tím, že co synchronně rozhází do víc linek, tak na druhé strany zase složí ve správném pořadí zpět, pak to funguje na výbornou, ale to není případ bonding driveru.

rado3105 píše:ale test robim pouzitim 20tcp...nie jedneho....alebo som ta nepochopil?

Proř nefunguje RR viz výše. U dalších záleží jak nastavíš transmit hash politiku. Máš bodo-bod spojení mezi dvěma routery, to se z pohledu bond pro hask na L2 jeví vše jako jedno spojení. Stjeně tak pokud těch 20 TCP spojení navážeš mezi dvěma IPčkama a ne různýma, tak i na L3 vše 20 jeví jako jendo spojení. Až když použíješ L4, tak se může zčít jevit 20 spojení jako různá spojení, ale pokud si pamatuji, tak mikrotik do hashe bere jen cilovou IP a port, takže 20 různých spojení na stejné cíl IP:port je pořád jedno spojení. Takže celkové využití a rpzkládáín nastává, až proti sobw komunikují různé IP v různých psojení a ješt ěmusíš mít štestí, aby ten hash nevycházel i tak poříád na jendu linku (zkrátka to nebude rozkládat přesně půl na půl).
Takže ti rozkládání zátěže dělá jen režim, co vyvolává střídání MAC adres na příjmu (což ti blbo kvůli přepínání MAC adres) nebo to střídavé vysálání do různých linek neodvozované od IP a spol..

Funguje niekomu spravne niektory typ bondingu nad nv2?
Mody mam ap bridge a station bridge v oboch pripadoch wireless liniek.

Bondingovat jdou pouye fullduplex spoje. Je nutne nejprve nad wireless spojem spustit eoip nebo mlps a ten dat do bondingu.
Aspo tak nas to ucil K. Klima

Pokud se snažíš bondovat wifi spoje, tak zcela zásadní, nikoliv však postačující, podmínka je, že se spoje nesmí rušit mezi sebou navzájem.
Tj. před pokusy pustit oběma spoji najednou stejným směrem btest naplno a snažit se bondovat až když se CCQ drží trvale nad 95procent.
Jinak to nemá cenu.

ef píše:Bondingovat jdou pouye fullduplex spoje. Je nutne nejprve nad wireless spojem spustit eoip nebo mlps a ten dat do bondingu.
Aspo tak nas to ucil K. Klima

ja som to mal uz rozbehane..ide to aj cez ospf...len uz som nemal nejako cas laborovat, v 6.20 su nanovo prekopane tunely tak ked bude cas sa do toho pustim

zdarec lidi, omlouvam, se, ze znova oteviram tema, ale realizuju ted propoj:
MT (RB450G RoS 6.20) -> VLAN PtP VLAN -> MT (CCR1016G RoS 6.20) 100mbit - latence 2 - 3 ms
MT (RB450G RoS 6.20) -> VLAN PtP VLAN -> MT (CCR1016G RoS 6.20) 200mbit - latence 2 - 3 ms
Da se tohle zbondovat? Cela sit jede v BGP.

Pokud jedeš BGP, tak můžeš použít toto:
http://wiki.mikrotik.com/wiki/Manual:BG ... interfaces
Jenom s úpravou, že když druhá lajna je 2x tlutá co první, tak ta statická rekurzivní oruta bude:
/ip route add dst-address=9.9.9.2/32 gateway=1.1.1.2,2.2.2.2,2.2.2.2
a
/ip route add dst-address=9.9.9.1/32 gateway=1.1.1.1,2.2.2.1,2.2.2.1

Díky

Majklik píše:Pokud jedeš BGP, tak můžeš použít toto:
http://wiki.mikrotik.com/wiki/Manual:BG ... interfaces
Jenom s úpravou, že když druhá lajna je 2x tlutá co první, tak ta statická rekurzivní oruta bude:
/ip route add dst-address=9.9.9.2/32 gateway=1.1.1.2,2.2.2.2,2.2.2.2
a
/ip route add dst-address=9.9.9.1/32 gateway=1.1.1.1,2.2.2.1,2.2.2.1

skusal som aj v novych verziach 6.25....najlepsie slo balance-rr to to delilo....
udp som dosiahol 120mbit/s, tcp 50-70mbit/s (pricom jeden spoj da od 40 do 55mbit/s
odozva kolisala od 2 do 19ms....
dva eoip tunely vytvorene nad dvoma nv2 spojmi a tie bondovane..cez bonding

uvazujem nad tym ospf bondingom ale ak to dobre chapem tak na konci oboch spojov bude potrebne pred pripojenim do siete vlozit dalsi router ktory bude smerovat dany traffic...alebo to ide aj bez toho?

Ja moc nechapu proc to tu resite porad do kola, souhlas s Majklikem. Jdete radsi na pivo a nebo za ten cas dete neco delat a za to si kupte poradnej spoj.
Pokud rozhazite packety 2 smery, tak neprijdou v bondindgu ve stejnem poradi. UDP protokolu je to samozrejme jedno, takze proto
ta propustnost kterou byste tam chteli videt. Ale realny prenosy na TCP proste takhle nikdy chodit nebudou. A to z duvodu bufferu,
razeni dat a zmensujici a zvetsijici se velikosti okenka.

Dost napovi napriklad:

http://en.wikipedia.org/wiki/Sliding_window_protocol
http://en.wikipedia.org/wiki/Flow_control_%28data%29

Reseni pomoci BGP je asi mozny, ale to jak si dost lidi predstavuje, ze mezi 2 routeru nacpou 2x 5GHz spoj v bridgi misto jednoho je proste nerealny
Ale nejsem zastancem ani jednoho. Proste tam ma prijit spoj, kterej to kapacitne zvlada a hotovo. Kazdopadne GL pri testech.