EIGRP соседите не се креваат на DMVPN слојот

Unicast низ слојот работи, а соседството сепак паѓа, затоа проверете ја NHRP multicast репликацијата, EIGRP политиката на тунелот и IPsec како три одделни слоја.

Тунелот е кренат, еден spoke може да пингува друг, а EIGRP сепак не покажува ниту еден сосед на hub-от. Таа комбинација е нормална, а не мистериозна: ping докажува unicast достапност преку NHRP, а EIGRP hello пораките се multicast. На DMVPN слој, моделот на доставување на протоколот за рутирање е втора конфигурациска површина и токму неа луѓето ја прескокнуваат затоа што првата површина веќе изгледа здрава. Секој слој подолу се проверува со своја команда, така што неуспех на еден не ве враќа на почетокот од списокот.

Запишете ги соседствата што ги очекувате

Пред која било show команда направете краток список: кој spoke со кој hub треба да се поврзе, преку кое тунелско интерфејс и во кој автономен систем на EIGRP. Дизајните со повеќе hub-ови паѓаат во празнините меѓу hub-овите, а списокот го претвора „EIGRP е расипан“ во „spoke 3 не се регистрира на hub 2“. Вклучете ги тунелските подмрежи што ги очекувате на секоја врска, зашто несовпаѓањето на адресите меѓу двата краја изгледа точно како протоколен неуспех. Запишете го списокот на тикетот, за да споредува следната смена со дизајнот, а не со последната слика од екранот.

Проверете NHRP, потоа multicast патеката

Почнете со состојбата на регистрација и мапирањата што hub-от навистина ги држи. Spoke без динамичен запис на hub-от не е регистриран и ниту еден протокол за рутирање тоа нема да го поправи. Потоа потврдете дека spoke-от прима multicast од NBMA адресата на hub-от, што е одделен ред од записот 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 преку слојот и му овозможува на multicast-от на hub-от да стигне до регистрираните spoke-ови. Без него unicast преку NHRP работи, а multicast не, и токму таа поделба го прави ping да изгледа како доказ. Водичот на Cisco IOS XE DMVPN го документира однесувањето на multicast-от кај hub-от и spoke-овите за секоја фаза, затоа усогласете ја конфигурацијата со фазата што навистина сте ја распоредиле, наместо да копирате фрагмент од друга топологија.

Проверете ја сопствената интерфејс политика на 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 може да стигне до друг spoke преку hub-от, а сумирањето може да скрие префикс дури и кога соседската врска е совршена.

Завршете со дозволена апликација меѓу две локации и потврдете ја патеката што ја зазема. Директните spoke-to-spoke кратенки се барање за препраќање со сопствена NHRP и безбедносна состојба, а нивното додавање за бројот на соседи да изгледа подобар обично создава втор проблем.

Запишете го фазниот дизајн, multicast мапирањето и EIGRP политиката на едно место. Следниот инженер ќе му треба дизајнот, не транскриптот.

Поврзани статии