Bonding 2 bezdrôtových spojov

majklik

Pokud jedeš BGP, tak můžeš použít toto:

http://wiki.mikrotik.com/wiki/Manual ... 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

/ip route add dst-address=9.9.9.1/32 gateway=1.1.1.1,2.2.2.1,2.2.2.1

honza198

Díky

Pokud jedeš BGP, tak můžeš použít toto:

http://wiki.mikrotik.com/wiki/Manual ... 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

rado3105

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?

brody

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:

:-)

Ale nejsem zastancem ani jednoho. Proste tam ma prijit spoj, kterej to kapacitne zvlada a hotovo. Kazdopadne GL pri testech.

brody

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:

:-)

Ale nejsem zastancem ani jednoho. Proste tam ma prijit spoj, kterej to kapacitne zvlada a hotovo. Kazdopadne GL pri testech.

rado3105

je to v ramci testovania a viaceri vyuzivaju riesenie cez OSPF....a funguje im to a navyse maju aj failover druhej linky..

majklik

Jenom tu je rozdíl, pokud používám spojování linek přes OSPF/BFP/statické routy (což vše jsou případy ECMP), tak se jedno spojení jde vždy jen jendou linkou, kdežto u bondongu v režimu balance rr, ti to rozhází jendo spojneí do víc linek, a to dělá bordel. Chování vzdáleně podobné tomu ECMP ti udělá leda 802.3ad režim bondu s nějakou rozumně zvolenou hash politikou L3+L4.

jezdec

Ahoj rad bych ozivil toto tema.

Na jednom miste potrebuju propojit dva switche pomoci dvou ptp spoju ...takze bonding bud balance-rr nebo balance-alb ci balance-tlb

Switche jsou typu CRS s RouterOS (netPower16P) a PtP jsou dva kompletni spoje PowerBeam 5AC.
Pri vytvoreni bondingu sem narazil na klasicky problem u bezdratovych spoju (neprime propojeni techto switchu) a to konkretni ztrata pingu i na zarizenich zapojenych za druhym switchem apod.

- Vim ze jedno reseni je vytvorit EoIP tunel a nebo druhe, lepsi reseni je vytvorit VLAN nad fyzickymi porty.

Konkretne pak:
https://help.mikrotik.com/docs/display/ROS/Layer2+misconfiguration#Layer2misconfiguration-BondingbetweenWirelesslinks

Problem je v tom ze tento priklad je v podstate pro router, nikoliv pro switch.

Nastavil se to presne podle navodu, zda se ze samotny bonding bezi korektne, problem je v samotnem pingu, ktery nebezi vubec (na AP, klienta apod, proste na management spoje)

Port ze ktereho pingam (napr eth1- port kde je napriklad pripojen PC nebo nejake zarizeni )na danem switichi je sice v bridgi s bonding interface ale samotne porty ktere jsou v tom bondingu (eth2_vlan a eth3_vlan) jsou zaroven soucasti vlan ale eth1 nikoliv (proto ping neproleze)

Podotykam ze se jedna o ciste bridgovanou cast site .

Diky za kazdy tip a radu, mozna se to tu nekde resilo ale jde mi o konkretne o tento problem.

theitman

jezdec ¨vzhledem k tomu že řešíš rádia přes které prochází bonding spoje a máš tam prostřelené vlan tak podle mě můžeš ty fyzické porty dát normálně do bridge k ostatním a pokud ne tak jedině naroutovat...

jezdec

theitman

To neni reseni, dojde ke smycce (eth2 a eth3 je jiz obsazen v bonding interface)

theitman

jezdec v bonding interface máš snad jen ty vlan ne ? tak jak by mohlo dojít ke smyčce ? nebo pokud to rádia umí si je dej do další vlan. Nebo mi něco uniká ?

jezdec

theitman

Mam to presne tak jak je ten priklad v tom odkazu ale v bridgi mam eth1 a bonding (eth2_vlan a eth3_vlan), tak jak by to melo byt aby bezel provoz pres bridge. Ty my radis at tak normalne mrsknu jeste fyzicke eth2 a eth3 do toho bridge (abych se dostal na management tech spoju) ale to je blbnost protoze takto vytvorim smycku (odzkouseno).

theitman

jezdec sorry mě to prostě nedá, jak to vytvoří smyčku kudy to vytvoří smyčku když dáš na straně ap do toho bridge i ty dva čisté ethernety, smyčka by se vytvořila kdybys to dal do bridge na obou stranách. podle mě na straně AP do bridge na druhé straně nechat ve vzduchu a musí to fungovat není tam důvod aby to udělalo smyčku s jiným provozem se to nepotká ten zajišťují VLANy a na druhém konci to visí ve vzduchu stejně jako kdyby to rádio ten ethernet nemělo zapojený takže co udělá smyčku ?

a nebo proč to prostě nenaroutuješ ?

Další stránka »