Virtualny spoj nad ptp spojom, co zvolit? je mozny?

[rado3105]

MK1-ethernet-MK2-ethernet-MK3--wifi--MK4--ethernet-mk5(klienti, dalsi connect....)

Riesim situaciu, ze jedna firma, ktorej spravujem siet ma priblizne takuto architekturu, hlavny privod internetu ide do MK1(hlavna brana), z mk5 ide wifi, kde je pokrytie budovy, taktiez do tejto budovy ide internetove pripojenie(do ethernetu mk5), ktore by chceli vyuzit v pripade padu hlavneho, popripade aj spojit a pustit tam niektore sluzby).
VPNkom by to slo dostat cez tunel az do MK1, ale to by bolo zbytocne plytvanie, kedze vpn zrave...
Ako inak by to bolo mozno dosiahnut? Je mozne to urobit cez vlan?

PS: cela siet je routovana....ziadny bridge...

[Majklik]

A ta trasa MK1 až MK5 je routovaná nebo to je L2 bridge? Pokud bridge, tak VLAN na propoj MK1-MK5 v pohodě.
Jinak možné řešení při bridge je to, že nahodíš VRRP, kde koncové body budou MK1 a MK5, nahodíš dvě VRRP, kdy jedne bude v defualtu přitažne k MK1 a druhý k MK5 a jen nastavuješ lidem příslušnou virtuální IP dle toho, kterou linkou mají odcházet, když jenda strana chcípne nebo se ti rozpůlí síť, stáhne se vše k té žijící/místní straně.
Pokud to máš routovaní, stejné řeší např OSPF a ten virtuální propoj přes EoIP.
Už máš namalovanej obrázek, jak si žádá Kpt. RUM na rootu?

[asdewq]

akurat ze eoip ma dost problem s priepustnostou.. na linky radovo v mbitoch je to v pohode ale pri vyssom konekte je to trochu problem (niekto to rozoberal aj na skfree) osobne pozorujem totozny problem a badam cim eoip nahradit

[rado3105]

ano eoip v podobe mikrotiku nefunguje.....spajal som tak dva n-kove spoje a vysledok bol este slabsia priepustnost ako jeden n-kovy....ale spat k teme:

http://tinypic.com/view.php?pic=14so0ua&s=6
narychlo nakreslene....

takze eoip nie, vpn nie....vlan?
ake su dalsie moznosti?

PS: neriesim teraz situaciu ako tie dva nety spojit(vrrp..a ine) ale len ako to dostat do hlavnej brany...

[Majklik]

