De RSVP-TE-tunnel staat, maar het L3VPN van de klant heeft geen pad

Twee teams kunnen allebei gelijk hebben wanneer de klant meldt dat de VPN plat ligt en het transportteam meldt dat de tunnel in orde is. Een met traffic engineering opgezette LSP en een MPLS L3VPN beantwoorden verschillende vragen: de ene verplaatst gelabelde pakketten door de core, de andere bepaalt bij welke routingcontext een pakket hoort. Worden ze door elkaar gehaald, dan draait de discussie in rondjes, omdat elke kant een ander object meet en beide metingen geldig zijn.

Transport omhoog en dienst omlaag is een normale toestand

Een LSP kan zijn opgezet, verkeer dragen en in elk monitoringssysteem zichtbaar zijn, terwijl de klantdienst onbruikbaar blijft. Niets aan die combinatie is tegenstrijdig, omdat de tunnel geen mening heeft over of een remote prefix bestaat, of een importbeleid die heeft geaccepteerd, of de aangesloten schakeling frames doorlaat.

Het symptoom dat de verwarring meestal blootlegt, is asymmetrisch: pings vanaf de PE-loopback slagen terwijl een host op het klant-LAN niets krijgt, of omgekeerd. Schrijf op welke adressen werkten voordat je een theorie vormt. Zodra je merkt dat je twee verschillende objecten test, is de volgende stap de labelstack lezen in plaats van discussiëren over wiens grafiek correct is. Twee adressen, twee eigenaren en meestal twee verschillende mensen die ieder geloven dat de ander iets kapot heeft gemaakt.

Lees de stack als twee verantwoordelijkheden

Het onderste label hoort bij de dienst en het bovenste label hoort bij het pad. RFC 4364 beschrijft de volgorde simpel: eerst wordt het VPN-routelabel opgelegd, daarna wordt dat gelabelde pakket naar de BGP-next-hop getunneld, waar een traffic-engineeringtunnel zijn eigen label erbovenop duwt.

Op de verre PE kiest het dienstlabel de behandeling, die een VRF-lookup of een koppelingsbeslissing kan zijn. Dat label kan niet worden vervangen door een label dat alleen de core doorkruist, en de twee zijn niet uitwisselbaar, zelfs niet wanneer beide in dezelfde stack op dezelfde interface verschijnen.

Wat RSVP-succes bewijst en wat niet

RSVP-TE zet expliciet gerouteerde LSP's op, met of zonder resource-reserveringen, wat een concrete en nuttige garantie is over het pad dat een pakket door de core aflegt. Het is geen uitspraak over klantroutes, en een geconfigureerde tunnelnaam is helemaal geen route.

Ook de aanwezigheid van RSVP levert geen einde-tot-eind prestatiebelofte op. Bandbreedtereservering op één LSP zegt niets over de aangesloten schakeling, de eigen toegangslijn van de klant of het wachtrijgedrag aan de verre rand. Het als garantie behandelen levert zelfverzekerde antwoorden op vragen die niemand stelde. Als de eis werkelijk een bandbreedteverplichting is, moet die worden samengesteld uit de onderdelen die er daadwerkelijk een afdwingen, en de LSP is slechts het midden van die keten.

Controleer in volgorde en stop dan

Werk van transport naar buiten en stop bij de eerste stap die faalt, omdat elke latere stap veronderstelt dat de eerdere standhielden. Bevestig eerst dat de LSP is opgezet en dat de doorstuurinvoer voor het dienstprefix er daadwerkelijk naar wijst. Bevestig daarna dat de VPN-route in de juiste tabel bestaat, dat de labelbinding aanwezig is en dat het importbeleid die heeft geaccepteerd. Bevestig daarna de koppeling: de interface, de encapsulatie en, waar van toepassing, de VLAN-identificatie die bij dat contract hoort.

show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMER

De opdrachtsyntaxis verschilt per platform, dus behandel die vier regels als de vier vragen en niet als een script. Het belangrijke is dat elke ervan een ander object ondervraagt, en dat is wat een storing naar een specifieke eigenaar laat wijzen.

Volg één toegestaan verzoek en bewaar het goede bewijs

Sluit af met één echt klantverzoek, toegestaan door het beleid, en het antwoord daarop. Eén werkende stroom van begin tot eind beslecht meer dan een pagina telleruitlezingen, en het beoefent de combinatie in plaats van elk onderdeel afzonderlijk.

Wanneer een latere fase faalt, bewaar dan de geslaagde LSP-waarneming in plaats van het transport opnieuw op te bouwen. Het opnieuw opbouwen van een werkende tunnel kan een ontbrekend remote prefix, een verkeerde VRF-koppeling of een toegangsregel voor de bestemming niet repareren, en het vernietigt het bewijs dat je aanvankelijk vertelde dat het transport gezond was.