Två PE, ett prefix: varför RD avgör synligheten
Två kantroutrar som annonserar samma prefix delar en destination om inte deras route distinguisher skiljer sig. Tilldela medvetet och kontrollera sedan VRF:en.
Två kantroutrar som annonserar samma kundprefix beskriver en enda VPNv4-destination tills något skiljer dem, och avgränsaren är route distinguisher. Den kvalificerar prefixet; den avgör inte vem som importerar resultatet, det är route targetens uppgift. Tilldela RD:n från mängden av rutter som måste förbli urskiljbara i varje domän där dessa annonser kan mötas, inte från filupplägget på en enda burk. Numret du väljer är en identitet som senare granskningar kommer att bero på, så det hör hemma i ett inventarium innan det hamnar i en konfiguration.
En RD plus ett prefix är en destination
En RD plus ett IPv4-prefix bildar den VPNv4-destination som kontrollplanet jämför. Ge två PE samma prefix för olika kunder och utan olika RD annonserar de rutter till en destination. Ingenting på en skärm säger att grupperingen är fel, eftersom plattformen gör exakt det identiteten säger. Byt RD på en av dem och den gamla annonsen dras tillbaka medan en ny dyker upp under en annan identitet. Allt nedströms som var knutet till den gamla identiteten, från ruttval till ett sparat operatörsfilter, refererar nu till något som inte längre finns.
Flera rutter per destination är normalt BGP-beteende, inte ett symptom. En speaker kan hålla flera mottagna rutter medan den väljer en bästa rutt för vidarebefordran, och gapet mellan mottagen och vald är där synlighetsfrågorna bor. När en rutt verkar ha försvunnit, bekräfta om identiteten den hörde till fortfarande finns innan du tittar på sessionen.
Samma RD, samma destination, olika rutter
Skicka en RD och ett prefix från två routrar för samma tjänsts räkning och båda erbjuder rutter till en destination, oftast med olika nästa hopp. Vilken av dem en route reflector skickar vidare är ett beslut om reflektorn: dess ruttval, dess annonseringsförmåga och alla policyer som lagts ovanpå. Ingen av kantroutrarna styr det valet. Ge de två annonserna olika RD och var och en blir sin egen destination, så båda kan överleva ett kontrollplan som annars bara bär den valda rutten för en identitet.
Synlighet och multipath möts i den mottagande VRF:en, men de är inte samma beslut, och en reflektor som bär två identiteter har inte konfigurerat en andra installerad rutt. VRF:en installerar det dess importpolicy tillåter och det dess egen inställning för maximalt antal rutter tillåter. Kontrollera den inställningen separat när du vill att den andra rutten ska användas och inte bara synas.
En lokal unikhetsregel är ingen policy
Att ge varje PE och varje routinginstans sin egen RD är en sund konvention: den namnger ursprunget, hindrar orelaterade tjänster från att kollidera på en identitet och ger inventariet en stabil nyckel. Vissa plattformar kräver bara unikhet inne i burken och tillåter uttryckligen att routrar delar en RD för samma VPN-instans. Det tillståndet är en implementeringsbegränsning, inte en regel mellan nätverk som du kan delegera till en leverantör. Om domänen spänner över team, skriv tilldelningspolicyn själv.
Medlemskap kommer aldrig från siffrorna. Ett mönster som 65000:12 för en PE och 65000:13 för en annan är en vana, medan matchande export- och importmål som 65000:112 är det som sätter en rutt i en VRF. Behandla RD:n som identiteten för en rutt och route targeten som tillståndet som bär den in i en VRF.
Bevisa ändringen på VRF:en, inte på skärmen
Innan du rör en RD, skriv ned fyra saker: vad PE:n annonserar i dag, vad reflektorn reflekterar, vad den mottagande VRF:en importerar och vilken rutt den väljer. En ny RD drar tillbaka en annons och inför en annan, så ändringen syns på båda sidor av sessionen och är lätt att läsa fel om du bara följer den annonserande sidan. Acceptans bör vila på den nåbarhet du ville ha, inte på en extra rad som dyker upp i en prefixlista. Tabellen nedan håller de tre identifierarna från att flyta ihop under den granskningen.
| 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 |
Börja på den annonserande PE:n och jämför båda identiteterna för samma prefix innan du tar bort något. IOS-kommandona nedan svarar på tre frågor i ordning: finns den gamla annonsen kvar, är den nya identiteten synlig för reflektorn och väljer VRF:en prefixet.
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
Andra plattformar skriver ut samma information med en annan syntax, och frågorna överlever den ändringen. Om den nya identiteten saknas hos reflektorn medan PE:n listar den som annonserad, är reflektorpolicy eller annonseringsförmåga den första misstänkta, inte numreringen.
Anteckna PE, instans, RD, export- och importmål och prefixägande på ett ställe, eftersom nästa tilldelning är en uppslagning och inte en gissning just när den posten finns. Behåll den gamla RD:n tills den nya identiteten syns i den mottagande VRF:en och dra sedan tillbaka den i ett andra steg så att varje fas förblir reversibel.