Tak jsem si tak zkoušel, co už umí RouterOS z věcí kolem MPLS a seskládal si takový pokus. Kdo chce, může mrknout, pár dní to poběží, než ten šrot upotřebím někde jinde...
Je to 13 ks RBček, většina ROS5.12, dostupné na adrese 212.80.82.17:7001 až port 7012, login: demo/mpls
Vydrátováno dle přiloženého obrázku. Kdo bude mít otázku, může septát, občas zkusím odpovědět.
Stručně:
Síť tvoří R1-R12, kde R1 a R2 jsou hraniční routery, mající každý jednu linku k uplinku R0, baví se pomocí BGP, kdy k R1/2 je propagován jen defualt gate a ven "veřejný" segment 172.21.1.0/24, síť uvnitř používá jako neveřejný 192.168.0.0/16. BGP nastavneno tak, že vše jde ven po trase R1-R0, při zdechnutí R1 přebírá R2 (active/backup konfigurace). Uvnitř sítě jede OSPF, kde backbone jde přes všechny linky mezi R1 až R12, okrajové konce jsou arei zvlášť. BGP na R0~R2 se stará jen o IPv4.
Specifický segment je 192.168.255.0/24 z kterého se dávají /32 IP routerům na loopback (bridge-routerid) a na tyto IPčka je pověšen router id pro OSPF, BGP, LDP a použito jako adresy pro VPLS tunely a TE kanály.
MPLS je aktivní na všech linkách v backbone mezi R1~R12. V podstatě zapnuté LDP na všech routerech a propojovacích linkách, konfigurováno s MPLS L2MTU 1520 bajtů (limit daný RB450G). Je povolena propagace TTL z IP záhlaví do MPLS záhlaví, takže traceroute vypisuje přes co to jde s jakýma MPLS značkama.
Toto stačí pro to, aby začlo fungovat to nejprimtivnější - MPLS pro transport IPv4 paketů, obvkyle zvané IP akcelerace, že switching je o něco rychlejší než routing (ale přijdu tím o možnost něco dělat uvnitř MPLS sítě s pakety na zákaldě obsahu, MPLS switche do toho nevidí). Má smysl samotné řešit, pokud by bylo opravdu hodně RBček zřetězeno, dá se tím nahnat něco na odezvách, pokud hnedka nechci nasazovat výkonější šrot (nebo chci zakrýt strukturu sítě, s vypnutou propagací TTL pak trceroute vidí jen první a poslední router v MPLS oblasti). ROS nezvládá MPLS transport pro IPv6, také neumí využít ECMP (ale i to řada dalších platforem vyžaduje specificky konfigurovat, aby se vytěžovaly všechny ECMP trasy).
Další level - VPLS tunel sestavovaný pomocí LDP protokolu (/interface vpls) . V podpstatě to, co dělá EoIP, tak VPLS udělá virtuální Ethernet kanál mezi dvěma body. Řekněme, že chci přes naší krásnou routovanou síť propašoat PPPoE, rozhodl jsem se, že klientům, co chtějí veřejné IPčko (aka 172.21.1.192/28) ho dopravím přes PPPoE. Tak jeden otrava je na R6 a druhý na R7 (je tam připíchlý klasik Ovis WL5460AP a Draytek 2900 krám jako koncové routery zákoše). PPPoE servery mám dva na R1 a R2 nastaveno tak, aby se klient chytil k tomu, co mu první odpoví (rozkládání zátěže a i záloha výpadku jednoho). Na R1,2,6,7 je bridge-pppoe, kde je buď přilepen PPPoE server (R1/2) nebo klient port (R6/7), bridge propojeny dvěma vpls tunely (vpls-pppoeX). Fakticky to tvoří smyčku, ať to nelítá dokola je řešeno horizontováním na bridge (nastaveno tak, ať data tečou jen ve směru klient-server a klienti se vzájemně neslyší - nechceme vtípky s podstrčeným PPPoE serverem). Ať je klient správně zaroutován zvnějšku se postará OSPF, že zapropaguje klientovu adresu z daného PPPoE serveru. Tohle VPLS je řízeno pomocí LDP protokolu. Viz na koncových bodech v /mpls ldp neighbor print mimo fyzických sousedů jdou vidět i koncové body tunelu s kterými se ustanoví LDP spojení, ať si dohodnou jakou MPLS značku přiřadí tunelu.
Hrajeme si na velkou síť - VPLS řizené pomocí BGP (dle RFC, na Cisco variantu kašleme, ale je to obdobné). OK, přišel otrava, že má dvě pobočky a k tomu ještě babu účetní a chce, ať mu uděláme L2 síť mezi těma třemi místy, tkaový klasický trojúhelník. Zrovna nám leží u routerů R3, R7 a R9. Šlo by dle předchozího, namlátime bridge, připojíme koncové ethernet porty ke klientovi a namlátíme mezi to ty 3 VPLS tunely. Zkusíme, ať to tunely dělá samo, dle specifikace kde co chci propojit, kde se konce tunelů hledají přes BGP.
Na podporu (hrajeme si na velkou síť) si nahodíme 2 BGP routery (pro zálohu) v režimu reflektoru (co přijde z jednoho připojeného routeru odešlu všem ostatním připojeným) na R4 a R5 a na tyto routery se musí obracet BGP routery puštěné na koncových místech tunelů z R3/7/9 (v tomto případě je reflektorování kanón na vrabce, míň práce by bylo propeerovat ty BGP přímo a ještě míň použít LDP variantu). Takže BGP puštěno, nastaveno, že se starají jen o VPLS (l2vpn).
Spáchá se oblíbený bridge (bridge-vip-X) na R3/7/9 a k tomu připojí koncový ethernet a dále v MPLS-VPLS-BGP VPLS (/interface vpls bgp-vpls) definuje koncový bod. Jako ID jedné skupiny tunelů mám zvoleno 379:0 a pak nastaveno pod čím se má tento bod propagovat (např na 7 je 379:7) a z jakých konců naimprtovat spojení (z 379:3 a 379:9) a na jaký bridge to má napojit (bridge-vip-X) a jak nastavit horizonty. Když se to přes BGP vykecá, tak si to automaticky založí a udržuje dané VPLS tunely a připojí na brodge. Pohoda.
Komplikujeme to o další level - řizení datových toků VPLS tunelu. Otrava měl něco zlatých nugetů a chce, ať mezi místy A a B (R7-R3) má pro sebe 500 Mbps a do C jen něco málo, baba stejně používá jen RDP. Jak je libo, nasazení traffic engeneeringu - zjednodušene definuje cestu, kudy mají data téct a případně i omezuje a počítá kolik ješt může protéci něčeho jiného a dle toho to i umí routovat.
Předpokladem pro toto je, že se jednotlivým linkám přiřadí jakou mají datovou kapacitu (/mpls traffic-eng interface ) a z ní se postupně ujídá dle toků.
Takže se na R3 a R7 vyrábi definice toku te-vipX (/interface traffic-eng). Tomuto toku nastavuji, že má rezervovat po cestě si 400 Mbps (zas tolik negetků nedal), ale řezat na 500 Mbps (bandwith limit 125%). Tok používá nějaké cesty, buď dynamicky zaroutované nebo natvrdo předpesáné, případně volně předepsané. Nepářeme se s tím chceme, aby to natvrdo šlo cestou R3-R4-R7 (příčka přes routery) jako primární cestou (tp-vip-Z-X-Y-primary) a jen když cesta nebude dostupná, má to vzít někudy jinudy, ale at to jde buď přes R5 nebo R4 (dle toho, co bude zdechlé - tp-vip-Z-X-Y-backup a -backup2). Cesty jsou definovány v /mpls traffic-eng tunnel-path a přiřazené k danému te-vip-A nebo -B. Definice toku je vždy jendosměrný, proto se musí definovat oběma směry, pokud se má uplatňovat v obou směrech (což se hodí, můžeme někdy poslat každý směr jinudy a využít tak linek nebo výkonu routerků).
Další bod je vyřízení místa C, tomu stačí málo, takže použijeme tok (te-vip-C), který bude určen pomocí cesty (tp-cspf) routované protokolem CSPF (v podstatě rozšířená varianta OSPF, která bere v potaz kolik kapacity je rezervováno po cestě) s tím, že babě se na dané cestě rezervuje 5 až 20 Mbps a řezání provádí na 150% rezervace (takže ji to dá max 30 Mpbs). Kolik ji to aktuálně rezervuje se počítá dle toho, kolik toho přenášela v poslední minutě, když nic, ta ji to padne na těch 5 Mbps, když povalí dlouhý přenos, nastoupá na těch 20 a řezaných 30, trasa se najde dle toho, kudy bude zrovna volno (drží to aktuálně pěkně po R7-R11-R9 jedna a R3-R6-R9 druhá).
Že daný VPLS tunel je řízen nějakým TE tokem je dáno tím, když z routeru je definován TE se stejnou cílovou adresou, kam míří VPLS tunel, tak automaticky se přiřadí k TEčku (vidět v /interface vpls monitor pod položkou transport, když je tam IPčko, jde to pířmo routingem, když ID TE rozhranní, jde to přes něj). Trošku blbě se proto vyrábí, pokud mezi dvěma místy má jít víc různých tunelů různě řízeno (v ROSu se to dost blbě konfiguruje, ale v principu jde).
Asi nejzajimavější, opět řízení datového toku, ale místo VPLS toku řídíme tok IP dat. Což se zařídí snadno, definujeme TE tunel a do toho interface něco naroutuji, co tam namířím, to je neseno tunelem k jeho konci. Klasické využití je, že máme mezi dvěma body víc cest a chceme vytěžovat všechny. Při klasickém routingu to jde tou s nejmenší vahou, pokud to nenastavím pro aktivní ECMP. Zde můžu dosáhnout, že to jde tou nejlepší, dokud se to tam vejde a až ne, tak zapojí i další.
Máme definován tok pro dopravu dat ke koncovým sektorům sektorB až sektorG, které jsou připojeny na na R9 a R10 vždy 3 a definiju tok od routeru R1 (a identicky z R2), klasika, potřebuji usměrnit sosání lidí. Je to nastavneo tak, že těch 6 te-sektorA až te-sektorG je definováno na R1 i R2 současně, přičemž na každém je aktivní jen polovina, pokud jedou oba routery. Když jedne zdechne, tak všechny TEčka převezme přežívší (zajištěno pomocí master/slave skriptu na VRRP rozhranních vrrp-teX na R1 a R2).
Tok pro sektor B až D je definován tak, že každému sektoru se má rezervovat 40 Mbps a řezat na 50 Mbps. Řekněmě, že na R10 jsou tři sektory, které to dokáží krmit k lidem. Za normálního stavu je to transportováno z R1. Když se podívám po cestě, tak se to chvilkama přepíná, ale dva toky jdou přímo R1-R4-R10 a jeden R1-R3-R6-R10, protože R10 má dva 100 Mbps uplinky a do jednoho se tím pádme 120 Mbps zarezervovat nedá (pokud by se cestu nepovedlo nalézt, tak nebude aktivní a pakety potečou normálně dle toho, co vymyslí OSPF nejkrastší cesotu). Toto je statická rezervace, jiná varianta je, že se má rezervovat dynamicky dle aktuální ptřeby, to je případ sektorE až G, který je normálně odbavován z R2.
Řekněme, že na R9 máme něco lepšího a každý sektor umí vyžrat až 100 Mbps. kdybych to udělal jak pro B-D, tak se toky nesestaví, protože tam nemám tolik kapacity, jeden stovkový ethernet a dvě rádiové linky pochybné kvality. Rezervace se proto odvíjí dynamicky od měření v poslední minutě (průměrování po 30 sec), kdy se dynamicky měni pro jeden sektor 10 až 70 Mbps a řezání je o 25% výše. Když je klid, tak vše jde cestou R2-R3-R6-R9 a každý si drží 10 Mbps. Když se to rozjede, tak dle toho se natahuje rezervace, když se zaplní linka R6-R9, tak jeden tok jde jí přímo, druhý se dostane po R2-R3-R8-R12-R9 a třetí R2-R5-R7-R11-R9 a každý bude vyžírat max toho, co daná linka dovolí. Když ten, kdo drží trasu R6-R9 přestane čučet na porno a rezervace se sníží, tak se ostatní vrátí na tu linku, pokud se tam vejdou, případně méně sosající kanál to může i vytlačit na jinou linku.
Jen podotýkám, že je TEčkem řešen jen downolad ke koncovým sektorům, uplink se nechává volně na nejkratší cestě dle OSPF (šlo by nastavit tkaé, ale obvkyle není třeba).
K dokonalosti taky ROSu ještě toho spousta chybí, např TE lze jen uvnitř jedné OSPF arei, nejde udělat kanál přes hranici arei (je na to specifikace, ROS neumí, takže jedině musím skládat kanály za sebou nebo vše jen jenda area), není podpora pro fast reroute - když cesta zanikne, že něco umřelo, tak najití nové cesty je často na desítky sekund, s fast reroute jsou to desítky milisekund. Krásné by blyo autotunelování, kdy se TEčka zakládají automaticky a dle měření automaticky rozkládají toky do všech tras a mnoho dalšího, ale co by člověk za těch pár šupů chtěl.
A toť zhuba vše, co ROS v dané oblasti umí.
