MPLS sit & RouterOS

[Majklik]

Pokud by tě ta cfg zajímaqla přesněji. Tak RX=192.168.255.1, RY=192.168.255.2, R1=192.168.255.11, R3=192.168.255.13 (to jsou loopackové adresy).
ad1)
Ve směru RY->RX nastavuji politiku, že default routa se rozkládá současně na obě trasy (cfg na RY):
/mpls traffic-eng tunnel-path
add hops=192.168.255.11:loose name=tp-yx1 record-route=yes use-cspf=no
add hops=192.168.255.13:loose name=tp-yx2 record-route=yes use-cspf=no
/interface traffic-eng
add auto-bandwidth-avg-interval=1m auto-bandwidth-update-interval=1h10s bandwidth=\
95Mbps bandwidth-limit=100% disabled=no from-address=192.168.255.2 name=te-yx1 \
primary-path=tp-yx1 reoptimize-interval=30s to-address=192.168.255.1
add auto-bandwidth-avg-interval=1m auto-bandwidth-update-interval=1h10s bandwidth=\
95Mbps bandwidth-limit=100% disabled=no from-address=192.168.255.2 name=te-yx2 \
primary-path=tp-yx2 reoptimize-interval=30s to-address=192.168.255.1
/ip route add gateway=te-yx1,te-yx2

ad2)
Ve směru RX->RY chci, aby provoy pro klienty s IP 192.168.200.0/24 šel první linkou a když bude linka minutu ucpaná, tak se začne část přelévat i na druhou lajnu (cfg na RX):
/mpls traffic-eng tunnel-path
add holding-priority=1 name=tp-dyn use-cspf=yes record-route=yes reoptimize-interval=30s setup-priority=1
/interface traffic-eng
add auto-bandwidth-avg-interval=30s auto-bandwidth-range=5Mbps-95Mbps auto-bandwidth-reserve=20% \
auto-bandwidth-update-interval=1m bandwidth=10Mbps disabled=no from-address=192.168.255.1 name=\
te-xy1 primary-path=tp-dyn to-address=192.168.255.2
add auto-bandwidth-avg-interval=30s auto-bandwidth-range=5Mbps-95Mbps auto-bandwidth-reserve=20% \
auto-bandwidth-update-interval=1m bandwidth=10Mbps disabled=no from-address=192.168.255.1 name=\
te-xy2 primary-path=tp-dyn to-address=192.168.255.2
/ip route add dst-address=192.168.200.0/24 gateway=te-xy2,te-xy1

[CANOPA]

diky za obsahle napady a konfigurace. Zkusim to behem dneska nasadit a otestovat. Jinak o co mi slo..
1.trasa RX-R1-R2-RY
2.trasa RX-R3-R4-R5-RY

Rekneme z RX je GW do netu a za RY je hromada klientu ...IP pres pppoe /32, a dva vetsi klienty, ktery jsou zaroven isp takze z jejich jedne NAT-IP jde vetsi provoz.
at jsem konkretnejsi...a pro zjednoduseni situace.
mam RX a RY mezi nima 2spoje po 150Mbps .. v souctu 300Mbps. Potrebuju provoz z poza RX smerem na RX nejak rovnomerne rozlozit...
Varianty
1)Ospf mezi RX a RY pri snaze rozlozit zatez pres ospf koncim na tom, ze tam kam se preklopi ti dva vetsi klienti(maji jednu verejnou IP)tak ten spoj se pretizi a ten druhy je vytizeny jen lehce. Proto jsem ospf musel zavrhnout.
2)Etherchannel by pouzit sel, ale chci se nachystat i na tu variantu kdy budu mit v ceste vic routeru..takze taky zavrhnuto.
3)mpls a jeho TE ...vim ze na Ciscu to jde a kolegove to pres tunnely rozkladaji. ale na MK nevim jak na to. takze tak.
Staticky rozdelovat klienty a ty pak routovat do jednotlivych tunnelu..mi prijde nestastne. Chtel bych se spolehnout na automatiku..
Co myslite, pujde to na mikrotiku vymyslet?

[Majklik]

Když to vezmu odzadu. Cisco umí spoustu krásných věcí, které se ROSu ani nezdají v těch nejdivočejších snech, bohužel... Autotunling, ECMP/MPLS, ..........
Ano, něco nakonfigurovt jde zázraky očekávat nemožno.

