EIGRP съседите не се вдигат върху DMVPN овърлей

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

Тунелът е вдигнат, един клон може да пингова друг, а EIGRP все още не показва съсед на хъба. Тази комбинация е нормална, а не загадъчна: ping доказва unicast достижимост през NHRP, а hello съобщенията на EIGRP са multicast. В DMVPN овърлей моделът на доставяне на рутиращия протокол е втора конфигурационна повърхност и точно нея хората прескачат, защото първата вече изглежда здрава. Всеки слой по-долу се проверява със своя команда, така че отказ в един слой не ви връща в началото на списъка.

Запишете съседствата, които очаквате

Преди която и да е show команда направете кратък списък: кой клон с кой хъб трябва да се съседства, през кой тунелен интерфейс и в коя автономна система на EIGRP. Дизайните с много хъбове се провалят в пропуските между хъбовете, а списъкът превръща «EIGRP е счупен» в «клон 3 не се регистрира при хъб 2». Включете тунелните подмрежи, които очаквате на всяка връзка, защото несъответствие в адресите между двата края изглежда точно като протоколен отказ. Запишете списъка в тикета, за да сравнява следващата смяна с дизайна, а не с последната екранна снимка.

Проверете NHRP, после multicast пътя

Започнете със състоянието на регистрация и mappings, които хъбът наистина държи. Клон без динамичен запис на хъба не се е регистрирал и никой рутиращ протокол няма да поправи това. След това потвърдете, че клонът приема multicast от 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 редът позволява на клона да изпраща своите hello съобщения към хъба като репликиран multicast през овърлея и позволява multicast на хъба да достига до регистрираните клонове. Без него unicast през NHRP работи, а multicast не, и точно това разделение прави ping да изглежда като доказателство. Ръководството на Cisco IOS XE DMVPN описва 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 профила на тунела, security associations за всеки peer и състоянието на тунелния интерфейс като три отделни факта.

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

SA, която е вдигната и броячите ѝ се движат, докато EIGRP остава долу, връща разследването ви по-нагоре в стека: пакетите се защитават и доставят, значи проблемът е кои пакети протоколът избира да изпраща.

Проверявайте маршрутите, не само броя на съседите

Щом съседството се оформи, прочетете какво обявява и инсталира. На многоточков тунел split horizon и поведението на следващия хоп решават дали клон може да достигне друг клон през хъба, а сумирането може да скрие префикс, дори когато съседството е безупречно.

Завършете с разрешено приложение между два сайта и потвърдете пътя, който то поема. Директните преки пътища клон-клон са изискване за препращане със собствено NHRP и security състояние и добавянето им, за да изглежда броят на съседите по-добър, обикновено създава втори проблем.

Запишете фазовия дизайн, multicast mapping-а и EIGRP политиката на едно място. Следващият инженер ще има нужда от дизайна, не от стенограмата.

Подобни статии