EIGRP հարևանները չեն բարձրանում DMVPN վերածածկույթում

Թունելը վերևում է, մի spoke կարող է ping անել մյուսին, և EIGRP-ը դեռ hub-ի վրա ոչ մի հարևան չի ցուցադրում։ Այս համակցությունը նորմալ է, ոչ առեղծվածային. ping-ը ապացուցում է unicast հասանելիությունը NHRP-ի միջոցով, իսկ EIGRP-ի hello-ները multicast են։ DMVPN վերածածկույթում երթուղավորման արձանագրության առաքման մոդելը երկրորդ կոնֆիգուրացիոն մակերևույթն է, և հենց այն են մարդիկ բաց թողնում, որովհետև առաջին մակերևույթն արդեն առողջ է երևում։ Ստորև յուրաքանչյուր շերտ ստուգվում է իր հրամանով, ուստի մի շերտի ձախողումը ձեզ չի վերադարձնում ցանկի սկիզբ։

Գրեք այն հարևանությունները, որոնք սպասում եք

Ցանկացած show հրամանից առաջ կարճ ցանկ կազմեք. ո՞ր spoke-ը որ hub-ի հետ պետք է peer լինի, որ թունելային ինտերֆեյսով և որ EIGRP ինքնավար համակարգում։ Բազմահաբ դիզայնները ձախողվում են hub-ների միջև եղած բացերում, և ցանկը «EIGRP-ը կոտրված է» արտահայտությունը վերածում է «spoke 3-ը չի գրանցվում hub 2-ում»-ի։ Ներառեք թունելային ենթացանցերը, որոնք սպասում եք յուրաքանչյուր կապում, որովհետև երկու ծայրերի միջև հասցեների անհամապատասխանությունը ճիշտ արձանագրության ձախողման տեսք ունի։ Ցանկը գրեք տոմսի վրա, որպեսզի հաջորդ հերթափոխը համեմատի դիզայնի հետ, ոչ վերջին էկրանի պատկերի։

Ստուգեք NHRP-ը, ապա multicast ուղին

Սկսեք գրանցման վիճակից և այն քարտեզագրումներից, որոնք hub-ը իրապես պահում է։ Այն spoke-ը, որ hub-ի վրա դինամիկ գրառում չունի, գրանցված չէ, և ոչ մի երթուղավորման արձանագրություն դա չի ուղղի։ Այնուհետև հաստատեք, որ spoke-ը multicast ընդունում է hub-ի NBMA հասցեից, ինչը առանձին տող է NHS գրառումից։

show dmvpn
show ip nhrp
show ip nhrp nhs detail
interface Tunnel0
 ip nhrp network-id 1
 ip nhrp nhs 203.0.113.1 nbma 198.51.100.1
 ip nhrp map multicast 198.51.100.1
 tunnel mode gre multipoint
 tunnel key 100

Հենց ip nhrp map multicast տողն է, որ թույլ է տալիս spoke-ին իր hello-ները hub-ին ուղարկել որպես կրկնօրինակված multicast վերածածկույթով, և որը թույլ է տալիս hub-ի multicast-ին հասնել գրանցված spoke-ներին։ Առանց դրա unicast-ը NHRP-ով աշխատում է, իսկ multicast-ը՝ ոչ, և հենց այդ բաժանումն է ping-ը ապացույցի տեսք տալիս։ Cisco-ի ուղեցույցը IOS XE DMVPN փաստաթղթավորում է hub-ի և spoke-ների multicast վարքը յուրաքանչյուր փուլի համար, ուստի ձեր կոնֆիգուրացիան համապատասխանեցրեք այն փուլին, որը իրականում տեղադրել եք, այլ ոչ թե այլ տոպոլոգիայից հատված պատճենեք։

Ստուգեք EIGRP-ի սեփական ինտերֆեյսի քաղաքականությունը

Թունելը, որը EIGRP գործընթացում չէ կամ passive է, երբեք հարևանություն չի ձևավորի, որքան էլ վերածածկույթը առողջ լինի։ Ինտերֆեյսի մասնակցությունը և հարևանների աղյուսակը կարդացեք միասին, որովհետև առաջինը բացատրում է երկրորդը։

show ip eigrp interfaces detail Tunnel0
show ip eigrp neighbors detail
show run | section router eigrp
router eigrp 100
 network 10.10.0.0 0.0.0.255
 passive-interface default
 no passive-interface Tunnel0

Նույնականացումը և մետրիկայի կշիռները պետք է համընկնեն երկու ծայրերում։ Սխալ ռեժիմով բանալիների շղթան կամ K արժեքի անհամապատասխանությունը գցում է hello-ները՝ առանց ստացողի մոտ ակնհայտ syslog տողի։ Եթե դիզայնը օգտագործում է հստակ կարգավորված unicast հարևաններ, ամբողջությամբ հետևեք այդ մոդելին՝ multicast կարգավորումների վրա շերտավորելու փոխարեն, մինչև ինչ-որ բան բարձրանա։

GRE փոխադրումը և IPsec պաշտպանությունը առանձին պահեք

DMVPN-ը multicast-ը փոխադրում է GRE-ի ներսում, իսկ IPsec-ը պաշտպանում է GRE փաթեթները, ոչ թե ներքին multicast-ը ուղղակիորեն։ Դրա համար էլ այն ընդհանուր պնդումը, թե IPsec-ը չի կարող multicast փոխադրել, այս դիզայնի համար սխալ է և որպես ախտորոշում՝ անօգուտ։ Ստուգեք թունելի IPsec պրոֆիլը, յուրաքանչյուր peer-ի անվտանգության ասոցիացիաները և թունելային ինտերֆեյսի վիճակը որպես երեք առանձին փաստ։

show crypto ipsec sa peer 198.51.100.1
show interfaces Tunnel0 | include line protocol
show ip nhrp multicast

Վերևում գտնվող և հաշվիչները շարժվող SA-ն, մինչ EIGRP-ը ներքևում է մնում, ձեր հետաքննությունը հետ է տանում դեպի ստեկի գագաթը. փաթեթները պաշտպանվում և առաքվում են, ուստի խնդիրն այն է, թե որ փաթեթներն է արձանագրությունն ընտրում ուղարկել։

Ստուգեք երթուղիները, ոչ միայն հարևանների քանակը

Հենց հարևանությունը ձևավորվի, կարդացեք, թե ինչ է այն հայտարարում և տեղադրում։ Բազմակետ թունելում split horizon-ը և next-hop վարքը որոշում են՝ spoke-ը կարո՞ղ է hub-ի միջով հասնել մեկ այլ spoke-ի, և ամփոփումը կարող է թաքցնել prefix նույնիսկ երբ հարևանային հարաբերությունը կատարյալ է։

Ավարտեք երկու կայքերի միջև թույլատրված հավելվածով և հաստատեք այն ուղին, որով այն անցնում է։ Ուղիղ spoke-to-spoke կարճուղիները փոխանցման պահանջ են՝ իրենց NHRP և անվտանգության վիճակով, և դրանք ավելացնելը, որպեսզի հարևանների քանակը ավելի լավ երևա, սովորաբար ստեղծում է երկրորդ խնդիր։

Գրանցեք փուլային դիզայնը, multicast քարտեզագրումը և EIGRP քաղաքականությունը մեկ տեղում։ Հաջորդ ինժեներին պետք կգա դիզայնը, ոչ սղագրությունը։