De ce L2VPN-ul tău ignoră RSVP-TE LSP-ul pe care tocmai l-ai construit

Doi ingineri pot părăsi aceeași fereastră de mentenanță convinși că noua cale este în uz, și amândoi să greșească din motive diferite. Unul a construit LSP-ul și a presupus că serviciul îl va urma. Celălalt a lăsat serviciul în pace și a presupus că nimic nu s-a schimbat. Un pseudowire folosește mereu doar transportul către care se rezolvă adresa peer-ului său în acel moment, deci întrebarea reală este ce produce acea rezoluție acum, iar cele două proiecte răspund diferit.

O etichetă numește un serviciu, cealaltă mută un pachet

Eticheta pseudowire, semnalizată de LDP țintit precum este descris în RFC 4447, spune marginii furnizorului care primește ce circuit de atașare trebuie să primească cadrul. Nu spune nimic despre cum a ajuns cadrul acolo. Eticheta de dedesubt aparține transportului, iar stiva aceea este construită de ceea ce a anunțat accesibilitate pentru loopback-ul peer-ului, fie LDP, RSVP-TE sau o cale rutată pe segmente. Deoarece protocoale diferite semnalizează cele două straturi, unul poate fi sănătos în timp ce celălalt este învechit. Această separare este toată sursa confuziei.

Merită spus direct: pseudowire nu alege LSP-ul. El predă un cadru transportului, iar transportul decide după adresa de destinație care i-a fost dată.

De aceea și un ping curat prin noul LSP dovedește atât de puțin. LSP-ul poate fi activ, etichetat și purtând alte servicii în timp ce pseudowire-ul tău încă se rezolvă prin alt salt următor. Până nu citești legătura, cele două fapte nu au legătură.

Opțiunea A: fixează pseudowire-ul pe un transport ales

Fixarea înseamnă a face rezoluția de transport a serviciului deterministă. În funcție de platformă, aceasta ia forma unei politici de selecție a tunelului, a unui punct final de transport explicit pe serviciu, sau a unei politici de rutare care rescrie saltul următor pentru adresa peer-ului. Toate trei fac același lucru dedesubt: forțează rezoluția unei destinații pe un LSP anume. Asta face rezultatul auditabil ulterior.

Costul este amploarea. O politică ce se potrivește pe o adresă de peer afectează fiecare serviciu îndreptat spre acel peer, nu doar pseudowire-ul la care te-ai gândit.

Calea de rezervă merită o decizie înainte de fereastra de schimbare, nu în timpul ei. Dacă LSP-ul fixat cade, fie lași serviciul să meargă pe altă cale aprobată, fie îl lași să se oprească. O politică ce revine în tăcere pe o cale ce încalcă o cerință de latență sau de disjuncție a transformat o întrerupere curată în ceva mult mai greu de explicat oricui.

Opțiunea B: lasă IGP-ul să aleagă și urmărește ce se întâmplă

A lăsa serviciul în pace este un proiect legitim și adesea cel mai bun. Pseudowire-ul urmează aceeași rezoluție ca orice alt trafic către loopback-ul peer-ului, deci moștenește convergența IGP, suprimarea prefixelor și redundanța pe care nucleul o oferă deja. Mai puține politici înseamnă mai puține locuri unde o potrivire învechită se poate ascunde. Schimbul este că nu mai controlezi ce cale ia serviciul, doar că există o cale.

Multipath-ul cu cost egal accentuează acest schimb mai mult decât pare la prima vedere. Hashing-ul este pe flux, deci două conversații într-un pseudowire pot pleca pe etichete exterioare diferite.

Citește forwarding-ul instalat înainte de a te încrede în oricare

Începe cu adresa peer-ului, nu cu serviciul. Pe Junos, show route 203.0.113.1 detail afișează saltul următor selectat și operația de etichetă, iar show route table mpls.0 mapează eticheta de intrare la acea operație. Pe IOS XR, show mpls l2transport vc 100 detail dă starea pseudowire împreună cu stiva impusă.

Confirmă LSP-ul pe care transportul îl folosește efectiv, nu pe cel pe care îl numește documentul tău de proiectare. traceroute mpls ipv4 203.0.113.1/32 pe IOS XR parcurge calea comutată prin etichete și listează etichetele și interfețele de ieșire de-a lungul ei, ceea ce este cel mai aproape de a urmări calea tu însuți. Apoi repetă exercițiul de la marginea furnizorului îndepărtat, pentru că direcția de retur se rezolvă independent și asimetria este obișnuită după o implementare parțială a politicilor. O cale corectă într-o direcție și greșită în cealaltă este mai rea decât una uniform greșită, pentru că jumătate din testele tale vor trece.

Păstrează dovezile împreună cu înregistrarea serviciului: adresa peer-ului, saltul următor, eticheta exterioară și data la care ai verificat. Politicile de rutare îmbătrânesc prost, și nimeni nu își amintește care era în vigoare acum două trimestre.

Alege după modul de defectare, nu după preferință

Fixarea se potrivește serviciilor cu o cerință pe care IGP-ul nu o poate exprima, și echipelor care pot întreține politica la fiecare schimbare. A lăsa asta în seama IGP-ului se potrivește serviciilor care trebuie să supraviețuiască oricărei defecțiuni unice fără un om în buclă.

Întrebarea decisivă este cât te costă o cale greșită. Dacă un serviciu pe LSP-ul greșit performează doar puțin mai slab, lasă IGP-ul să decidă și cheltuie efortul pe monitorizare. Dacă o cale greșită rupe un contract, o constatare de audit sau o cerință de disjuncție, fixeaz-o și scrie calea de rezervă. Apoi testează rezerva, pentru că o rezervă netestată este o presupunere, nu un plan. În orice caz, recitește legătura instalată după orice schimbare în nucleu, și tratează un pseudowire care a urcat ca dovadă a nimic altceva decât că semnalizarea funcționează.