Etherchanel byl myšlen tak, že se udělají 2 VPLS tunely, každý jde jinou trasou a přes RX a z RY se spojí dohromady. Takže v cestě je routerů kolik chceš, jen se udělá, že to vypadá jak transparetní L2 bod-bod spoj.
Toto ale neuděláš, pokud RX a RY je jedne router, musí být dva (nebo si pomůžu MetaROUTERem). Jde o to, že není problém udělat několik VPLS tunelů mezi RX a RY, stjeně tak můžu udělat několik TE tras mezi RX a RY (kdy jedna jde 1. a druhá 2. rádiovou trasou), ale v ROSu nejde VPLS tunel spárovat s danou TE cestou ručně. Páruje se to automaticky na základě IP adres cíle. Takže když z RX (192.168.255.1) udělám tunely a TE cesty k RY (192.168.255.2), tak nevím, jakou TE si jaký VPLS tunel zvolí, obvykle věechny jednu a jsem v pytli. Takže si musím pomoci metarouterem, druhou krabicí, která bude mít jinou IP (nebo EoIP tunelem, pokud mám mezi RX-RY jumbo rámce).

OSPF mezi RX/RY ti udělá rozklad zátěže podle počtu spojení - zhruba, ale neřeší, jak která spojení toho moc přenáší. Zde je utčitý prostor pro to CSPF a TE. Předpokládám, že PPPoE koncentrátor je až na RY? Taktéž pokud budeš dělat NAT na RX nebo RY, tsak to není vždy ÖK v kombinaci s MPLS.
Zkusil bych řešit tak, že pro ty dva pseudo ISP bych udlal samosatný statický TE tunel (měřený, klidně ořízlý dle toho, co má zaplaceno), a jeho IP poslal do něj, ISP1 první trasou, ISP2 druhou trasou (s nastavenou i backup trasou druhou linkou, kdyby to spoj chcípl), tím jsi rozhodil dva největší zatěžovatele. Dále si udělal aspoň va dynamické tunely měřené, do nich poslal ten zbytel IPček klientů s využitím ECMP (jak mám výše), nebo si ty tunely udělám 4 a do každého pošlu čtvrtinu IPček... Možností je víc, ale plnou a dokonalou automatiku neočekávej....

[CANOPA]

Diky za napady. Nakonec jsem to vsechno zkombinoval:-))a udelal jak si rekl ty. Ten hop rt-rt jsem jsem vyresil pres bonding a zbytek pres TE a staticke routy. Ted to uz funguje a plni funkci. Takze dekuju za napady..

[CANOPA]

je skoda ze MK zatim neumi ten "autotunneling" ...to by spoustu veci zjednodusilo. Budu doufat, ze treba dalsich verzich...

[Majklik]

ROS neumí spousty mnohem jendodušších věcí (proč třeba u netwatch není limit přepnout stav až po X vypadlých/přijatých odpovědí), natož vylomeniny v MPLS. A navíc, dokud to celé hrotí v CPU, tak tu bude pořád výkonostní limit, co proteče mezi porty.... Nu, mámo muziky, málo peněz..
Ale obdovuji, že někteří šílenci na tom jejich MPLS mají síť přes celé USA, nadšení se nedá upřít.

[lwq]

Zjistil sem co s obri jistotou rozesmeje cloveka z Cisco az se za bricho popada... Mikrotik... A pokud ne jen tohle jedno slovo, tak dilo dokona spojeni Mikrotik a MPLS overeno praxi

[pepulis]

Dobry den,

chtel bych pozadat o radu. Mam napr. tohle zapojeni MK1(GW)--------MK2----------MK3-----------MK4------------MK5----------MK6. Na vsech zarizenich je zaple a nastavene MPLS. Kdyz dam traceroute z MK6 na MK2, vsechny zbyvajici mikrotiky po ceste jsou "zamaskovany" a nesjou tedy v traceroute videt. Da se nejak udelat to, aby uvedene routery byly zamaskovany i v pripade, ze si dam traceroute na napr. seznam.cz? Dekuju za radu.

[Majklik]

Bude to asi proto, že nedistribuješ MPLS značku pro default routu, takže provoz mířící ven vůbec není do MPLS balen (to je výchozí chování). Který router ti plní funkci LER ze strany brány do Internetu? Předpokládám, že MK2. Takže na něm něco jako:
/mpls ldp distribute-for-default-route=yes

[pepulis]

Bude to asi proto, že nedistribuješ MPLS značku pro default routu, takže provoz mířící ven vůbec není do MPLS balen (to je výchozí chování). Který router ti plní funkci LER ze strany brány do Internetu? Předpokládám, že MK2. Takže na něm něco jako:
/mpls ldp distribute-for-default-route=yes

