To PE'er, ét præfiks: hvorfor RD'en afgør synligheden
To kantroutere, der annoncerer det samme præfiks, deler én destination, medmindre deres route distinguishers er forskellige. Tildel bevidst, og kontroller derefter VRF'en.
To kantroutere, der annoncerer det samme kundepræfiks, beskriver én VPNv4-destination, indtil noget adskiller dem, og adskilleren er route distinguisheren. Den kvalificerer præfikset; den afgør ikke, hvem der importerer resultatet, det er route targetens job. Tildel RD'er ud fra det sæt af ruter, der skal forblive adskillelige i hvert domæne, hvor disse annonceringer kan mødes, ikke ud fra filopsætningen på én boks. Det nummer, du vælger, er en identitet, som senere gennemgange vil afhænge af, så det hører i en fortegnelse, før det havner i en konfiguration.
En RD plus et præfiks er én destination
En RD plus et IPv4-præfiks danner den VPNv4-destination, som kontrolplanet sammenligner. Giv to PE'er det samme præfiks for forskellige kunder, og uden forskellige RD'er annoncerer de ruter til én destination. Intet på en skærm fortæller dig, at den gruppering er forkert, fordi platformen gør præcis, hvad identiteten siger. Skift RD'en på en af dem, og den gamle annoncering trækkes tilbage, mens en ny dukker op under en anden identitet. Alt nedstrøms, der var nøglet på den gamle identitet, fra rutevalg til et gemt operatørfilter, henviser nu til noget, der ikke længere findes.
Flere ruter per destination er normal BGP-adfærd, ikke et symptom. En speaker kan holde flere modtagne ruter, mens den vælger én bedste rute til videresendelse, og kløften mellem modtaget og valgt er der, hvor synlighedsspørgsmålene bor. Når en rute ser ud til at være forsvundet, så bekræft, om den identitet, den hørte til, stadig findes, før du ser på sessionen.
Samme RD, samme destination, forskellige ruter
Send én RD og ét præfiks fra to routere på vegne af den samme tjeneste, og begge tilbyder ruter til én destination, normalt med forskellige next hops. Hvilken af dem en route reflector sender videre, er en beslutning om reflectoren: dens rutevalg, dens annonceringskapacitet og enhver politik, der er lagt ovenpå. Ingen af kantrouterne styrer det valg. Giv de to annonceringer forskellige RD'er, og hver bliver sin egen destination, så begge kan overleve et kontrolplan, der ellers kun bærer den valgte rute for én identitet.
Synlighed og multipath mødes i den modtagende VRF, men de er ikke den samme beslutning, og en reflector, der bærer to identiteter, har ikke konfigureret en anden installeret rute. VRF'en installerer hvad dens importpolitik tillader, og hvad dens egen maksimum-rute-indstilling tillader. Kontroller den indstilling separat, når du vil have den anden rute brugt og ikke blot synlig.
En lokal entydighedsregel er ikke en politik
At give hver PE og hver routinginstans sin egen RD er en sund konvention: den navngiver oprindelsen, holder ubeslægtede tjenester fra at kollidere på én identitet og giver fortegnelsen en stabil nøgle. Nogle platforme kræver kun unikhed inde i boksen og tillader udtrykkeligt, at routere deler en RD for den samme VPN-instans. Den tilladelse er en implementeringsbegrænsning, ikke en regel på tværs af netværk, du kan uddelegere til en leverandør. Hvis domænet spænder over teams, så skriv tildelingspolitikken selv.
Medlemskab kommer aldrig fra cifrene. Et mønster som 65000:12 for en PE og 65000:13 for en anden er en vane, mens matchende eksport- og importtargets som 65000:112 er det, der sætter en rute i en VRF. Behandl RD'en som identiteten på en rute og route targeten som den tilladelse, der bærer den ind i en VRF.
Bevis ændringen på VRF'en, ikke på skærmen
Før du rører en RD, så skriv fire ting ned: hvad PE'en annoncerer i dag, hvad reflectoren reflekterer, hvad den modtagende VRF importerer, og hvilken rute den vælger. En ny RD trækker én annoncering tilbage og indfører en anden, så ændringen vises på begge sider af sessionen og er let at læse forkert, hvis du kun ser på den annoncerende side. Accept bør hvile på den rækkevidde, du ønskede, ikke på en ekstra linje, der dukker op i en præfiksliste. Tabellen nedenfor holder de tre identifikatorer fra at flyde sammen under den gennemgang.
| 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 |
Start på den annoncerende PE og sammenlign begge identiteter for det samme præfiks, før du fjerner noget. IOS-kommandoerne nedenfor besvarer tre spørgsmål i rækkefølge: er den gamle annoncering der stadig, er den nye identitet synlig for reflectoren, og vælger VRF'en præfikset.
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
Andre platforme udskriver de samme oplysninger med en anden syntaks, og spørgsmålene overlever den ændring. Hvis den nye identitet mangler hos reflectoren, mens PE'en viser den som annonceret, er reflectorens politik eller annonceringskapacitet den første mistænkte, ikke nummereringen.
Notér PE, instans, RD, eksport- og importtargets og præfiksejerskab ét sted, fordi den næste tildeling er et opslag og ikke et gæt, netop når den post findes. Behold den gamle RD, indtil den nye identitet er synlig i den modtagende VRF, og træk den så tilbage i et andet trin, så hvert stadie forbliver reversibelt.