EIGRP հարևան, թե՞ DMVPN տրանզիտ։ Նախ ստուգեք դերը

Հարևանությունը բացակայում է, և մեջտեղի երթուղիչը թվում է ակնհայտ կասկածյալ։ Նա կարող է անմեղ լինել։ Թունելի արտաքին փաթեթները փոխանցելը և overlay երթուղավորման արձանագրությանը մասնակցելը երկու տարբեր աշխատանք են, և սարքը կարող է անել առաջինը՝ չանելով երկրորդը։ Անցեք ստորև նշված հինգ ստուգումները հերթականությամբ և կանգ առեք առաջին ձախողվածի վրա։

Քայլ 1. գծեք երկու դերերը

Գծեք նախատեսված EIGRP հարևանությունը որպես երկու երթուղիչների միջև տրամաբանական կապ, ապա գծեք underlay երթուղիչները, որոնք կրում են նրա թունելի փաթեթները։ Նույն սարքը պարտադիր չէ, որ լինի երկու ցանկերում էլ, և ցանկերը շփոթելը ամենատարածված պատճառն է, թե ինչու առողջ տրանզիտ երթուղիչին մեղադրում են հարևանությունը կոտրելու մեջ։

Տրանզիտ երթուղիչը փոխանցում է արտաքին փաթեթները իր սովորական IP երթուղավորմամբ և քաղաքականությամբ։ Նրան պետք չէ գործարկել պաշտպանված թունելի ներսում կրարվող արձանագրությունը, և այդ փաթեթները առաջ փոխանցելու համար EIGRP գործընթաց պետք չէ։

Քայլ 2. ստուգեք, թե ինչ է ավարտում մեջտեղի սարքը

Եթե մեջտեղի երթուղիչը ավարտում է թունելը և պետք է EIGRP հարևանություններ կազմի spoke-ների հետ, պատասխանը լիովին փոխվում է։ Այդ սարքին անհրաժեշտ է աջակցվող overlay երթուղավորման վարքագիծ, և այն տրանզիտ անվանելը չի վերացնում հարևանի պահանջը։ Կարդացեք թունելի կազմաձևը երթուղավորման կազմաձևից առաջ։ Այդ պատասխանը որոշում է բոլոր հաջորդ ստուգումները։

Այսպիսով, առաջին իրական հարցը ոչ թե որ արձանագրությունը կարգավորելն է։ Հարցն այն է՝ արդյոք տուփը hub է, spoke, մաքուր underlay թռիչք, թե Layer 2 ծառայություն, որը կադրեր է կրում վերջնակետերի միջև։

Քայլ 3. ստուգեք հարևանի կառավարման հարթությունը

Յուրաքանչյուր սարքում, որը պետք է հարևան լինի, հաստատեք չորս բան՝ EIGRP օրինակը և ինքնավար համակարգի համարը, նույնականացման պարամետրերը, գործընթացին մասնակցող ինտերֆեյսը և այդ ինտերֆեյսը ծածկող ցանցային հայտարարությունը։ Դրանցից որևէ մեկում անհամապատասխանությունը հարևանությունը պահում է ներքևում, մինչ ինտերֆեյսը մնում է վերևում, և ping-ը շարունակում է աշխատել։

RFC 7868-ը EIGRP-ն նկարագրում է որպես IP արձանագրություն՝ multicast կառավարման փոխանակմամբ, այդ պատճառով հարևանային հարաբերությունը այնպիսի բան չէ, որը միջանկյալ երթուղիչը կարող է փոխարինել՝ փաթեթները դեպի նպատակակետ երթուղավորելով։ Կամ կառավարման փոխանակումը հասնում է զուգընկերոջը, կամ հարևանությունը չի ձևավորվում։

Քայլ 4. ստուգեք, որ տրանսպորտը հասցնում է կառավարման փոխանակումը

Այնուհետև՝ ստուգեք, որ overlay-ը իսկապես կրում է կառավարման երթևեկությունը նախատեսված վերջնակետերի միջև։ Ստուգեք զուգընկերոջ NHRP քարտեզագրումը և դրան հասնող արտաքին երթուղին, ապա հաստատեք, որ թունելի ինտերֆեյսը վերևում է և անցկացնում է երթևեկություն։ Հաջող underlay ping-ը ապացուցում է, որ արտաքին ուղին գոյություն ունի, բայց չի ապացուցում, որ overlay-ի կառավարման փոխանակումը հասցվել է։

Թափանցիկ Layer 2 ծառայությունը, կետ-կետ թունելը և բազմակետ DMVPN ամպը multicast-ը հասցնում են տարբեր ձևերով։ Հետևեք փաստացի տեղակայված լուծման աջակցվող ինտերֆեյսի, NHRP-ի և multicast-ի մոդելին՝ փոխարենը չենթադրելով, որ բոլոր երեքը նույն կերպ են վարվում։

Քայլ 5. վերանախագծեք սահմանը, եթե այն չի կարող մասնակցել

Եթե պահանջվող overlay սարքը չի կարող գործարկել արձանագրությունը, փոխեք նախագիծը բացահայտորեն։ Այդ սահմանին օգտագործեք աջակցվող արձանագրություն կամ փոխանակման մոդել, կամ կազմակերպեք համապատասխան ծայրից ծայր թունել, որպեսզի հարևանները լինեն այն վերջնակետերը, որոնք իրականում խոսում են միմյանց հետ։ Մի ենթադրեք, որ ստատիկ երթուղին չմասնակցողին վերածում է յուրաքանչյուր կառավարման փաթեթի համար ռելեի։

Գծապատկերում գրանցեք յուրաքանչյուր սարքի դերը և պահեք այն կազմաձևի հետ։ RFC 7868 սահմանում է արձանագրության փոխանակումը, և այդ սահմանումն է հղումը, թե ինչու հարևանային հարաբերությունը հնարավոր չէ նմանակել տրանզիտ երթուղավորմամբ։

Երբ հարևանությունը դեռ չի ձևավորվում բոլոր հինգ ստուգումներից հետո, մնացած կասկածյալները պլատֆորմի առանձնահատկություններն են, ինչպիսիք են թունելի ինտերֆեյսում multicast-ի մշակումը և 88 արձանագրությունը զտող քաղաքականությունը։ Դրանք կոնկրետ, ստուգելի պատճառներ են և արժեն ավելին, քան մեջտեղի երթուղիչին մեղադրելու ևս մեկ փուլը։