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-а и multicasta за оно што је стварно имплементирано, уместо да претпоставите да се сва три понашају исто.

Корак 5: редизајнирајте границу ако не може да учествује

Ако потребни overlay уређај не може да покреће протокол, промените дизајн изричито. Употребите подржани протокол или модел размене на тој граници или уредите одговарајући end-to-end тунел тако да суседи буду крајње тачке које стварно разговарају једна с другом. Не претпостављајте да статичка рута претвара неучесника у релеј за сваки контролни пакет.

Забележите улогу сваког уређаја на дијаграму и чувајте је уз конфигурацију. RFC 7868 дефинише протоколну размену, а та дефиниција је референца за то зашто се суседски однос не може симулирати транзитним прослеђивањем.

Када суседство и даље не успева након свих пет провера, преостали осумњичени су карактеристике платформе попут обраде multicasta на интерфејсу тунела и политике која филтрира протокол 88. То су конкретни узроци који се могу тестирати и вреде више од још једне рунде окривљавања рутера у средини.