BGP-istunto pystyssä, asiakkaan polku rikki: MPLS DMVPN:n päällä
BGP-istunto todistaa yhden TCP-polun yhteen osoitteeseen. Asiakkaan liikenne tarvitsee myös oikean VRF:n, leiman ja NHRP-kartoituksen, ja molemmat viat näyttävät samalta.
Peering on ollut pystyssä viikkoja, prefiksien määrä näyttää oikealta, ja silti yhden asiakkaan liikenne kulkee yhä pitkää reittiä tai ei saavu perille lainkaan. Sama indikaattori arvioi kahta eri asiaa. BGP-istunto kertoo, että kaksi peeriä voi vaihtaa viestejä TCP-yhteyden yli; se ei kerro mitään siitä, pystyykö overlay kuljettamaan leimatun paketin juuri sille asiakkaalle.
Tämä aukko näkyy helpoimmin MPLS-over-DMVPN-ratkaisussa, jossa hub-reitti ja suora spoke-reitti voivat käyttäytyä eri tavoin syistä, joilla ei ole mitään tekemistä peeringin kanssa.
Mitä istunto todella todistaa
BGP toimii TCP:n päällä, joten jokainen peer tarvitsee reitin toisen pään osoitteeseen ennen kuin mitään muuta voi tapahtua. Jos valitset sellaiseksi pääksi loopbackin, olet luonut tavoitettavuusvaatimuksen, et välitystakuun. Istunto voi sitten pysyä pystyssä rajapinnan kautta, jota asiakkaan liikenne ei koskaan käyttäisi.
Kirjaa neljä tosiasiaa molemmissa päissä ennen johtopäätöksiä: istunnon lähdeosoite, kohdeosoite, reitityskonteksti jossa se on, ja minkä rajapinnan ydin tai reititin valitsisi sille parille. Nämä tosiasiat kuvaavat ohjaustasoa. Asiakkaan paketit lisäävät niiden päälle VRF:n, leimapinon ja overlay-kartoituksen.
Neljä mekanismia, ei yksi
Ciscon dokumentaatio MPLS:stä DMVPN:n päällä erottaa osat selvästi. MP-BGP jakaa asiakkaan overlay-leimat palveluntarjoajan reunalaitteiden välillä. MPLS käyttää näitä leimoja paketin välityskontekstin valintaan. NHRP kartoittaa overlay-osoitteen siihen siirtoyhteyden päähän, jota dynaaminen tunneli tarvitsee. IPsec suojaa peer-reittiä siellä, missä se soveltuu.
Mikä tahansa neljästä voi olla oikein samalla kun toinen on väärin, ja yhdistelmä on se, mikä kuljettaa liikennettä. Reittien vaihto voi valmistua, samalla kun yhden VRF:n leimasidonta puuttuu, NHRP-kartoitus osoittaa vanhentuneeseen siirto-osoitteeseen tai tunneli on olemassa mutta mikään käytäntö ei salli sisäpakettia. Mikään näistä ehdoista ei kaada istuntoa.
Vertaa hub-reittiä oikotiehen, yksi muuttuja kerrallaan
Kiinnitä lähdeisäntä, kohdeisäntä ja VRF ja seuraa sitten samaa virtaa kahdesti. Hub-reitillä kirjaa seuraava hyppy, palveluleima joka tunnistaa etäisen asiakaskontekstin, ja käytössä oleva overlay-siirto-kartoitus. Aiottuun suoraan reittiin kirjaa samat kolme asiaa. Kahden listan ero on vika, tai sen puuttuminen.
Pidä virta vakiona vertailun ajan. Lähdeisännän, VRF:n tai kohteen vaihtaminen havaintojen välillä tuottaa kaksi toisiinsa liittymätöntä tarinaa, ja se on yleisin tapa, jolla tämä harjoitus menee pieleen.
Pidä loopback-testit omassa lokerossaan
Reitittimen loopbackista lähetetty ping on hyödyllinen testi, ja se harjoittaa eri tapausta kuin isännästä lähtevä virta. Lähdeosoite kuuluu reitittimelle, sen reitityskonteksti voi olla globaali VRF:n sijaan, ja vastausreitti voi poiketa siitä, minkä asiakkaan prefiksi ottaisi. Niinpä vastaava loopback ja oikotien kautta toimiva sovellus ovat erillisiä tuloksia, ja vain jälkimmäinen kuvaa asiakasta.
Testaa molemmat ja merkitse ne sitten erikseen muistiinpanoihisi. Kun ne ovat eri mieltä, olet oppinut jotain konkreettista siitä, missä ratkaisu poikkeaa, ja se on enemmän kuin yksi vihreä valintamerkki koskaan kertoo.
Versio- ja vikaväitteet tarvitsevat omat todisteensa
Kenttäraportit suosittelevat joskus isäntämaskin tai BGP:n lähdeosoitteen muuttamista, ja sellaisia raportteja kannattaa lukea vain yhdessä sen vian kanssa, josta ne kirjoitettiin, ja niiden julkaisujen kanssa, joihin se vaikutti. Yhden julkaisun kiertotapa ei ole väite, ettei arkkitehtuuri tukisi jokaista /32-prefiksiä.
Käytä dokumentaatiota, joka vastaa DMVPN-vaihettasi, alustaasi ja julkaisuasi, ja muista, että yksi luku voi kattaa useita järjestelyjä, mukaan lukien FlexVPN. Yhden järjestelyn esimerkki ei siirry äänettömästi toiseen. Valitse istunnon päät ohjaustason ratkaisun mukaan, jota todella tarvitset, ja tarkista sitten asiakkaan välityspolku erikseen, sillä jokaisen loopback-maskin uudelleenkirjoittaminen ei korvaa sen selvittämistä, mikä työ epäonnistui.