To PE-ar, eitt prefiks: kvifor RD-en avgjer synlegheita
To kantrutarar som annonserer same prefiks deler éin destinasjon med mindre route distinguisher-ane deira er ulike. Tildel medvite, og kontroller deretter VRF-en.
To kantrutarar som annonserer same kundeprefiks skildrar éin VPNv4-destinasjon til noko skil dei, og skiljaren er route distinguisher. Han kvalifiserer prefikset; han avgjer ikkje kven som importerer resultatet, det er jobben til route target. Tildel RD-ar frå settet med ruter som må halde fram med å vere skilbare i kvart domene der desse annonsane kan møtast, ikkje frå filoppsettet på éin boks. Nummeret du vel, er ein identitet som seinare gjennomgangar vil avhenge av, så det høyrer heime i eit inventar før det går inn i ein konfigurasjon.
Ein RD og eit prefiks er éin destinasjon
Ein RD pluss eit IPv4-prefiks dannar VPNv4-destinasjonen som kontrollplanet samanliknar. Gi to PE-ar same prefiks for ulike kundar, og utan ulike RD-ar annonserer dei ruter til éin destinasjon. Ingenting på ein skjerm fortel deg at grupperinga er feil, fordi plattforma gjer nøyaktig det identiteten seier. Endre RD-en på ein av dei, og den gamle annonsen blir trekt tilbake medan ein ny dukkar opp under ein annan identitet. Alt nedstraums som var nøkla til den gamle identiteten, frå ruteval til eit lagra operatørfilter, viser no til noko som ikkje finst lenger.
Fleire ruter per destinasjon er vanleg BGP-åtferd, ikkje eit symptom. Ein speaker kan halde fleire mottekne ruter medan han vel éi beste rute for vidaresending, og gapet mellom motteke og vald er der synlegheitsspørsmåla bur. Når ei rute ser ut til å ha forsvunne, stadfest om identiteten ho høyrde til framleis finst før du ser på sesjonen.
Same RD, same destinasjon, ulike ruter
Send éin RD og eitt prefiks frå to rutarar på vegner av same teneste, og begge tilbyr ruter til éin destinasjon, vanlegvis med ulike neste hopp. Kva for ei av dei ein route reflector sender vidare, er ei avgjerd om reflectoren: rutevalet, annonseringskapasiteten og kva som helst policy lagd over han. Ingen av kantrutarane kontrollerer det valet. Gi dei to annonsane ulike RD-ar, og kvar blir sin eigen destinasjon, slik at begge kan overleve eit kontrollplan som elles berre ber den valde ruta for éin identitet.
Synlegheit og multipath møtest i den mottakande VRF-en, men dei er ikkje same avgjerd, og ein reflector som ber to identitetar har ikkje konfigurert ei andre installert rute. VRF-en installerer det importpolitikken tillèt og det hans eigen maksimum-rute-innstilling tillèt. Kontroller den innstillinga separat når du vil at den andre ruta skal brukast og ikkje berre vere synleg.
Ein lokal unikskapsregel er ikkje ein policy
Å gi kvar PE og kvar rutingsinstans sin eigen RD er ein sunn konvensjon: han namngir opphavet, held uslekta tenester frå å kollidere på éin identitet og gir inventaret ein stabil nøkkel. Nokre plattformer krev berre unikskap inne i boksen og tillèt uttrykkeleg at rutarar deler ein RD for same VPN-instans. Den tillatinga er ei implementeringsavgrensing, ikkje ei regel på tvers av nettverk som du kan delegere til ein leverandør. Viss domenet spenner over team, skriv tildelingspolitikken sjølv.
Medlemskap kjem aldri frå sifra. Eit mønster som 65000:12 for éin PE og 65000:13 for ein annan er ein vane, medan samsvarande eksport- og importmål som 65000:112 er det som set ei rute i ein VRF. Behandle RD-en som identiteten til ei rute og route target-en som tillatinga som ber henne inn i ein VRF.
Prov endringa på VRF-en, ikkje på skjermen
Før du rører ein RD, skriv ned fire ting: kva PE-en annonserer i dag, kva reflectoren reflekterer, kva den mottakande VRF-en importerer og kva rute han vel. Ein ny RD trekkjer tilbake éin annonse og innfører ein annan, så endringa viser seg på begge sider av sesjonen og er lett å lese feil viss du berre følgjer den annonserande sida. Aksept bør kvile på rekkevidda du ønskte, ikkje på ei ekstra linje som dukkar opp i ei prefiksliste. Tabellen nedanfor held dei tre identifikatorane frå å flyte saman 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 annonserande PE-en og samanlikn begge identitetane for same prefiks før du fjernar noko. IOS-kommandøane nedanfor svarar på tre spørsmål i rekkjefølgje: er den gamle annonsen der framleis, er den nye identiteten synleg for reflectoren, og vel 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 skriv ut den same informasjonen med ein annan syntaks, og spørsmåla overlever den endringa. Viss den nye identiteten manglar hos reflectoren medan PE-en listar han som annonsert, er policyen eller annonseringskapasiteten til reflectoren den første mistenkte, ikkje nummereringa.
Noter PE, instans, RD, eksport- og importmål og prefikseigarskap på éin stad, fordi neste tildeling er eit oppslag og ikkje ei gissing nettopp når den posten finst. Hald på den gamle RD-en til den nye identiteten er synleg i den mottakande VRF-en, og trekk han så tilbake i eit andre trinn slik at kvart stadium blir reversibelt.