Stránka 1 z 2

OSPF bonding

Napsal: 14 Sep 2014 20:46
od rado3105
Mam dva body spojene bezdrotovo jednym spojom. Routing je robeny staticky. Dnes som pridal dalsi bezdrotovy spoj zapojil do routrov na oboch bodoch.
http://blog.butchevans.com/2008/10/usin ... ess-links/
skusam tento typ bondingu, avsak pocas bandwitch testu idu data len jednym spojom. Je to sposobene tym ze popri ospf je jedna z liniek routovana aj staticky? je potrebne vypnut staticke routovanie a nechat len ospf?

Re: OSPF bonding

Napsal: 14 Sep 2014 20:55
od Majklik
Pokud ta statická routa má menší metriku než to co dává OSPF (110), tak se uplatňuje statika před OSPF.
OSPF používá ECMP pro rozkládání provozu, to si můžeš udělat i ručně staticky:
/ip route add dst-address=10.1.1.0/24 gateway=10.1.2.3,10.4.5.6
Zkrátka namláýtíš víc bran dle počtu jednotlivýxh linek patřičně z obou stran...

Re: OSPF bonding

Napsal: 14 Sep 2014 21:08
od rado3105
toto bolo na jednom bode:
1.jpg
1.jpg (3.73 KiB) Zobrazeno 722 x


toto na druhom:
2.jpg
2.jpg (12.88 KiB) Zobrazeno 722 x


a stale to islo cez ten spoj ktory tam bol primarne - 10.10.58.0/24...tu ukazovalo cost 1, pri tom druhom nic....
test robim jednosmerne, pouzitim 20tcp...

Re: OSPF bonding

Napsal: 14 Sep 2014 21:17
od Majklik
ECMP se opět uplatňuje per spojení. Takže musíš tlačit víc různých spojení, aby se začlo využívat obou tras.

Re: OSPF bonding

Napsal: 14 Sep 2014 21:26
od rado3105
Robil som 20 tcp spojeni...
Dokazem takto v pripade jednosmerneho toku spojit obe priepustnosti, cize ak jeden spoj da 70 a druhy tiez, Tak dosiahnem pri jednosmernom teste 140? alebo je mozne dosiahnut len full duplex 70/70?

Re: OSPF bonding

Napsal: 14 Sep 2014 21:36
od Majklik
Ach jo, 20 TCP spojení jendím bandwitch testem chápe ECMP jake jedno spojení. :-) Musí jít o různé IP adresy, aby to rozlišoval jako různé spojení (přesněji se spojení vyhodnocuje dle shody zdrojová adresa, cílová adresa, vstupní interfejs, TOS a routing mark).
Jedno spojení umí ucpat jen jednu linku. Aby jsi ucpal obě linky na 100%, tak to musíš mít dost štestí, nebude to symetrické. ECMP neřeší aktuální ucpanost, jenom nově detekované spojení posílá pokaždé do jiné linky (a jednou za 10 minut zresetuje cache a uspořádává spojení do linek po novu).

Re: OSPF bonding

Napsal: 14 Sep 2014 21:56
od rado3105
1 tcp spoj dava 50mbit/s jednosmerne....v pripade dvoch bran ako uvadzas vyssie dava 30mbit/s...preco?

Re: OSPF bonding

Napsal: 14 Sep 2014 22:02
od Majklik
Odhad os stolu - pokud to jedeš přes ty NV2 linky, tak se ti to rozložilo tak, že jendím směrem to jde jendou trasou a potvrzování zpět druhou. A ty dvě linky vedle se be se ruší nebo vzhledem k čsování NV2 a posunu časování těch dovu linek vedle sebe to má v tomto režimu delší RTT pro TCP potvrzování.

Re: OSPF bonding

Napsal: 14 Sep 2014 22:08
od rado3105
Majklik píše:Odhad os stolu - pokud to jedeš přes ty NV2 linky, tak se ti to rozložilo tak, že jendím směrem to jde jendou trasou a potvrzování zpět druhou. A ty dvě linky vedle se be se ruší nebo vzhledem k čsování NV2 a posunu časování těch dovu linek vedle sebe to má v tomto režimu delší RTT pro TCP potvrzování.



toto by to teoreticky mohlo byt...
pouzivas bonding? resp. ktora metoda bondingu je podla teba v tomto pripade ze chcem spojit dva spoje najvhodnejsia?

Re: OSPF bonding

Napsal: 14 Sep 2014 22:43
od hapi
kámo, vylepši si jeden spoj a na dva se vykašli. Budeš mít jenom problémy.

Jakákoliv technologie co slučuje víc linek dohromady v drtivý většině rozlišuje src a dst adresy a pak to pouští jenom jedním spojem. Typicky bonding na switchy v jakýkoliv režimu to tak dělá. Neni možný tedy využít třeba 2Gbit na gbit portech na jedno spojení. Musí tam bejt víc zdrojů nebo cílů. Leda by si měl extra featury.

