Ontbrekende route in de VRF: lokaal, VPNv4 of doorstuurtabel?
Een prefix dat in de VRF ontbreekt, in VPNv4 ontbreekt en niet in CEF is geïnstalleerd, zijn drie verschillende storingen. Lees de tabellen op volgorde voordat u route-targets aanpast.
Een klant meldt dat een prefix ontbreekt na een wijziging van het route-target, en de eerste schermafbeelding die hij stuurt is meestal de verkeerde tabel. Drie verschillende tabellen beantwoorden drie verschillende vragen: of het prefix binnen de VRF bestaat, of het als VPNv4-route is aangekondigd en geïmporteerd, en of er werkelijk een doorstuurvermelding is geïnstalleerd. Ze in de verkeerde volgorde lezen levert stellige en onjuiste conclusies op. Deze runbook leidt één lokaal en één extern prefix in volgorde door alle drie de tabellen, en eindigt met een terugdraaiplan voor de RT-wijziging die het begon.
Benoem het prefix en de tabel waarin het thuishoort
Schrijf twee prefixen op voordat u iets typt. Eén is lokaal op de locatie van de klant, geleerd van een aangesloten interface of een CE-aankondiging. Het andere is extern en wordt verwacht via de backbone van de provider. Ze nemen verschillende paden naar dezelfde VRF, en een storing in het ene zegt niets over het andere.
| Table | Question it answers | Command |
|---|---|---|
show ip vrf CUST-A | Which RTs are attached for import and export | Read the RT lists before anything else |
show ip route vrf CUST-A | Is the prefix present in this VRF at all | Local and imported routes both appear |
show ip bgp vpnv4 all | Was the NLRI advertised and retained | Keyed by route distinguisher |
show ip cef vrf CUST-A | Was a forwarding entry installed | Proves a usable path, not just a BGP entry |
Houd het onderscheid tussen de twee identifiers scherp, want daar komt het meeste misverstand in deze tickets vandaan. De route-onderscheider maakt deel uit van de VPNv4-NLRI en bestaat om verder identieke klantprefixen uniek te maken over de backbone. Het route-target is een uitgebreide community die als attribuut wordt gedragen, en daarop matcht het import- en exportbeleid. Het is geen tweede naam voor de onderscheider en het wordt niet in de pakketten van de klant gedragen.
Stap 1: bewijs dat het prefix in de VRF staat
Begin met de lokale weergave en daarna met de RT’s die de import bepalen. Als het lokale prefix hier ontbreekt, kan niets stroomopwaarts de schuld zijn:
show ip route vrf CUST-A 172.21.4.0 255.255.255.0
show ip route vrf CUST-A | include 172.21.4.0
show ip vrf CUST-AEen prefix dat als verbonden of statisch verschijnt, is lokaal geleerd, en de aanwezigheid ervan zegt niets over de vraag of het is geëxporteerd. Dat is de meest voorkomende verkeerde lezing in deze werkwijze: een gezonde VRF-tabel is alleen bewijs over lokaal leren. De exportkant is een aparte vraag, die de buurweergave en het aangehechte export-target beantwoorden.
Controleer de RT-lijsten op de VRF terwijl u hier bent. Als het bedoelde import-target niet in de lijst staat, is alles stroomafwaarts irrelevant. Als het er wel staat maar afwijkt van wat de externe PE exporteert, hebt u de storing gevonden zonder één pakketopname te openen.
Stap 2: lees de VPNv4-tabel en de targets ervan
De VPNv4-tabel laat zien wat het controlevlak werkelijk heeft uitgewisseld. Zoek het externe prefix onder de juiste onderscheider en kijk dan naar de communities die eraan hangen:
show ip bgp vpnv4 all 10.60.9.0/24
show ip bgp vpnv4 all | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A neighbors 192.0.2.17 advertised-routesEen vermelding met het juiste route-target maar zonder lokale installatie wijst op importbeleid of op routeselectie, niet op bereikbaarheid. Een vermelding die helemaal niet in de VPNv4-tabel verschijnt, wijst omhoog: de oorspronkelijke PE heeft hem misschien niet geëxporteerd, of de sessie draagt de adresfamilie niet.
Er is een derde geval dat mensen tijdens wijzigingen in de war brengt. Sommige platforms beperken welke VPN-routes ze opvragen of vasthouden, met behulp van lidmaatschapsinformatie van route-targets, dus het ontbreken van een extern NLRI in één gefilterde weergave is geen bewijs dat de aankondiging nergens bestaat. Controleer de ongefilterde tabel en de aangekondigde routes van de buur voordat u concludeert dat een route wereldwijd is ingetrokken.
Stap 3: bevestig dat er iets is geïnstalleerd en gelabeld
Een BGP-vermelding is een beslissing, geen pad. De doorstuurtabellen vertellen of pakketten ergens heen kunnen:
show ip cef vrf CUST-A 10.60.9.0/24
show mpls forwarding-table vrf CUST-A | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-AEen CEF-vermelding met een opgeloste nabuurschap en een uitgaand label betekent dat verkeer in de dataplane moet werken, en elk resterend symptoom hoort bij de toepassing of bij filteren binnen de VRF. Een CEF-vermelding met een niet-opgeloste volgende hop betekent dat het labelpad onvolledig is terwijl BGP gezond lijkt, en dat is precies het geval waarin een schermafbeelding van de BGP-tabel een wijzigingsbeoordeling heeft misleid.
Vergelijk het label dat de lokale PE oplegt met het label dat de externe PE verwacht te ontvangen. Een verschil tussen de twee weergaven is een probleem met labeltoewijzing of met de sessie, en het wordt niet opgelost door route-targets aan te passen, hoe vaak u dat ook doet.
Draai de RT-wijziging terug met een verklaarde reikwijdte
Als de storing begon met een wijziging van het route-target, maak die dan ongedaan als één bewuste stap en zeg welke reikwijdte u wijzigt. Het verwijderen van een import-target trekt de geschiktheid binnen die VRF in. Het wist de VPNv4-aankondiging niet uit de backbone, en op sommige platforms blijft de route in de tabel gehouden. Dat zijn verschillende uitkomsten en het voor de gebruiker zichtbare effect hangt af van welke u bedoelt.
configure terminal
vrf definition CUST-A
address-family ipv4
no route-target import 65000:410
end
clear ip bgp vpnv4 vrf CUST-A soft inEen zachte inkomende herconfiguratie is genoeg wanneer de sessie de prefixen al opslaat; een harde reset van een sessie richting de provider tijdens kantooruren is een beslissing die iemand anders moet nemen. Op Junos lezen de equivalente controles de tabel per VRF en de VPN-tabel rechtstreeks, en het terugdraaien is een terugkeer bij commit en niet een undo per commando, dus leg het configuratieverschil vast voordat u begint.
Sluit af met dezelfde drie commando’s als waarmee u begon, in dezelfde volgorde, en leg hun uitvoer vast met een tijdstempel. Een ticket dat zegt dat het RT verkeerd was en nu goed is, is niet herbruikbaar; een dat laat zien dat het prefix in de VRF, in VPNv4 en in CEF is geïnstalleerd, is bewijs waarmee de volgende persoon kan vergelijken. Als alleen de eerste twee zijn veranderd, hebt u de wijziging niet afgemaakt.