Nogle L2VPN-ruter forsvinder, når du tilføjer rutereflektorer

Sessionerne forbliver oppe, IGP'en er stabil, og alligevel dukker en håndfuld L2VPN-ruter aldrig op på to af de fire udbyderkanter. Det mønster hører til et refleksionsproblem og ikke et transportproblem, fordi en brudt session fejler fuldstændigt, mens en genbrugt refleksionsgrænse fejler selektivt. Den fysiske ring har intet med det at gøre; den logiske distributionsgraf er der, hvor de ruter stoppede. Det punkt kræver ikke, at du genopbygger kontrolplanet.

Tabet er selektivt, og det indsnævrer søgningen

Fire udbyderkanter på en fysisk ring kræver seks logiske sessioner til et fuldt mesh, da hver router parres med de tre andre. De sessioner kører over den rutede transport, så kabelføringen siger intet om, hvor mange naboerskaber der findes, eller hvilke af dem der reflekterer. Når to kanter mangler et bestemt sæt præfikser, mens alt andet konvergerer, er kablet ikke den mistænkte.

Selektivt tab peger på loopforebyggelse, politik eller relationsretning, hvor nogle ruter krydser en grænse, og andre smides væk undervejs. Totalt tab peger på sessionen eller adressefamilien. At afgøre, hvilken af de to du ser på, er det første nyttige skridt, og det tager én kommando.

Hvad refleksion faktisk ændrer

Ruterefleksion lemper reglen om, at en iBGP-talker ikke må genannoncere en rute, der er lært fra en anden iBGP-talker. RFC 4456 udtrykker undtagelsen gennem forholdet mellem talkeren og rutens kilde, og retningen af det forhold betyder mere, end de fleste resuméer antyder. En rute lært fra en klient må reflekteres til andre klienter og til ikke-klienter, mens en rute lært fra en ikke-klient kun må reflekteres til klienter. Læs asymmetrien to gange, for den forklarer, hvordan tilføjelsen af en klientrelation kan skjule en designfejl: den åbner en vej, som topologien aldrig havde tænkt sig.

Attributten CLUSTER_LIST registrerer refleksionshistorik, og en reflektor, der finder sit eget klynge-ID på den liste, skal ignorere annonceringen. Det er loopforebyggelse, og det er også mekanismen, der sletter ruter, når identifikatorer genbruges ved et uheld. ORIGINATOR_ID spiller en beslægtet rolle ved at navngive den router, der først annoncerede ruten.

Genbrugte klynge-ID'er er, hvordan ruter forsvinder

Et lille netværk indbyder til en genvej: giv hver router et klynge-ID svarende til dens loopback, tilføj senere endnu en reflektor, og genbrug en eksisterende loopback, fordi den er bekvem at have ved hånden. Hvis den identifikator nu optræder på to uafhængige refleksionstrin, ser det andet trin sit eget ID i CLUSTER_LIST og kasserer ruten. Intet logger en fejl, fordi kassering er det korrekte svar på et loop.

Overflødige reflektorer, der betjener én klynge, er den legitime undtagelse: de deler med vilje et ID, så enhver af dem kan betjene de samme klienter. Identifikatoren skal matche refleksionsdesignet i stedet for at skelne chassisnavne.

Tegn den tilsigtede graf, før du rører nogen konfiguration: hvem oprinder præfikset, hvilken klientrelation tillader den første refleksion, hvilken reflektor bærer den til næste trin, og hvor den sidste klient sidder. Hvert hop i den graf er et sted, hvor en genbrugt identifikator, en manglende klientrelation eller et politikfilter kan stoppe ruten. Når grafen er tegnet, har en manglende rute en placering i stedet for et mysterium.

Modstå at gøre hver nabo til klient

Den hurtige reparation for en manglende rute er at gøre hver nabo til klient hos hver reflektor. Udbredelsen vender tilbage, og designet holder op med at fortælle dig noget: det mangedobler de ruter, hver talker bærer, mens det skjuler, hvilken relation der skulle have gjort arbejdet.

Et lille netværk har normalt brug for en af to former. Et fuldt iBGP-mesh er seks sessioner til fire routere helt uden refleksion, og et udpeget par reflektorer, der betjener de resterende kanter, er den anden. Begge er lettere at ræsonnere om end et delvist mesh, hvor hver router reflekterer lidt. Vælg formen efter skala og fejlopførsel, ikke efter kablingstegningen.

Kontroller adressefamilien, før du bebrejder refleksionen

En TCP-session på port 179 beviser, at de to talkere kan tale sammen, og intet om, hvorvidt VPN-adressefamilien udvekslede en enkelt rute. Fastslå sessionstilstanden, derefter familien, derefter det enkelte præfiks.

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

De tre output adskiller et naboproblem fra et udvekslingsproblem fra et manglende-præfiks-problem. Hvis familien slet ikke viser præfikser, skal du undersøge naboens aktiveringstilstand og eksportpolitik, før du ser på refleksion. Hvis præfikser vises på én kant men ikke på en anden, skal du sammenligne klyngelisten og oprinderen på modtagersiden og derefter gå grafen fra forrige afsnit igennem.

Hold næste hop-rækkevidde og videresendelsestilstand uden for den kontrol. En reflekteret rute med et utilgængeligt næste hop er til stede og ubrugelig, hvilket ser ud som en refleksionsfejl, indtil du ser på næste hop-kolonnen. Løs næste hop, bekræft videresendelsesposten, og beslut først derefter, om distributionsgrafen har brug for endnu en reflektor.