Re: OSPF bonding

Napsal: 15 Sep 2014 17:23
od okoun
jo ale když budeš stahovat třeba ze steamu tak ti to hodí teoreticky ten 2Gb, teoreticky

Re: OSPF bonding

Napsal: 16 Sep 2014 09:28
od Majklik
rado3105 píše:
Majklik píše:Odhad os stolu - pokud to jedeš přes ty NV2 linky, tak se ti to rozložilo tak, že jendím směrem to jde jendou trasou a potvrzování zpět druhou. A ty dvě linky vedle se be se ruší nebo vzhledem k čsování NV2 a posunu časování těch dovu linek vedle sebe to má v tomto režimu delší RTT pro TCP potvrzování.


toto by to teoreticky mohlo byt...
pouzivas bonding? resp. ktora metoda bondingu je podla teba v tomto pripade ze chcem spojit dva spoje najvhodnejsia?


Ještě ti v té sérií cvičení chybí zkusit si traffic engineering nad MPLS. :-) Ale neboj, dopadneš stejně (maximálně bude změna v tom, že nastavíš, aby se používala první trasa a až bude trasa plná, tak část provozu se poslalo druhou), jenom se o dost víc konfiguračně nadřeš...
Nepomůžeš si také. Čií-li jak říká Hapi - pořid tlustější rádio a druhou linku třeba někudy jinudy jen jako zálohu, když primár zdechne.
Bonding používám běžmě, ale jen režimy active-backup nebo LACP a jen na Ethernetu. A skřípu u toho zubama, protože v tom má ROS, jak je dobrým zvykem, několik chyb. Takže někdy raději než active-backup, tak je lepší použít třeba bridge a RSTP.
Co se týče ECMP ve vztahu k OSPF, tak to používám, ale je třeba si být vědom, co to dělá a nečekat od toho zázraky. Alůe chce to opět přes trošku rozumné linky. Protože když uděláš několik skoků na NV2 jendu linku a několik skolů nad NV2 jako druhou trasu. Tak když to sedne tak, že TCP spojneí půjde jendou trasou a potvrzování druhou, tak si v podstatě začneš hrát na SDH kruhy, akorát takové, které jsou krutě nesynchronní se všema z toho plynoucíma problémy. :-)

okoun píše:jo ale když budeš stahovat třeba ze steamu tak ti to hodí teoreticky ten 2Gb, teoreticky


Záleží jak daná technologie bude dělat rozklad do víc směrů. U OSPF/BGP/statického ECMP může jeden koncový klient ucpat víc tras, pokud bude stahovat z různých serverů (IP adres), takže se to vyhodnotí jako různé spojneí a bude je rozhazovat. U L2 technologií, např klasické LACP trunky, záleží jak moc chytré to bude. Jendodušší krabice jedou rozklad jen na základě cílové MAC adresy, tu má klient jendu, takže půjde k němu vše jendím směrem. Chytřejší berou xor src i dst MACky (to dělá i bond v ROS), pak už to může být jiné, ale pokud je to mezi routerem ven a klientem, tak jsou MACky pořád stjené, tak také nic a vše jendou linkou. Až co začne brát v potaz L3 a/nebo L4 src i dst pak u různých stahování může začít vytěžovat víc linek.

Re: OSPF bonding

Napsal: 16 Sep 2014 16:20
od rado3105
samozrejme ze to neriesim na viacerych skokoch...cisto na jednom...
...ale u jedneho klienta nas to ani nezaujima, malokto dava vzduchom jednej osobe nad 30mbit/s....a v takom pripade samozrejme treba riesit kvalitu linky...ale ked to chces na spoj a zvysit jeho kapacitu...kde su stovky spojeni roznych mac, ip...tak tam to vyuzitelne vidim...ci nie?

Re: OSPF bonding

Napsal: 17 Sep 2014 10:54
od Majklik
Ano, kde ti půjde víc rlzných spojení z pohledu ECMP, tam se rozklad využije a budeš obvkyle dosahovat větší celkové kapacity do daného místa než když tam ten spoj bude jen jeden, pokud se ti ty dva NV2 spoje vedle sebe nebudou moc rušit.

Re: OSPF bonding

Napsal: 17 Sep 2014 18:32
od rado3105
Majklik píše:Ano, kde ti půjde víc rlzných spojení z pohledu ECMP, tam se rozklad využije a budeš obvkyle dosahovat větší celkové kapacity do daného místa než když tam ten spoj bude jen jeden, pokud se ti ty dva NV2 spoje vedle sebe nebudou moc rušit.

je potom vhodnejsi nstreme? namiesto nv2