Priznam se, ale porpavde nevim co je tou funkci LER mysleno. MK1 je hlavni router, kde se shapuje atd. MK2 atd. jsou routerboardy, pres ktere jde konekt. dale do site. Na MK2 a dal je zaple ospf (i kvuli zaokruhovani). Pokud jsem to nastavil na MK2 a dal traceroute na MK6 na napr. seznam.cz porad vidim vypis vsech zarizeni, ktere jsou v ceste. Pokud jsem to nastavil na MK1 (gw), tak konektivita dalk do site prestala fungovat. Muzete me jeste nakopnout? Dekuju .

[Majklik]

LER-Label Edge Router, to je krabice, která z jedním iface dostává pakety ještě bez MPLS a tlačí je dál už označkované MPLS (proti tomu je LSR-label switching router, ten už dostáva označkované a jen to přehazuje dál značkované).

Takže dle toho máš už puštěné MPLS přímo i na bráně na MK1 (a tím pádem je LER)? Pak je zcela samozřejnmé, jak jsi na něm dal distribute-for-default-route=yes, že ti chcíplo spojení ven do Internetu. Protože se ti začne do MPLS balit komunikace mezi MK2 a MK1 pro odchozí směr ven. A na GW dojde ke kolizi - bohužel, pořadí zpracování MPLS, NATu a dalších je takový, že to zdechne.... Což se stalo. Nejde, aby router, který dělá NAT, tak zároveň plnil roli LER nebo LSR.
Pokud ti po zapnutí té volby zdechla komunikace mezi MK1 a zbytkem vnitřní sítě, tak asi nebyla splněna nutná podmínka uvedená o kus dál (naznačovalo by to i tvrzení, že máš OSPF až na MK2 a dál).

Když jsi dal distribute-for-default-route=yes jen na MK2, tak při traceroute ven by ti měl ze seznamu vypadnout MK2. Ta volba platí jen pro jeden router, takže MPLS by pro provoz k seznam.cz mělo naskočit jen na spoji MK3->MK2.

Tu volbu distribute-for-default-route=yes je třeba postupně zapnout na všem v té řadě (MK2, MK3, MK4, MK5, MK6). A pokud je MPLS doména větší, tak postupně na všech routerech.
POZOR: Před zapnutím je nutno splnit podmínku, že všechny routery v MPLS doméně musí vidět jednotnou a stejnou routovací tabulku!! Jakmile toto není splněno, velmi zajimavě a podivně to bude zdechat. Takže na všem, kde je aktivní MPLS, tak musí být aktivní i OSPF a všechny tyto routery musí být buď v jedné arei nebo víc areí, ale všechny arei musí být typu default (distribuce plné tabulky bez agregací na hranicích areí).
Pak ti to začně fungovat korektně v režimu IP akcelerátoru i pro provoz směrovaný ven (pokud chci MPLS jen kvůli VPLS nebo TE, tak je lepší distribute-for-default-route nechat vypnuté).
PS: Pro Cisco smíšky, stejné platí a je nutno nastavit/dodržet tna Ciscu také. Tam je ekvivalentní nadávka pro "/mpls ldp distribute-for-default-route=yes" schována v "mpls ip default-route".

[pepulis]

LER-Label Edge Router, to je krabice, která z jedním iface dostává pakety ještě bez MPLS a tlačí je dál už označkované MPLS (proti tomu je LSR-label switching router, ten už dostáva označkované a jen to přehazuje dál značkované).

Takže dle toho máš už puštěné MPLS přímo i na bráně na MK1 (a tím pádem je LER)? Pak je zcela samozřejnmé, jak jsi na něm dal distribute-for-default-route=yes, že ti chcíplo spojení ven do Internetu. Protože se ti začne do MPLS balit komunikace mezi MK2 a MK1 pro odchozí směr ven. A na GW dojde ke kolizi - bohužel, pořadí zpracování MPLS, NATu a dalších je takový, že to zdechne.... Což se stalo. Nejde, aby router, který dělá NAT, tak zároveň plnil roli LER nebo LSR.
Pokud ti po zapnutí té volby zdechla komunikace mezi MK1 a zbytkem vnitřní sítě, tak asi nebyla splněna nutná podmínka uvedená o kus dál (naznačovalo by to i tvrzení, že máš OSPF až na MK2 a dál).

Když jsi dal distribute-for-default-route=yes jen na MK2, tak při traceroute ven by ti měl ze seznamu vypadnout MK2. Ta volba platí jen pro jeden router, takže MPLS by pro provoz k seznam.cz mělo naskočit jen na spoji MK3->MK2.