EoIP je v pohodě, pokud dokáži zabránit fragmentaci. Záleží na RBčkách ('a switchích po cestě), zda dokážu použít L2MTU tak, aby uvnitř tunelu jsem udržel MTU1500 bez fragmentace na fyzickém přenosovém kanálu.
Obecné doporučení od Mikroťáků je místo EoIP používat VPLS, ale konfigurace je kapánek spožitější než to EoIP.
Pokud to nemáš v bridge, nepotřebuješ ani L2 tunel, takže dle libosti GRE nebo IPIP jde použít. Otázka je, proč tam chceš nějak tunel od MK5 k MK1 plácat.
Dle toho obrázku bych si nedělal násilí a pomocí OSPF posílal defualt gate na jednu nebo druhou stranu, když to poctivě routuješ.

PS: Mizerná propustnot dvou Nkových spojů bondovaných dohromady je někde úplně jinde, než u EoIP.

[rado3105]

Nieco ako tunel preto, lebo nechcem aby sa to nemiesalo s trafficom ktory tam obojsmerne bezi a bezat bude.....

[reset]

koukam , ze paralelni vlakno jsi zalozil i na root.cz
http://forum.root.cz/index.php?topic=5924.msg55405;topicseen#new

[rado3105]

http://wiki.mikrotik.com/wiki/Manual:MPLSVPLS
toto vyzera zaujimavo, nema niekto nasadene? ako to zerie vykon routrov?

[Dalibor Toman]

ano eoip v podobe mikrotiku nefunguje.....spajal som tak dva n-kove spoje a vysledok bol este slabsia priepustnost ako jeden n-kovy....ale spat k teme:

kecy v kleci:

[MT1]-ethernet-[MT2_station]-mimo2x2_s_EoIP-[MT3_apbridge]-ethernet-[MT4]

TCP BW test s 20 spojenima mezi MT1 a MT4 prave ted 69mbps. MT3 pri tom ma jeste jedno ho klienta a linkou tekla nejaka data. Zatez CPU na MT2 cca 60%. Vsechny MT jsou RB433AH.
Ano, diky manipulaci s obsahem packetu je EoIP narocnejsi na CPU a bez nej (v PtP scenarich lze obejit pomoci station bridge za cenu jinych mene podstatnych nesnazi) je propustnost vyssi, ale je nesmysl tvrdit, ze EoIP je nefunguje ci je nepouzitelne pro jine nez zanedbatelne rychlosti.

Kdysi jsem testoval Mikrotikem vychvalovane VPLS tunely. Vyslo mi, ze jsou mozna o nekolik malo procent rychlejsi (mene narocnejsi na CPU). Ale jednak pro vykonocy rozdil nevidim duvod (pokud EoIP nepsal nejaky packal) a jednak konfigurace VPLS je nepomerne komplikovanejsi a mene pruhledna cili ji nepouzivame. BTW: mam pocit, ze v nejakem lonskem changelogu byla zminka o optimalizaci EoIP ...

[asdewq]

Dalibor: rad by som s tebou suhlasil, ale mam jedneho konkretneho zakaznika ktory z istych dovodov ma tiez dotiahnuty EoIP. Ked sa mu pustia data cez EoIP dostane cez linku cca 7mbit, ked sa mu pustia data mimo EoIP ide to plnou rychlostou linky (15mbit) co je priepastny rozdiel...Ano tiez som kedysi pouzival EoIP na bondovanie wlan liniek a slo to paradne lenze to bolo 802.11a+nstreme tu je to 11n + nv2 a katastrofa na svete

[hapi]

to je celkem pochopitelný. Zmenšení mtu potažmo roseknutí paketu na dva, větší pps, větší zátěž cpu, větší latence doručení, menší propustnost. Jakejkoliv tunel je bordel pokud nemáte trasu co zvládne větší mtu aby se do tunelu vešlo celí mtu 1500.

[Dalibor Toman]

Dalibor: rad by som s tebou suhlasil, ale mam jedneho konkretneho zakaznika ktory z istych dovodov ma tiez dotiahnuty EoIP. Ked sa mu pustia data cez EoIP dostane cez linku cca 7mbit, ked sa mu pustia data mimo EoIP ide to plnou rychlostou linky (15mbit) co je priepastny rozdiel...Ano tiez som kedysi pouzival EoIP na bondovanie wlan liniek a slo to paradne lenze to bolo 802.11a+nstreme tu je to 11n + nv2 a katastrofa na svete

mnou zminovana linka je taky NV2 (protoze nstreme v MIMO u nas nefunguje). Takovehle propastne rozdily by snad mohly vzniknout pokud jsou desky moc pomale (ale to by snad musely byt stare RB133) a nebo je CPU hodne zatizene necim jinym. Neslo to EoIP co zminujes nahou jeste pres ethernet (= mozny problem s MTU a fragmentaci) ?

BTW zajimavy je pohled do tools/profile - pri mnou zminovanem testu je na MT2 zatez CPU u EoIP max 6% pri testu kdy data tecou na MT2 (MT2 EoIP 'rozbaluje'). Zdaleka nejvice si vezme wireless a queuing (kazdy 20-30) a firewall (cca 15%). V testu opacneho smeru (kdy MT2 'zabaluje' do EoIP) si EoIP vezme cca 15%-20%, wireless kolem 20%, quing kolem 10%

Jo a desky nejsou RB433AH ale RB411AH ale to je z pohledu toho testu doufam nezajimave (CPU je stejny)

[Majklik]

Tak nějak. je jedno, zda VPLS nebo EoIP, základem je linka, co přenese L2MTU takové, aby ta vnitřní tunelovaná se nemesela fragmentovat.
V tomto případě je VPLS blbost. To by se hodilo, pokud těch tuenelů budou desítky, síť budou smyčky s vícero cestami a využuje TE pro vyvažování všech cest, a podobné blbosti. Pro takovýto případ s jedním tunelem by to bylo jen akademické cvičení...
Stále mi není jasné, proč tvrvá na L2 tunelu, nestačí IPIP nebo GRE L3 tunel? Pokud to má zapojeno jak kresleno, tak sina propojích mezi RBčky nastaví L2MTU 1520 (což snad umí vechna RBčka) a udělá mezi MK1a MK5 IPIP tunel a vnitřním MTU 1500 a pojede mu to.
Nicmén bych se bvyflákl i na tne tunel. Proč ho cheš? To chce všechen provoz posílat na M1 a zd rozhodnout kretou linkou to posílat ven? Pak ten tunel má smysl. Spíše bych zvážil, že nechám každou bránu samostatně, pustím mezi tmi RBčky OSPF nastavené tak, aby třeba LAN1 až LAN3 odcházelo přes MK1 a LAN4 pře zálohu (v závislosti jaký mám poměr mezi primární a záložní linky a jde vzniká kolik provozu) a je to. S tunelem jen budu posílat nějaký provoz sítí 2x.