BGP-seanss üleval, kliendi tee katki: MPLS üle DMVPN-i

Peerimine on olnud üleval nädalaid, prefiksite arv näib õige, ja ometi läheb ühe kliendi liiklus endiselt pikemat teed või ei jõua kohale üldse. Sama indikaator hindab kahte erinevat asja. BGP-seanss teatab, et kaks peeri saavad TCP-ühenduse kaudu sõnumeid vahetada; see ei ütle midagi selle kohta, kas overlay suudab kanda märgistatud paketi just selle kliendi jaoks.

Seda lünka on kõige lihtsam näha MPLS-over-DMVPN lahenduses, kus jaoturi tee ja otsene spoke tee võivad käituda erinevalt põhjustel, millel pole peerimisega mingit seost.

Mida seanss tegelikult tõestab

BGP töötab TCP peal, seega vajab iga peer enne muu toimumist marsruuti teise otspunkti aadressini. Kui valid selleks otspunktiks loopbacki, oled loonud kättesaadavuse nõude, mitte edastamise garantii. Seanss võib seejärel püsida üleval liidese kaudu, mida kliendi liiklus kunagi ei kasutaks.

Enne järelduste tegemist pane kirja neli fakti mõlemas otsas: seansi lähteaadress, sihtaadress, marsruutimiskontekst, milles see asub, ja millise liidese kernel või ruuter selle paari jaoks valiks. Need faktid kirjeldavad juhtimistasandit. Kliendi paketid lisavad nende peale VRF-i, siltide virna ja overlay-vastenduse.

Neli mehhanismi, mitte üks

Cisco dokumentatsioon MPLS-i kohta DMVPN-i peal eristab osad selgelt. MP-BGP levitab kliendi overlay-silte teenusepakkuja servaseadmete vahel. MPLS kasutab neid silte paketi edastuskonteksti valimiseks. NHRP vastendab overlay-aadressi transpordi otspunktiga, mida dünaamiline tunnel vajab. IPsec kaitseb peeri teed seal, kus see kehtib.

Ükskõik milline neljast võib olla õige, samal ajal kui teine on vale, ja liiklust kannab just kombinatsioon. Marsruutide vahetus võib lõpule jõuda, samal ajal kui ühe VRF-i sildi sidumine puudub, NHRP-vastendus osutab vananenud transpordiaadressile või tunnel on olemas, kuid ükski poliitika ei luba sisemist paketti. Ükski neist tingimustest ei kuku seanssi maha.

Võrdle jaoturi teed lühiühendusega, üks muutuja korraga

Fikseeri lähtevastuvõtja, sihtvastuvõtja ja VRF, seejärel jälgi sama voogu kaks korda. Jaoturi teel pane kirja järgmine hüpe, teenusesilt, mis tuvastab kaugema kliendikonteksti, ja kasutatav overlay-transpordi vastendus. Kavandatud otsesel teel pane kirja samad kolm asja. Kahe nimekirja vahe on rike, või selle puudumine.

Hoia voog võrdlemise ajal muutumatuna. Lähtevastuvõtja, VRF-i või sihtkoha muutmine vaatluste vahel annab kaks seosetut lugu, ja see on kõige tavalisem viis, kuidas see harjutus untsu läheb.

Hoia loopback-testid eraldi lahtris

Ruuteri loopbackilt saadetud ping on kasulik test ja see kontrollib teistsugust juhtumit kui vastuvõtjalt lähtuv voog. Lähteaadress kuulub ruuterile, selle marsruutimiskontekst võib olla globaalne, mitte VRF, ja vastusteekond võib erineda sellest, mille kliendi prefiks võtaks. Nii on loopback, mis vastab, ja rakendus, mis lühiühenduse kaudu töötab, eraldi tulemused, ja ainult teine kirjeldab klienti.

Testi mõlemat ja märgi need seejärel märkmetes eraldi. Kui need lahknevad, oled õppinud midagi konkreetset selle kohta, kus lahendus hälbib, ja see on rohkem, kui üks roheline linnuke sulle kunagi ütleb.

Versiooni- ja defektiväited vajavad oma tõendeid

Väljaraportid soovitavad mõnikord muuta vastuvõtja maski või BGP lähteaadressi, ja selliseid raporteid tasub lugeda ainult koos defektiga, millest need kirjutati, ja väljalasetega, mida see mõjutas. Ühe väljalaske möödasõit ei ole väide, et iga /32 prefiksit arhitektuur ei toeta.

Kasuta dokumentatsiooni, mis vastab sinu DMVPN faasile, platvormile ja väljalaskele, ja pea meeles, et üks peatükk võib katta mitut paigutust, sealhulgas FlexVPN. Ühe paigutuse näide ei kandu vaikselt teisele. Vali seansi otspunktid juhtimistasandi lahenduse järgi, mida sa tegelikult vajad, seejärel kontrolli kliendi edastusteed eraldi, sest iga loopback-maski ümberkirjutamine ei asenda selle väljaselgitamist, milline töö ebaõnnestus.