Tu volbu distribute-for-default-route=yes je třeba postupně zapnout na všem v té řadě (MK2, MK3, MK4, MK5, MK6). A pokud je MPLS doména větší, tak postupně na všech routerech.
POZOR: Před zapnutím je nutno splnit podmínku, že všechny routery v MPLS doméně musí vidět jednotnou a stejnou routovací tabulku!! Jakmile toto není splněno, velmi zajimavě a podivně to bude zdechat. Takže na všem, kde je aktivní MPLS, tak musí být aktivní i OSPF a všechny tyto routery musí být buď v jedné arei nebo víc areí, ale všechny arei musí být typu default (distribuce plné tabulky bez agregací na hranicích areí).
Pak ti to začně fungovat korektně v režimu IP akcelerátoru i pro provoz směrovaný ven (pokud chci MPLS jen kvůli VPLS nebo TE, tak je lepší distribute-for-default-route nechat vypnuté).
PS: Pro Cisco smíšky, stejné platí a je nutno nastavit/dodržet tna Ciscu také. Tam je ekvivalentní nadávka pro "/mpls ldp distribute-for-default-route=yes" schována v "mpls ip default-route".

Super, dekuju za vysvetleni. Pochopil jsem a nastavil to a uz to chodi vsechno, jak ma. S tim, jak jste psal, ze to muze zdechat, tak to se mi stalo vcera, kdyz jsem se s tim hral .

Jeste se presto zeptam: Proc je lepsi distribute-for-default-route nechat vypnuté pro MPLS jen kvuli VPLS nebo TE, jak pisete? Na co to ma vliv?

[Majklik]

Pokud chci dělat jen VPLS nebo TE, tak dokonce nemusím ani šířit MPLS pro všechny lokální routy, ale jen pro vybrané IP, které budou po trase/koncové body těch tunelů (dosáhnu toho pomocí /mpls ldp accept-filter/advertise-filter).
Jen v případě aplikace IP akcelerátoru potřebuji distribuovat defualt routu do MPLS (a zde např má ROS mínus, že umí jen IPv4 over MPLS a ne i IPv6, konkurence má 10 let náskok).

Riziko po zapnutí šíření defualt routy plyne z toho, že MPLS funguje při směrování jinak než klasický routing. V podstatě o cílovém bodě, kde paket opustí MPLS doménu, tak o tom rozhodne už LER při prvním označkování a dál se paket už jen switchuje v celé MPLS, než dorazí na koec. Kdežto klasický routing dělá na každém skoku rozhodování o dalším směru.
Takže jak máš tu řadu routerů MK1 až MK6, tak řekněme, máš na MK3 odbočku, kde je obsluhován segment 3.3.3.0/24. Fakticky routery MK4/5/6 nepotřebuji vědět routu pro 3.3.3.0/24, stačí jim default routa mířící nahoru a postupně paket pro 3.3.3.1 doskáče na MK3 a ten ho otočí do žádaného směru odbočky. Pokud nad tím pustíš MPLS a zapomeneš nastavit, aby se pro segment 3.3.3.0/24 distribuoval label nebo aby se nepropagoval do rout na MK4/5/6 (např to bude stub area jen s default routou), tak dokud nezapneš MPLS pro default routu, tak se nic neděje. Protože MK6 nebude znát 3.3.3.0/24 nebo pro něj nebude mít MPLS značku, tak ho normánlě routne bez MPLS a korektně ti doskáče na MK3 a tam se otočí. Jakmile zapneš distribute-for-default-route=yes a MK6 bude chtít poslat paket na 3.3.3.1, tak pokud stále nemá pro danou destinaci MPLS značku, tak použije MPLS pro defualt routu, do ni to zabalí a odpálí... a pak prosviští paket až na MK1, protože po cestě se už nezkoumá co je uvnitř, cíl byl vybrán na LER dle jeho nejlepších znalostí. Teprve tam s trocohu štestí se vybalí, zjistí se, že má jít zpět a pošle už lépe (protože MK1 musí vědět sopeciufickou troutu pro 3.3.3.0/24, pokud daná síť má být dostupná). Takže toto způsobí, při neúplné routovací tabulce všude, ž ti něco bude pěkně obíhat mnohem dále, než chceš (v lepším případě, v horším se to tiše někde ztratí). Toto platí třeba i pro situaci vypršení TTL. V MPLS záhlaví máš TTL, po vypršení se posílá oznámení, že chcíplo. Pokud budeš mít třeba zaplé propagaci TTL z IP záhlaví do MPLS záhlaví a dáš traceroute seznam.cz, tak paket na MK6 se strčí do MPLS značky pro defualt routu a pošle k MK5, když cestou chcípne TTL, tak se chybová zpráva neposílá zpět, ale nesena tou MPLS zančkou dorazí až na MK1, kde se korektně obrátí zpět do další MPLS značky na MK6.
Proto je distribuce default routy v základu vypnuta, ať ti to neudělá ze sítě holubník automaticky. Máš si ji zapnout sám, až dáš vše patřičně do pořádku ručně.