BGP sesija darbojas, klienta ceļš salauzts: MPLS virs DMVPN

Peering darbojas jau nedēļām, prefiksu skaits izskatās pareizs, un tomēr viena klienta trafiks joprojām iet garo ceļu vai nemaz neierodas. Viens un tas pats rādītājs vērtē divas dažādas lietas. BGP sesija ziņo, ka divi peers var apmainīties ar ziņojumiem TCP savienojumā; tā neko nepasaka par to, vai pārklājums spēj pārvadāt marķētu pakešu tieši šim klientam.

Šo plaisu visvieglāk saskatīt MPLS virs DMVPN arhitektūrā, kur ceļš caur hub un tiešais spoke ceļš var uzvesties atšķirīgi tādu iemeslu dēļ, kuriem nav nekāda sakara ar peering.

Ko sesija patiešām pierāda

BGP darbojas virs TCP, tāpēc katram peeram vajag maršrutu uz otra gala adresi, pirms var notikt jebkas cits. Ja par šo galu izvēlaties loopback, jūs esat izveidojis sasniedzamības prasību, nevis pārsūtīšanas garantiju. Pēc tam sesija var palikt aktīva caur saskarni, kuru klienta trafiks nekad neizmantotu.

Pirms secinājumiem pierakstiet četrus faktus abos galos: sesijas avota adresi, galamērķa adresi, maršrutēšanas kontekstu, kurā tā atrodas, un to, kuru saskarni kodols vai maršrutētājs izvēlētos šim pārim. Šie fakti raksturo vadības plakni. Klienta paketes tiem virsū pievieno VRF, etiķešu steku un pārklājuma kartējumu.

Četri mehānismi, nevis viens

Cisco dokumentācija par MPLS virs DMVPN skaidri sadala daļas. MP-BGP izplata klienta pārklājuma etiķetes starp pakalpojumu sniedzēja malas ierīcēm. MPLS izmanto šīs etiķetes, lai izvēlētos paketes pārsūtīšanas kontekstu. NHRP kartē pārklājuma adresi uz transporta galu, kas vajadzīgs dinamiskam tunelim. IPsec aizsargā peera ceļu tur, kur tas attiecas.

Jebkurš no četriem var būt pareizs, kamēr cits ir nepareizs, un tieši kombinācija pārvadā trafiku. Maršrutu apmaiņa var noslēgties, kamēr trūkst vienas VRF etiķetes piesaistes, kamēr NHRP kartējums norāda uz novecojušu transporta adresi vai kamēr tunelis pastāv, bet neviena politika neļauj iekšējo pakešu. Neviens no šiem nosacījumiem nenomet sesiju.

Salīdziniet ceļu caur hub ar saīsni, pa vienam mainīgajam

Nofiksējiet avota hostu, galamērķa hostu un VRF, tad divreiz izsekojiet to pašu plūsmu. Ceļā caur hub pierakstiet nākamo lēcienu, pakalpojuma etiķeti, kas identificē attālo klienta kontekstu, un izmantoto pārklājuma-uz-transportu kartējumu. Paredzētajā tiešajā ceļā pierakstiet tās pašas trīs lietas. Atšķirība starp abiem sarakstiem ir kļūme vai tās neesamība.

Salīdzināšanas laikā turiet plūsmu nemainīgu. Avota hosta, VRF vai galamērķa maiņa starp novērojumiem rada divus nesaistītus stāstus, un tas ir visbiežākais veids, kā šis vingrinājums neizdodas.

Loopback testus turiet atsevišķā nodalījumā

Ping no maršrutētāja loopback ir noderīgs tests, un tas pārbauda citādu gadījumu nekā plūsma no hosta. Avota adrese pieder maršrutētājam, tā maršrutēšanas konteksts var būt globāls, nevis VRF, un atbildes ceļš var atšķirties no tā, kuru ietu klienta prefikss. Tāpēc atbildošais loopback un lietojumprogramma, kas strādā pa saīsni, ir atsevišķi rezultāti, un tikai otrais raksturo klientu.

Pārbaudiet abus, tad atzīmējiet tos atsevišķi savās piezīmēs. Kad tie nesakrīt, jūs uzzinājāt kaut ko konkrētu par to, kur arhitektūra novirzās, un tas ir vairāk, nekā jebkad pateiks viena zaļa atzīme.

Versijas un defekta apgalvojumiem vajag savus pierādījumus

Lauka ziņojumi dažkārt iesaka mainīt hosta masku vai BGP avota adresi, un šādus ziņojumus ir vērts lasīt tikai kopā ar defektu, par kuru tie rakstīti, un laidieniem, kurus tas skāra. Viena laidiena apiešanas risinājums nav apgalvojums, ka arhitektūra neatbalsta nevienu /32 prefiksu.

Izmantojiet dokumentāciju, kas atbilst jūsu DMVPN fāzei, platformai un laidienam, un atcerieties, ka viena nodaļa var aptvert vairākas konfigurācijas, tostarp FlexVPN. Vienas konfigurācijas piemērs klusi nepāriet citā. Izvēlieties sesijas galus tās vadības plaknes arhitektūras vajadzībām, kas jums patiešām vajadzīga, un pēc tam atsevišķi pārbaudiet klienta pārsūtīšanas ceļu, jo katras loopback maskas pārrakstīšana neaizstāj noskaidrošanu, kurš uzdevums neizdevās.