Ad 1)
Jak moc znamená rovnoměrně? Tohle mnohem jednodušeji uděláš s OSPF, kde nastavíš obě cesty tak, aby v součtu měly stejnu cost a uplatní se ECMP a budou se na střídačku jednotlivé spojení rozhazovat na obě linky. Pokud nad tím už máš ale MPLS akceleraci, tak ROS implementace nepodporuje ECMP (řve se kvůli tomu na Mikroťáky už dlouho).
Nejde jednoduše udělat to, aby jeden VPLS tunel získal šířku 200 Mbps, že půjde naráz oběma trasama. Leda uděláš, že jedne směr jde 1. a zpět to jde trasou 2.
Pokud chceš to pro VPLS, tak řešení je, že se udělají 2 VPLS tunely, předepíše se každému trasa jednou linkou a na koncích se tyto tunely spojí dohromady pomocí bondu, kde budeš řídit politiku rozkládání (např LACP s MAC xorem, pokud je to L2 tunel pro Ethernet).
Pokud to chceš řešit pro routing, že za RY je třeba hromada klientů na A.B.C.0/24 a pro ně to chceš rozhazovat, tak principiálně tak:
a) definuješ dvě cesty, každá půjde jinou trasou:
/mpls traffic-eng tunnel-path add name=tp1 hops=R1
/mpls traffic-eng tunnel-path add name=tp2 hops=R3
To loose je podstatné, cesta je neúplná, ale dostatečná, aby bylo jané, koma to má jít. Při použití strict politoky by s emusela ta cesta vyjmenovat celá.
b) Definuješ dva toky, kde každý tok pošleš jednou cestou:
/interface traffic-eng add name=te1 to-address=RY primary-path=tp1 secondary-paths=tp2
/interface traffic-eng add name=te2 to-address=RY primary-path=tp2 secondary-paths=tp1
jeden tok jde první trasou a druhý truhou, když linka chcípne, oba toky se přestěhují na přežívší trasu.
A nyní na RX normálně do toho zaroutuješ ten traffic s použitím ECMP:
/ip route add dst-address=A.B.C.0/24 gateway=te1,te2
Bude to dělat rozhazování per spojení na ty dvě trasy stejně, jak dělá klasické OSPF, když je využto ECMP.
Ad 2)
Obvykle se zákazníci za RY rozdlělit minimálně na dvě skupiny., třeba na A.B.C.0/25 a A.B.C.128/25. Čím víc skupin a tunelů, tím lépe se to rozdělí, ale je to na hlavu pak (Už by se ROS měl naučit autotunneling). Ale jd epoužít i ten ECMP routing jak v předchozím bodě.
Definuje se jenda dynamická cesta (CSPF=OSPF doplněné o braní v potaz rezervace linky):
/mpls traffic-eng tunnel-path add name=tp0 use-cspf=yes
A opět definuješ dva tunely, které používají dynamické cesty:
/interface traffic-eng add name=te1 to-address=RY primary-path=tp0 bandwidth=10000000 auto-bandwidth-range=5000000-95000000 auto-bandwidth-avg-interval=10s auto-bandwidth-update-interval=1m auto-bandwith-reserve=20 reoptimize-interval=1m
/interface traffic-eng add name=te2 to-address=RY primary-path=tp0 bandwidth=10000000 auto-bandwidth-range=5000000-95000000 auto-bandwidth-avg-interval=10s auto-bandwidth-update-interval=1m auto-bandwith-reserve=20 reoptimize-interval=1m
A routing n RX:
/ip route add dst-address=A.B.C.0/25 gateway=te1
/ip route add dst-address=A.B.C.128/25 gateway=tte2
Mělo by to fungovat tak, že při startu se rezervuje pro každý tunel 10 Mbps (bandwidth=), ale neomezuje, jde zapnout (bandwidth-limit=), pak se měří, kolik tím teče dat (průměry za 10 sec) a každou minutu přepočítává kolik potřebuje. S tím, že se rezervuje o 20% víc, než se naměřilo (auto-bandwith-reserve=20). Rezervace se může pohybovat v limitu 5 až 95 Mbps (auto-bandwidth-range=). Normálně by oba toky měly jít nejkratší trasou dle OSPF, taže asi RX-R1-R2-RY. V okamžiku, kdy požadavek na rezervaci těch dvou toků překročí co ta trasa snese, tak dojde k přesunu jednoho toku na jinou trasu (pokud je k dispozoci). Když se naopak první trasa uvolní, sestěhuje se to zpět (reoptimize-interval). Pomocí priorit se dá řídit, který tunel je výsadnější a další blbosti.
Připomínám, že TE tunel je jendosměrný, pokud chci řídit tok i opačným směrem RY->RX, je třeba to patřičně opbráceně zopakovat.
