Twee PE's, één prefix: waarom de RD de zichtbaarheid bepaalt

Twee edgerouters die hetzelfde klantprefix adverteren beschrijven één VPNv4-bestemming tot iets ze scheidt, en de scheiding is de route distinguisher. Die kwalificeert het prefix; hij bepaalt niet wie het resultaat importeert, dat is de taak van de route target. Wijs RD's toe vanuit de verzameling routes die in elk domein waar die advertenties elkaar kunnen ontmoeten onderscheidbaar moeten blijven, niet vanuit de bestandsindeling van één doos. Het nummer dat u kiest is een identiteit waar latere beoordelingen van afhangen, dus het hoort in een inventaris voordat het in een configuratie belandt.

Een RD plus een prefix is één bestemming

Een RD plus een IPv4-prefix vormt de VPNv4-bestemming die het controlevlak vergelijkt. Geef twee PE's hetzelfde prefix voor verschillende klanten en zonder verschillende RD's adverteren ze routes naar één bestemming. Niets op een scherm vertelt u dat die groepering onjuist is, omdat het platform precies doet wat de identiteit zegt. Wijzig de RD op een van beide en de oude advertentie wordt ingetrokken terwijl onder een andere identiteit een nieuwe verschijnt. Alles stroomafwaarts dat op de oude identiteit was gesleuteld, van routekeuze tot een opgeslagen operatorfilter, verwijst nu naar iets dat niet meer bestaat.

Meerdere routes per bestemming is normaal BGP-gedrag, geen symptoom. Een speaker kan meerdere ontvangen routes houden terwijl hij één beste route voor doorsturen selecteert, en de kloof tussen ontvangen en geselecteerd is waar de zichtbaarheidsvragen leven. Wanneer een route verdwenen lijkt, controleer dan of de identiteit waartoe hij behoorde nog bestaat voordat u naar de sessie kijkt.

Dezelfde RD, dezelfde bestemming, andere routes

Stuur één RD en één prefix vanaf twee routers namens dezelfde dienst en beide bieden routes naar één bestemming, meestal met verschillende volgende hops. Welke daarvan een route reflector doorgeeft is een beslissing over de reflector: zijn routekeuze, zijn advertentievermogen en elk beleid dat eroverheen ligt. Geen van de edgerouters beheert die keuze. Geef de twee advertenties verschillende RD's en elk wordt zijn eigen bestemming, zodat beide een controlevlak kunnen overleven dat anders alleen de geselecteerde route voor één identiteit draagt.

Zichtbaarheid en multipath ontmoeten elkaar in de ontvangende VRF, maar het zijn niet dezelfde beslissing, en een reflector die twee identiteiten draagt heeft geen tweede geïnstalleerde route geconfigureerd. De VRF installeert wat zijn importbeleid toelaat en wat zijn eigen instelling voor maximaal aantal routes toestaat. Controleer die instelling apart wanneer u wilt dat de tweede route wordt gebruikt en niet alleen zichtbaar is.

Een lokale uniciteitsregel is geen beleid

Elke PE en elke routinginstantie een eigen RD geven is een gezonde conventie: het benoemt de oorsprong, houdt onverwante diensten ervan af op één identiteit te botsen en geeft de inventaris een stabiele sleutel. Sommige platforms vereisen alleen uniciteit binnen de doos en staan routers uitdrukkelijk toe een RD te delen voor dezelfde VPN-instantie. Die toestemming is een implementatiebeperking, geen regel tussen netwerken die u aan een leverancier kunt delegeren. Als het domein teams omvat, schrijf het toewijzingsbeleid dan zelf.

Lidmaatschap komt nooit uit de cijfers. Een patroon zoals 65000:12 voor één PE en 65000:13 voor een andere is een gewoonte, terwijl overeenkomende export- en importtargets zoals 65000:112 zijn wat een route in een VRF zet. Behandel de RD als de identiteit van een route en de route target als de toestemming die hem in een VRF draagt.

Bewijs de wijziging op de VRF, niet op het scherm

Voordat u een RD aanraakt, noteert u vier dingen: wat de PE vandaag adverteert, wat de reflector reflecteert, wat de ontvangende VRF importeert en welke route hij selecteert. Een nieuwe RD trekt één advertentie in en voert een andere in, dus de wijziging is aan beide zijden van de sessie zichtbaar en gemakkelijk verkeerd te lezen als u alleen de adverterende kant volgt. Acceptatie moet rusten op de bereikbaarheid die u wilde, niet op een extra regel die in een prefixlijst verschijnt. De tabel hieronder houdt de drie identificaties tijdens die beoordeling uit elkaar.

Begin op de adverterende PE en vergelijk beide identiteiten voor hetzelfde prefix voordat u iets verwijdert. De IOS-opdrachten hieronder beantwoorden drie vragen in volgorde: staat de oude advertentie er nog, is de nieuwe identiteit zichtbaar voor de reflector en selecteert de VRF het prefix.

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

Andere platforms printen dezelfde informatie met een andere syntaxis, en de vragen overleven die wijziging. Ontbreekt de nieuwe identiteit bij de reflector terwijl de PE hem als geadverteerd vermeldt, dan is het beleid of het advertentievermogen van de reflector de eerste verdachte, niet de nummering.

Leg de PE, instantie, RD, export- en importtargets en het eigenaarschap van het prefix op één plek vast, want de volgende toewijzing is een opzoeking en geen gok alleen wanneer dat record bestaat. Houd de oude RD aan tot de nieuwe identiteit in de ontvangende VRF zichtbaar is, en trek hem dan in een tweede stap terug zodat elke fase omkeerbaar blijft.