Techtoriale – partea 9/12 – Multicast VPN
Continuam seria de techtoriale cu un capitol despre Multicast VPN (click pe imagine pentru download .pdf).Read More →
2015-02-12
Techtoriale – partea 5/12 – MPLS
Continuam seria de techtoriale cu un capitol despre MPLS (click pe imagine pentru download .pdf).Read More →
2015-02-09
Techtoriale – partea 4/12 – LDP & TE
Continuam seria de techtoriale cu un capitol despre LDP si Traffic Engineering (click pe imagine pentru download .pdf).Read More →
2014-11-26
EoMPLS folosind MPLS TE
Cred ca orice ISP care are retea MPLS se foloseste de circuite virtuale L2 (EoMPLS – Ethernet over MPLS). In urmatoarele randuri nu voi detalia ce anume inseamna un tunel EoMPLS (poate intr-un articol viitor) dar as vrea sa va supun atentiei o alta problema un pic mai delicata. EoMPLS presupune cel putin 2 label-uri MPLS (label stack) si in aceste conditii aproape orice metoda de balansare a traficului pe mai multe link-uri, fie ca este vorba de port-channel fie ca discutam de ECMP, “sufera” cand vine vorba sa imparta pe mai multe link-uri traficul dintr-un singur tunel EoMPLS. Si pentru ca in acest momentRead More →
2010-04-06
Multicast & MPLS TE
Traficul multicast se forwardeaza tinandu-se cont de RPF pentru sursa fiecarui pachet. Asadar pachetul cu destinatie multicast este trimis mai departe doar daca a venit pe interfata pe care “se vede” sursa in tabela de rutare. Din acest motiv nu va fi trimis printr-un tunel MPLS TE (intotdeauna “one way”) ci printr-o interfata fizica (sau logica). Daca insa avem trafic multicast intr-o retea MPLS si tunele MPLS TE intre P-uri pe care avem activat “autoroute annnounce” (deci la folosim ca interfete logice in OSPF de exemplu), atunci vom avea o mare problema cauzata de RPF. Practic, traficul multicast va fi afectat in momentul in care “vedem” sursa in tabelaRead More →
2010-01-11
MPLS TE Protection sau FRR (fast reroute)
FRR (fast reroute) este dupa parerea mea cel mai uzitat “feature” de MPLS traffic-engineering. Cand vine vorba de a implementa MPLS TE, toti marii provideri de internet (tier 1 sau 2) se rezuma la FRR deoarece, in cele mai multe dintre cazuri, un “full-mesh” de tunele MPLS configurat cu “bandwith reservation” pentru optimizari de banda creaza mari probleme datorita complexitatii. Asadar, daca avem o retea MPLS si ne dorim convergenta foarte buna in cazul in care pica un nod sau un link, recomand implementarea FRR. Sunt intrebat destul de frecvent doua lucruri legate de FRR: 1. De ce nu ne putem baza doar pe convergentaRead More →
2009-03-18