Doi PE, un prefix: de ce RD decide vizibilitatea
Două rutere de margine care anunță același prefix împart o singură destinație dacă route distinguisher-urile lor nu diferă. Alocați deliberat, apoi verificați VRF-ul.
Două rutere de margine care anunță același prefix de client descriu o singură destinație VPNv4 până când ceva le separă, iar separatorul este route distinguisher. Acesta califică prefixul; nu decide cine importă rezultatul, aceasta este treaba route target. Alocați RD-uri din mulțimea rutelor care trebuie să rămână distincte în fiecare domeniu unde acele anunțuri se pot întâlni, nu din aranjamentul fișierelor unui singur echipament. Numărul pe care îl alegeți este o identitate de care vor depinde verificările ulterioare, așa că îi este locul într-un inventar înainte de a ajunge într-o configurație.
Un RD plus un prefix înseamnă o destinație
Un RD plus un prefix IPv4 formează destinația VPNv4 pe care o compară planul de control. Dați la două PE același prefix pentru clienți diferiți și, fără RD-uri diferite, ele anunță rute către o singură destinație. Nimic pe un ecran nu vă spune că gruparea este greșită, pentru că platforma face exact ce spune identitatea. Schimbați RD-ul la unul dintre ele și anunțul vechi este retras, în timp ce sub altă identitate apare unul nou. Tot ce se afla în aval și depindea de identitatea veche, de la selecția rutei până la un filtru de operator salvat, se referă acum la ceva ce nu mai există.
Mai multe rute per destinație este comportament normal BGP, nu un simptom. Un speaker poate ține mai multe rute primite în timp ce selectează una mai bună pentru transmitere, iar diferența dintre primită și selectată este locul unde trăiesc întrebările despre vizibilitate. Când o rută pare să fi dispărut, confirmați dacă identitatea căreia îi aparținea mai există înainte de a privi sesiunea.
Același RD, aceeași destinație, rute diferite
Trimiteți un RD și un prefix de la două rutere în numele aceluiași serviciu și ambele oferă rute către o singură destinație, de obicei cu următoarele salturi diferite. Care dintre ele este transmisă mai departe de un route reflector este o decizie despre reflector: selecția sa de rută, capacitatea de anunțare și orice politică suprapusă. Niciunul dintre ruterele de margine nu controlează acea alegere. Dați celor două anunțuri RD-uri distincte și fiecare devine propria destinație, astfel încât ambele pot supraviețui unui plan de control care altfel poartă doar ruta selectată pentru o identitate.
Vizibilitatea și multipath se întâlnesc în VRF-ul receptor, dar nu sunt aceeași decizie, iar un reflector care poartă două identități nu a configurat o a doua rută instalată. VRF-ul instalează ceea ce permite politica sa de import și ceea ce permite propria setare de maxim de rute. Verificați acea setare separat când vreți ca a doua rută să fie folosită, nu doar vizibilă.
O regulă locală de unicitate nu este o politică
A da fiecărui PE și fiecărei instanțe de rutare propriul RD este o convenție sănătoasă: numește originea, împiedică serviciile nelegate să se ciocnească pe o identitate și dă inventarului o cheie stabilă. Unele platforme cer unicitate doar în interiorul echipamentului și permit explicit ruterelor să partajeze un RD pentru aceeași instanță VPN. Acea permisiune este o constrângere de implementare, nu o regulă între rețele pe care să o delegați unui furnizor. Dacă domeniul cuprinde echipe, scrieți voi înșivă politica de alocare.
Apartenența nu vine niciodată din cifre. Un model ca 65000:12 pentru un PE și 65000:13 pentru altul este un obicei, în timp ce ținte de export și import potrivite ca 65000:112 sunt ceea ce pune o rută într-un VRF. Tratați RD-ul ca identitatea unei rute și route target-ul ca permisiunea care o duce într-un VRF.
Dovediți schimbarea pe VRF, nu pe ecran
Înainte de a atinge un RD, notați patru lucruri: ce anunță PE-ul astăzi, ce reflectă reflectorul, ce importă VRF-ul receptor și ce rută selectează. Un RD nou retrage un anunț și introduce altul, așa că schimbarea apare pe ambele părți ale sesiunii și este ușor de citit greșit dacă urmăriți doar partea care anunță. Acceptarea ar trebui să se bazeze pe accesibilitatea dorită, nu pe o linie suplimentară apărută într-o listă de prefixe. Tabelul de mai jos ține cele trei identificatoare să nu se contopească în timpul acelei verificări.
| Identifier | Question it answers | What breaks when it is confused with another |
|---|---|---|
| Route distinguisher | Which route identity is this? | Two services collapse into one destination, so one advertisement withdraws the other |
| Route target | Who is allowed to import it? | Routes arrive in a VRF that should not have them, or never arrive at all |
| VRF import policy | What does this instance accept and install? | The route is visible on the PE but never selected in the VRF |
Începeți pe PE-ul care anunță și comparați ambele identități pentru același prefix înainte de a elimina ceva. Comenzile IOS de mai jos răspund pe rând la trei întrebări: anunțul vechi mai este acolo, noua identitate este vizibilă pentru reflector și VRF-ul selectează prefixul.
show bgp vpnv4 unicast rd 65000:12 203.0.113.0/24 show bgp vpnv4 unicast rd 65000:13 203.0.113.0/24 show ip route vrf CUSTOMER-A 203.0.113.0/24
Alte platforme afișează aceleași informații cu altă sintaxă, iar întrebările supraviețuiesc acelei schimbări. Dacă noua identitate lipsește la reflector în timp ce PE-ul o listează ca anunțată, primul suspect este politica sau capacitatea de anunțare a reflectorului, nu numerotarea.
Înregistrați PE-ul, instanța, RD-ul, țintele de export și import și proprietatea prefixului într-un singur loc, pentru că următoarea alocare este o căutare, nu o presupunere doar atunci când acea înregistrare există. Păstrați RD-ul vechi până când noua identitate este vizibilă în VRF-ul receptor, apoi retrageți-l într-un al doilea pas, astfel încât fiecare etapă să rămână reversibilă.