To PE-er, ett prefiks: hvorfor RD-en avgjør synligheten
To kantrutere som annonserer samme prefiks deler én destinasjon med mindre route distinguisher-ene deres er forskjellige. Tildel bevisst, og kontroller deretter VRF-en.
To kantrutere som annonserer samme kundeprefiks beskriver én VPNv4-destinasjon til noe skiller dem, og skilleren er route distinguisher. Den kvalifiserer prefikset; den avgjør ikke hvem som importerer resultatet, det er route target-ens jobb. Tildel RD-er fra settet med ruter som må forbli atskilbare i hvert domene der disse annonsene kan møtes, ikke fra filoppsettet på én boks. Nummeret du velger, er en identitet som senere gjennomganger vil avhenge av, så det hører hjemme i et inventar før det går inn i en konfigurasjon.
En RD pluss et prefiks er én destinasjon
En RD pluss et IPv4-prefiks danner VPNv4-destinasjonen som kontrollplanet sammenligner. Gi to PE-er samme prefiks for forskjellige kunder, og uten forskjellige RD-er annonserer de ruter til én destinasjon. Ingenting på en skjerm forteller deg at grupperingen er feil, fordi plattformen gjør nøyaktig det identiteten sier. Endre RD-en på en av dem, og den gamle annonsen trekkes tilbake mens en ny dukker opp under en annen identitet. Alt nedstrøms som var nøklet til den gamle identiteten, fra rutevalg til et lagret operatørfilter, viser nå til noe som ikke lenger finnes.
Flere ruter per destinasjon er vanlig BGP-oppførsel, ikke et symptom. En speaker kan holde flere mottatte ruter mens den velger én beste rute for videresending, og gapet mellom mottatt og valgt er der synlighetsspørsmålene bor. Når en rute ser ut til å ha forsvunnet, bekreft om identiteten den hørte til fortsatt finnes før du ser på sesjonen.
Samme RD, samme destinasjon, ulike ruter
Send én RD og ett prefiks fra to rutere på vegne av samme tjeneste, og begge tilbyr ruter til én destinasjon, vanligvis med forskjellige neste hopp. Hvilken av dem en route reflector sender videre, er en beslutning om reflectoren: rutevalget, annonseringskapasiteten og enhver policy lagt over den. Ingen av kantruterne kontrollerer det valget. Gi de to annonsene forskjellige RD-er, og hver blir sin egen destinasjon, slik at begge kan overleve et kontrollplan som ellers bare bærer den valgte ruten for én identitet.
Synlighet og multipath møtes i den mottakende VRF-en, men de er ikke samme beslutning, og en reflector som bærer to identiteter har ikke konfigurert en andre installert rute. VRF-en installerer det importpolitikken tillater og det dens egen maksimum-rute-innstilling tillater. Kontroller den innstillingen separat når du vil at den andre ruten skal brukes og ikke bare være synlig.
En lokal unikhetsregel er ikke en policy
Å gi hver PE og hver rutingsinstans sin egen RD er en sunn konvensjon: den navngir opprinnelsen, holder ubeslektede tjenester fra å kollidere på én identitet og gir inventaret en stabil nøkkel. Noen plattformer krever bare unikhet inne i boksen og tillater uttrykkelig at rutere deler en RD for samme VPN-instans. Den tillatelsen er en implementeringsbegrensning, ikke en regel på tvers av nettverk som du kan delegere til en leverandør. Hvis domenet spenner over team, skriv tildelingspolicyen selv.
Medlemskap kommer aldri fra sifrene. Et mønster som 65000:12 for én PE og 65000:13 for en annen er en vane, mens samsvarende eksport- og importmål som 65000:112 er det som setter en rute i en VRF. Behandle RD-en som identiteten til en rute og route target-en som tillatelsen som bærer den inn i en VRF.
Bevis endringen på VRF-en, ikke på skjermen
Før du rører en RD, skriv ned fire ting: hva PE-en annonserer i dag, hva reflectoren reflekterer, hva den mottakende VRF-en importerer og hvilken rute den velger. En ny RD trekker tilbake én annonse og innfører en annen, så endringen vises på begge sider av sesjonen og er lett å lese feil hvis du bare følger den annonserende siden. Aksept bør hvile på rekkevidden du ønsket, ikke på en ekstra linje som dukker opp i en prefiksliste. Tabellen nedenfor holder de tre identifikatorene fra å flyte sammen under den gjennomgangen.
| 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 annonserende PE-en og sammenlign begge identitetene for samme prefiks før du fjerner noe. IOS-kommandoene nedenfor svarer på tre spørsmål i rekkefølge: er den gamle annonsen der fortsatt, er den nye identiteten synlig for reflectoren, og velger VRF-en prefikset.
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 plattformer skriver ut den samme informasjonen med en annen syntaks, og spørsmålene overlever den endringen. Hvis den nye identiteten mangler hos reflectoren mens PE-en lister den som annonsert, er policyen eller annonseringskapasiteten til reflectoren den første mistenkte, ikke nummereringen.
Noter PE, instans, RD, eksport- og importmål og prefikseierskap på ett sted, fordi neste tildeling er et oppslag og ikke en gjetning nettopp når den posten finnes. Behold den gamle RD-en til den nye identiteten er synlig i den mottakende VRF-en, og trekk den så tilbake i et andre trinn slik at hvert stadium forblir reversibelt.