Sommige L2VPN-routes verdwijnen nadat u routereflectors toevoegt

Sessies blijven actief, de IGP is stabiel, en toch verschijnen een paar L2VPN-routes nooit op twee van de vier provider-randen. Dat patroon hoort bij een reflectieprobleem en niet bij een transportprobleem, omdat een gebroken sessie volledig faalt terwijl een hergebruikte reflectiegrens selectief faalt. De fysieke ring heeft er niets mee te maken; de logische distributiegraaf is de plek waar die routes stopten. Dat punt vinden vereist niet dat u het controlevlak opnieuw bouwt.

Het verlies is selectief, wat het zoeken vernauwt

Vier provider-randen op een fysieke ring hebben zes logische sessies nodig voor een volledig mesh, omdat elke router met de andere drie paart. Die sessies lopen over het gerouteerde transport, dus de bekabeling zegt niets over hoeveel aanliggende relaties er zijn of welke daarvan reflecteren. Wanneer twee randen een specifieke set prefixes missen terwijl al het andere convergeert, is de kabel niet de verdachte.

Selectief verlies wijst op luspreventie, beleid of de richting van de relatie, waarbij sommige routes een grens oversteken en andere onderweg worden weggegooid. Totaal verlies wijst op de sessie of de adresfamilie. Bepalen welke van de twee u ziet is de eerste nuttige stap, en dat kost één commando.

Wat reflectie werkelijk verandert

Routereflectie versoepelt de regel dat een iBGP-spreker een route die hij van een andere iBGP-spreker leerde niet opnieuw mag aankondigen. RFC 4456 drukt de uitzondering uit via de relatie tussen de spreker en de bron van de route, en de richting van die relatie is belangrijker dan de meeste samenvattingen suggereren. Een route die van een cliënt is geleerd mag naar andere cliënten en naar niet-cliënten worden gereflecteerd, terwijl een route die van een niet-cliënt is geleerd alleen naar cliënten mag worden gereflecteerd. Lees de asymmetrie twee keer, want ze verklaart hoe het toevoegen van een cliëntrelatie een ontwerpfout kan verbergen: het opent een pad dat de topologie nooit bedoelde.

Het attribuut CLUSTER_LIST legt de reflectiegeschiedenis vast, en een reflector die zijn eigen cluster-ID in die lijst vindt moet de aankondiging negeren. Dat is luspreventie, en het is ook het mechanisme dat routes verwijdert wanneer identificatoren per ongeluk opnieuw worden gebruikt. ORIGINATOR_ID speelt een verwante rol door de router te noemen die de route als eerste aankondigde.

Hergebruikte cluster-ID's zijn hoe routes verdwijnen

Een klein netwerk nodigt uit tot een sluiproute: geef elke router een cluster-ID gelijk aan zijn loopback, voeg later nog een reflector toe, en hergebruik een bestaande loopback omdat die handig voorhanden is. Als die identificator nu in twee onafhankelijke reflectiefasen verschijnt, ziet de tweede fase zijn eigen ID in CLUSTER_LIST en gooit de route weg. Niets logt een fout, omdat weggooien het juiste antwoord op een lus is.

Overbodige reflectors die één cluster bedienen zijn de legitieme uitzondering: ze delen opzettelijk een ID zodat elk van hen dezelfde cliënten kan bedienen. De identificator moet bij het reflectieontwerp passen en niet kastnamen onderscheiden.

Teken de bedoelde graaf voordat u enige configuratie aanraakt: wie het prefix origineert, welke cliëntrelatie de eerste reflectie toestaat, welke reflector het naar de volgende fase draagt, en waar de laatste cliënt zit. Elke hop in die graaf is een plek waar een hergebruikte identificator, een ontbrekende cliëntrelatie of een beleidsfilter de route kan stoppen. Met de graaf getekend heeft een ontbrekende route een locatie in plaats van een mysterie.

Weersta de neiging om elke buur cliënt te maken

De snelle reparatie voor een ontbrekende route is elke buur cliënt van elke reflector maken. De verspreiding komt terug, en het ontwerp vertelt u niets meer: het vermenigvuldigt de routes die elke spreker draagt terwijl het verbergt welke relatie het werk had moeten doen.

Een klein netwerk heeft meestal een van twee vormen nodig. Een volledig iBGP-mesh is zes sessies voor vier routers zonder enige reflectie, en een aangewezen paar reflectors dat de resterende randen bedient is de andere. Beide zijn eenvoudiger te beredeneren dan een gedeeltelijk mesh waarin elke router een beetje reflecteert. Kies de vorm op schaal en faalgedrag, niet op het bekabelingsdiagram.

Controleer de adresfamilie voordat u reflectie de schuld geeft

Een TCP-sessie op poort 179 bewijst dat de twee sprekers kunnen praten, en niets over de vraag of de VPN-adresfamilie één route heeft uitgewisseld. Stel de sessietoestand vast, dan de familie, dan het individuele prefix.

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

Die drie uitvoer scheidt een aanliggendheidsprobleem van een uitwisselingsprobleem en van een ontbrekend prefix. Als de familie helemaal geen prefixes toont, inspecteer dan de activeringsstatus en het exportbeleid van de buur voordat u naar reflectie kijkt. Als prefixes op de ene rand verschijnen maar niet op de andere, vergelijk dan de clusterlijst en de originator aan de ontvangende kant en loop daarna de graaf uit de vorige sectie door.

Houd de bereikbaarheid van de volgende hop en de doorstuurstatus buiten die controle. Een gereflecteerde route met een onbereikbare volgende hop is aanwezig en onbruikbaar, wat op een reflectiefout lijkt tot u naar de kolom van de volgende hop kijkt. Los de volgende hop op, bevestig de doorstuurvermelding, en beslis pas daarna of de distributiegraaf nog een reflector nodig heeft.