Noen L2VPN-ruter forsvinner når du legger til rutereflektorer

Sesjonene holder seg oppe, IGP-en er stabil, og likevel dukker noen få L2VPN-ruter aldri opp på to av de fire leverandørkantene. Det mønsteret hører til et refleksjonsproblem og ikke et transportproblem, fordi en brutt sesjon feiler fullstendig, mens en gjenbrukt refleksjonsgrense feiler selektivt. Den fysiske ringen har ingenting med det å gjøre; den logiske distribusjonsgrafen er der disse rutene stoppet. Å finne det punktet krever ikke at du bygger kontrollplanet på nytt.

Tapet er selektivt, og det snevrer inn søket

Fire leverandørkanter på en fysisk ring trenger seks logiske sesjoner for et fullt mesh, siden hver ruter pares med de tre andre. Disse sesjonene går over den rutede transporten, så kablingen sier ingenting om hvor mange naboskap som finnes eller hvilke av dem som reflekterer. Når to kanter mangler et bestemt sett med prefikser mens alt annet konvergerer, er kabelen ikke den mistenkte.

Selektivt tap peker mot sløyfeforebygging, policy eller relasjonsretning, der noen ruter krysser en grense og andre kastes underveis. Totalt tap peker mot sesjonen eller adressefamilien. Å avgjøre hvilken av de to du ser på er det første nyttige trinnet, og det tar én kommando.

Hva refleksjon faktisk endrer

Ruterefleksjon lemper på regelen om at en iBGP-snakker ikke kan annonsere på nytt en rute lært fra en annen iBGP-snakker. RFC 4456 uttrykker unntaket gjennom forholdet mellom snakkeren og rutens kilde, og retningen på det forholdet betyr mer enn de fleste sammendrag antyder. En rute lært fra en klient kan reflekteres til andre klienter og til ikke-klienter, mens en rute lært fra en ikke-klient bare kan reflekteres til klienter. Les asymmetrien to ganger, for den forklarer hvordan det å legge til en klientrelasjon kan skjule en designfeil: den åpner en vei topologien aldri hadde tenkt seg.

Attributtet CLUSTER_LIST registrerer refleksjonshistorikken, og en reflektor som finner sin egen klynge-ID i den listen, må ignorere annonsen. Det er sløyfeforebygging, og det er også mekanismen som sletter ruter når identifikatorer gjenbrukes ved et uhell. ORIGINATOR_ID spiller en beslektet rolle ved å navngi ruteren som først annonserte ruten.

Gjenbrukte klynge-ID-er er hvordan ruter forsvinner

Et lite nettverk innbyr til en snarvei: gi hver ruter en klynge-ID lik loopbacken, legg til enda en reflektor senere, og gjenbruk en eksisterende loopback fordi den er praktisk tilgjengelig. Hvis den identifikatoren nå dukker opp på to uavhengige refleksjonstrinn, ser det andre trinnet sin egen ID i CLUSTER_LIST og forkaster ruten. Ingenting logger en feil, fordi forkasting er det riktige svaret på en sløyfe.

Overflødige reflektorer som betjener én klynge er det legitime unntaket: de deler en ID med vilje slik at hver av dem kan betjene de samme klientene. Identifikatoren må samsvare med refleksjonsdesignet i stedet for å skille kabinettnavn.

Tegn den tiltenkte grafen før du rører noen konfigurasjon: hvem oppretter prefikset, hvilken klientrelasjon tillater den første refleksjonen, hvilken reflektor bærer den til neste trinn, og hvor den siste klienten sitter. Hvert hopp i den grafen er et sted der en gjenbrukt identifikator, en manglende klientrelasjon eller et policyfilter kan stoppe ruten. Når grafen er tegnet, har en manglende rute en plassering i stedet for et mysterium.

Motstå fristelsen til å gjøre hver nabo til klient

Den raske reparasjonen for en manglende rute er å gjøre hver nabo til klient hos hver reflektor. Utbredelsen kommer tilbake, og designet slutter å fortelle deg noe: det mangedobler rutene hver snakker bærer, samtidig som det skjuler hvilken relasjon som skulle gjøre arbeidet.

Et lite nettverk trenger vanligvis en av to former. Et fullt iBGP-mesh er seks sesjoner for fire rutere helt uten refleksjon, og et utpekt par reflektorer som betjener de gjenværende kantene er den andre. Begge er lettere å resonnere om enn et delvis mesh der hver ruter reflekterer litt. Velg formen etter skala og feilatferd, ikke etter kablingstegningen.

Sjekk adressefamilien før du klandrer refleksjonen

En TCP-sesjon på port 179 beviser at de to snakkerne kan snakke sammen, og ingenting om hvorvidt VPN-adressefamilien utvekslet én eneste rute. Fastslå sesjonstilstanden, deretter familien, deretter det enkelte prefikset.

vtysh -c "show bgp summary"
vtysh -c "show bgp l2vpn evpn summary"
vtysh -c "show bgp l2vpn evpn"

Disse tre utdataene skiller et naboproblem fra et utvekslingsproblem og fra et manglende prefiks. Hvis familien ikke viser noen prefikser i det hele tatt, undersøk naboens aktiveringstilstand og eksportpolicy før du ser på refleksjon. Hvis prefikser vises på én kant men ikke på en annen, sammenlign klyngelisten og originatoren på mottakersiden, og gå deretter gjennom grafen fra forrige avsnitt.

Hold rekkevidden til neste hopp og videresendingstilstanden utenfor den kontrollen. En reflektert rute med et utilgjengelig neste hopp er til stede og ubrukelig, noe som ser ut som en refleksjonsfeil til du ser på kolonnen for neste hopp. Løs neste hopp, bekreft videresendingsoppføringen, og først da avgjør om distribusjonsgrafen trenger enda en reflektor.