BGP-sessie staat, klantpad kapot: MPLS over DMVPN

De peering staat al weken, het aantal prefixen lijkt te kloppen, en toch neemt het verkeer van één klant nog steeds de lange weg of komt het nooit aan. Twee verschillende dingen worden door dezelfde indicator beoordeeld. Een BGP-sessie meldt dat twee peers berichten kunnen uitwisselen over een TCP-verbinding; over de vraag of de overlay een gelabeld pakket voor precies die klant kan dragen, zegt zij niets.

Dat gat is het gemakkelijkst te zien in een MPLS-over-DMVPN-ontwerp, waar het hub-pad en het directe spoke-pad zich anders kunnen gedragen om redenen die niets met de peering te maken hebben.

Wat de sessie werkelijk bewijst

BGP draait over TCP, dus elke peer heeft een route nodig naar het adres van het andere uiteinde voordat er iets anders kan gebeuren. Kies je een loopback als dat uiteinde, dan heb je een bereikbaarheidseis gecreëerd, geen doorstuurgarantie. De sessie kan daarna overeind blijven via een interface die het klantverkeer nooit zou gebruiken.

Noteer vier feiten aan beide uiteinden voordat je conclusies trekt: het bronadres van de sessie, het bestemmingsadres, de routeringscontext waarin zij zit, en welke interface de kernel of router voor dat paar zou kiezen. Die feiten beschrijven het besturingsvlak. Klantpakketten voegen daar een VRF, een labelstack en een overlay-mapping aan toe.

Vier mechanismen, niet één

De documentatie van Cisco over MPLS over DMVPN scheidt de onderdelen duidelijk. MP-BGP verdeelt de overlay-labels van de klant tussen apparaten aan de rand van de provider. MPLS gebruikt die labels om de doorstuuropzet voor een pakket te kiezen. NHRP koppelt een overlay-adres aan het transportuiteinde dat een dynamische tunnel nodig heeft. IPsec beschermt het peer-pad waar dat van toepassing is.

Elk van de vier kan goed zijn terwijl een ander fout is, en de combinatie is wat verkeer draagt. Een route-uitwisseling kan voltooid zijn terwijl de labelbinding voor één VRF ontbreekt, terwijl de NHRP-mapping naar een verouderd transportadres wijst, of terwijl de tunnel bestaat maar geen beleid het binnenste pakket toestaat. Geen van die toestanden laat de sessie vallen.

Vergelijk het hub-pad met de kortere weg, één variabele tegelijk

Zet de bronhost, de bestemmingshost en de VRF vast en volg dan dezelfde stroom twee keer. Op het hub-pad noteer je de volgende hop, het servicelabel dat de externe klantcontext identificeert, en de gebruikte overlay-naar-transport-mapping. Op het beoogde directe pad noteer je dezelfde drie dingen. Het verschil tussen de twee lijsten is de storing, of het ontbreken daarvan.

Houd de stroom constant tijdens de vergelijking. De bronhost, de VRF of de bestemming tussen waarnemingen wijzigen levert twee ongerelateerde verhalen op, en dat is de meest voorkomende manier waarop deze oefening mislukt.

Houd loopback-tests in hun eigen compartiment

Een ping vanaf de loopback van een router is een nuttige test, en hij oefent een ander geval dan een stroom vanaf een host. Het bronadres hoort bij de router, de routeringscontext kan globaal zijn in plaats van een VRF, en het antwoordpad kan verschillen van het pad dat een klantprefix zou nemen. Dus de loopback die antwoordt en de toepassing die via de kortere weg werkt zijn aparte resultaten, en alleen het tweede beschrijft de klant.

Test beide en label ze daarna apart in je notities. Als ze het oneens zijn, heb je iets concreets geleerd over waar het ontwerp afwijkt, en dat is meer dan één groen vinkje ooit zal vertellen.

Versie- en defectbeweringen hebben hun eigen bewijs nodig

Veldrapporten adviseren soms een hostmasker of een BGP-bronadres te wijzigen, en zulke rapporten zijn alleen de moeite waard naast het defect waarover ze zijn geschreven en de releases die het trof. Een omweg uit één release is geen uitspraak dat elk /32-prefix door de architectuur niet wordt ondersteund.

Gebruik documentatie die past bij je DMVPN-fase, platform en release, en bedenk dat één hoofdstuk meerdere opstellingen kan dekken, inclusief FlexVPN. Een voorbeeld uit één opstelling gaat niet stilzwijgend naar een andere over. Kies sessie-uiteinden voor het besturingsvlakontwerp dat je werkelijk nodig hebt, en verifieer daarna het doorstuurpad van de klant apart, want elke loopback-masker herschrijven is geen vervanging voor uitzoeken welke taak is mislukt.