BGP munkamenet él, az ügyfél útvonala törött: MPLS DMVPN felett

A peering hetek óta él, az előtagok száma helyesnek látszik, és mégsem megy át egy ügyfél forgalma a rövid úton, vagy egyáltalán nem érkezik meg. Két különböző dolgot ugyanaz a jelző értékel. Egy BGP munkamenet azt jelenti, hogy két peer TCP-kapcsolaton keresztül tud üzeneteket váltani; arról semmit nem mond, hogy az overlay képes-e címkézett csomagot vinni éppen annak az ügyfélnek.

Ez a rés legkönnyebben MPLS-over-DMVPN felépítésben látható, ahol a hub útvonala és a közvetlen spoke útvonal más viselkedést mutathat olyan okokból, amelyeknek semmi közük a peeringhez.

Amit a munkamenet valójában bizonyít

A BGP TCP fölött fut, ezért minden peernek útvonalra van szüksége a másik végpont címéhez, mielőtt bármi más megtörténhet. Ha ezt a végpontot loopbacknek választja, elérhetőségi követelményt hozott létre, nem továbbítási garanciát. A munkamenet ezután olyan interfészen is fennmaradhat, amelyet az ügyfél forgalma soha nem használna.

Rögzítsen négy tényt mindkét végén, mielőtt következtetéseket von: a munkamenet forrás- és célcímét, azt az útválasztási környezetet, amelyben ül, és hogy a kernel vagy a router melyik interfészt választaná ehhez a párhoz. Ezek a tények a vezérlési síkot írják le. Az ügyfél csomagjai ezek fölé VRF-et, címkevermet és overlay-leképezést tesznek.

Négy mechanizmus, nem egy

A Cisco MPLS-over-DMVPN dokumentációja tisztán szétválasztja a részeket. Az MP-BGP osztja el az ügyfél overlay-címkéit a szolgáltató peremieszközei között. Az MPLS ezekkel a címkékkel választja ki egy csomag továbbítási környezetét. Az NHRP egy overlay-címet arra a transzportvégpontra képez le, amelyre egy dinamikus alagútnak szüksége van. Az IPsec pedig ott védi a peer útvonalát, ahol alkalmazható.

Bármelyik négy közül lehet helyes, miközben egy másik hibás, és a kombináció az, ami a forgalmat viszi. Az útvonalcsere befejeződhet úgy, hogy egy VRF címkekötése hiányzik, az NHRP-leképezés elavult transzportcímre mutat, vagy az alagút létezik, de egyetlen szabályzat sem engedi a belső csomagot. Egyik feltétel sem ejti el a munkamenetet.

Hasonlítsa össze a hub útvonalát a rövidítéssel, egyszerre egy változót

Rögzítse a forrásgazdát, a célgazdát és a VRF-et, majd kétszer kövesse ugyanazt a folyamot. A hub útvonalán jegyezze fel a következő ugrást, a távoli ügyfélkörnyezetet azonosító szolgáltatáscímkét és az éppen használt overlay-transzport leképezést. A tervezett közvetlen útvonalon ugyanezt a három dolgot jegyezze fel. A két lista közötti különbség a hiba, vagy annak hiánya.

Tartsa állandón a folyamot az összehasonlítás alatt. A forrásgazda, a VRF vagy a cél megváltoztatása a megfigyelések között két összefüggéstelen történetet ad, és ez a leggyakoribb módja annak, hogy ez a gyakorlat félremenjen.

Tartsa a loopback teszteket külön rekeszben

A router loopbackjéből küldött ping hasznos teszt, és más esetet gyakorol, mint egy gazdából induló folyam. A forráscím a routerhez tartozik, útválasztási környezete globális is lehet VRF helyett, és a válasz útvonala eltérhet attól, amelyet egy ügyfél-előtag venne. Ezért a válaszoló loopback és a rövidítésen működő alkalmazás külön eredmény, és csak a második írja le az ügyfelet.

Tesztelje mindkettőt, majd jelölje meg őket külön a jegyzeteiben. Amikor nem egyeznek, valami konkrétat megtudott arról, hol tér el a felépítés, és ez több annál, mint amit egyetlen zöld pipa valaha mondani fog.

A verzió- és hibaállításoknak saját bizonyíték kell

A terepi jelentések néha a gazdamask vagy a BGP forráscím módosítását javasolják, és az ilyen jelentéseket csak a hiba mellett érdemes olvasni, amelyről íródtak, valamint az érintett kiadásokkal együtt. Egy kiadás kerülőmegoldása nem állítás arról, hogy az architektúra egyetlen /32 előtagot sem támogat.

Olyan dokumentációt használjon, amely megfelel a DMVPN-fázisának, platformjának és kiadásának, és ne feledje, hogy egy fejezet több elrendezést is lefedhet, köztük a FlexVPN-t. Az egyik elrendezés példája nem megy át csendben a másikba. A munkamenet végpontjait a valóban szükséges vezérlési sík felépítéséhez válassza, majd külön ellenőrizze az ügyfél továbbítási útvonalát, mert minden loopback-mask újraírása nem helyettesíti annak kiderítését, melyik feladat bukott el.