Från en RIP-rutt på CE till en avlägsen VRF: var exporten sker

En RIPv2-uppdatering anländer till provider edge, hamnar i en VRF-routingtabell och stannar där om inget uttryckligen exporterar den. Tre beslut sker i följd och varje beslut kan avvisa prefixet av sitt eget skäl. Att läsa dem som en enda händelse är varför man letar i fel burk när en avlägsen plats inte når ett nätverk som CE uppenbart annonserar. Följ rutten genom PE och sekvensen blir självklar.

Vad PE gör med en RIP-uppdatering

PE tar emot uppdateringen på VRF-gränssnittet, kontrollerar att källan är en tillåten granne och installerar prefixet i VRF-routingtabellen med ett hoppantal som härleds från annonsen. Den tabellen är en vanlig routingtabell med egna administrativa avstånd och eget val av bästa väg. Om CE annonserar samma prefix två gånger med olika metrik överlever bara den bättre i tabellen. Inget i detta steg involverar leverantörens backbone.

Prefixet finns nu inom en kunds routingkontext, vilket är långt från att vara nåbart någon annanstans.

Export är en policyhandling, inte en protokollkonsekvens

För att lämna VRF:en måste en rutt redistribueras in i den MP-BGP-process som bär VPN-rutter, och den behöver en route target extended community som identifierar vilka avlägsna VRF:er som får importera den. Arkitekturen i RFC 4364 håller dessa utbyten åtskilda från CE-till-PE-protokollet just av detta skäl. Att använda RIP vid kanten säger ingenting om vad som ska korsa leverantörens nät.

Skriv ner exportkontraktet innan du konfigurerar något: de kundprefix som måste vara nåbara på distans, de rutter som måste stanna lokalt och eventuella default-rutter, mer specifika rutter eller undantag för delade tjänster. Jämför det kontraktet med den faktiska VRF:en, inte med en liknande namngiven som tillhör en annan kund.

Importsidan är en andra policy med egna route targets, och en matchande export med en icke-matchande import ger ett prefix som finns i backbonen och inte visas i någon avlägsen tabell.

Redistribuering och explicit origination beter sig olika

Redistribuering tar rutter som redan finns i VRF-tabellen och kopierar dem till BGP, filtrerade av en route map. Mapen avgör vilka prefix som är kvalificerade och vilka attribut de bär, och metriken måste sättas uttryckligen eftersom ett RIP-hoppantal inte har någon betydelse som BGP-metrik. Allt du lämnar oinställt ärvs på ett sätt som vanligtvis överraskar den som läser konfigurationen ett halvår senare.

Ömsesidig redistribuering är där den tysta skadan sker. Ett prefix som exporteras till BGP kan komma tillbaka genom en andra redistribueringspunkt, och utan taggar eller filter oscillerar rutten medan båda tabellerna ser rimliga ut i varje ögonblick. Filtrera på taggar som sätts vid kanten i stället för att lita på att topologin hindrar returvägen.

Explicit origination ser snyggare ut och är inte ovillkorlig. Ett network statement behöver normalt en matchande rutt i routingtabellen innan prefixet origineras, så annonsen försvinner i samma stund som CE slutar annonsera den. Det är ofta det beteende du vill ha, och det är inte samma sak som en statisk rutt som ligger kvar konfigurerad för alltid. Kontrollera plattformens faktiska regel i stället för att anta något av beteendena.

Hur som helst är frågan för varje prefix vilken aktiv källa som gör det kvalificerat och vad som händer när den källan försvinner.

Verifiera kedjan på fyra ställen

Titta på CE-annonsen, VRF-routingtabellen, VPN-ruttabellen med sin route target och importen i den avlägsna VRF:en, i den ordningen. I IOS betyder det CE-grannutskriften, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, och samma kommando på den avlägsna PE:n. I IOS-XR finns motsvarande utskrift under show bgp vrf CUSTOMER ipv4 unicast. Kommandonamnen skiljer sig, de fyra kontrollpunkterna inte.

Kontrollera ett prefix som bör avvisas lika noggrant som ett som bör passera, eftersom en policy som tillåter allt ser identisk ut med en korrekt tills det första undantaget kommer. Titta sedan på en withdrawal: stäng CE-gränssnittet och bekräfta att den avlägsna posten försvinner inom förväntad timer i stället för att ligga kvar.

Anteckna vem som äger varje policy. När leverantören driver CE:n hör det levererade beteendet hemma i serviceavtalet, och ett annat protokoll eller en annan withdrawal-policy på den hanterade enheten är först ett dokumentationsproblem och sedan ett routingproblem.