Көршілестік жоқ, ал ортадағы маршрутизатор айқын күдікті болып көрінеді. Ол кінәсіз болуы мүмкін. Сыртқы туннель пакеттерін жіберу мен overlay маршруттау протоколына қатысу — екі бөлек жұмыс, және құрылғы екіншісінсіз біріншісін орындай алады. Төмендегі бес тексеруді ретімен орындап, бірінші сәтсіз аяқталғанында тоқтаңыз.

1-қадам: екі рөлді сызыңыз

Көзделген EIGRP көршілестігін екі маршрутизатор арасындағы логикалық байланыс ретінде сызыңыз, содан кейін оның туннель пакеттерін тасымалдайтын underlay маршрутизаторларын сызыңыз. Бір құрылғы екі тізімде де болуы міндетті емес, ал тізімдерді шатастыру — сау транзиттік маршрутизаторды көршілестікті бұзды деп айыптаудың ең көп тараған себебі.

Транзиттік маршрутизатор сыртқы пакеттерді әдеттегі IP маршруттауымен және саясатымен жібереді. Оған қорғалған туннель ішінде тасымалданатын протоколды іске қосу қажет емес, әрі бұл пакеттерді әрі қарай өткізу үшін EIGRP процесі де қажет емес.

2-қадам: ортадағы құрылғы нені аяқтайтынын тексеріңіз

Егер ортадағы маршрутизатор туннельді аяқтап, spoke-тармен EIGRP көршілестіктерін құруы тиіс болса, жауап мүлдем өзгереді. Ол құрылғыға қолдау көрсетілетін overlay маршруттау тәртібі қажет, ал оны транзит деп атау көрші талабын жоймайды. Маршруттау конфигурациясынан бұрын туннель конфигурациясын оқыңыз. Сол жауап келесі барлық тексерулерді айқындайды.

Сондықтан бірінші нақты сұрақ қай протоколды реттеу емес. Сұрақ — қорап hub па, spoke пе, таза underlay секірісі ме, әлде шеткі нүктелер арасында фреймдерді тасымалдайтын Layer 2 қызметі ме.

3-қадам: көршінің басқару жазықтығын тексеріңіз

Көрші болуы тиіс әрбір құрылғыда төрт нәрсені растаңыз: EIGRP данасы мен автономды жүйе нөмірі, аутентификация параметрлері, процеске қатысатын интерфейс және сол интерфейсті қамтитын желілік мәлімдеме. Олардың кез келгеніндегі сәйкессіздік интерфейс жоғары тұрып ping жалғаса бергенде көршілестікті төменде ұстайды.

RFC 7868 EIGRP-ні multicast басқару алмасуы бар IP протоколы ретінде сипаттайды, сондықтан көршілік қатынас — аралық маршрутизатор пакеттерді межелі орынға маршруттау арқылы алмастыра алатын нәрсе емес. Не басқару алмасуы серіктеске жетеді, не көршілестік қалыптаспайды.

4-қадам: көлік басқару алмасуын жеткізетінін тексеріңіз

Содан кейін, overlay көзделген шеткі нүктелер арасында басқару трафигін шынымен тасымалдайтынын тексеріңіз. Серіктестің NHRP бейнеленуін және оған жететін сыртқы маршрутты қарап, содан кейін туннель интерфейсінің жоғары екенін және трафикті өткізетінін растаңыз. Сәтті underlay ping сыртқы жолдың бар екенін дәлелдейді; ол overlay басқару алмасуының жеткізілгенін дәлелдемейді.

Мөлдір Layer 2 қызметі, нүктеден нүктеге туннель және көпнүктелі DMVPN бұлты multicast-ты әртүрлі жеткізеді. Үшеуі бірдей әрекет етеді деп болжаудың орнына нақты енгізілген шешімнің қолдау көрсетілетін интерфейс, NHRP және multicast үлгісін ұстаныңыз.

5-қадам: қатыса алмаса, шекараны қайта жобалаңыз

Егер қажетті overlay құрылғысы протоколды іске қоса алмаса, дизайнды анық өзгертіңіз. Сол шекарада қолдау көрсетілетін протоколды немесе алмасу үлгісін пайдаланыңыз, немесе көршілер бір-бірімен шынымен сөйлесетін шеткі нүктелер болуы үшін қолайлы ұшынан ұшына туннель ұйымдастырыңыз. Статикалық маршрут қатыспайтын құрылғыны әрбір басқару пакеті үшін релеге айналдырады деп болжамаңыз.

Диаграммада әрбір құрылғының рөлін жазып, оны конфигурациямен бірге сақтаңыз. RFC 7868 протокол алмасуын айқындайды, және сол анықтама көршілік қатынасты транзиттік жіберу арқылы имитациялауға болмайтынының негіздемесі.

Көршілестік бес тексеруден кейін де қалыптаспаса, қалған күдіктілер — платформа мүмкіндіктері, мысалы, туннель интерфейсіндегі multicast өңдеуі және 88 протоколын сүзетін саясат. Бұл нақты, тексеруге болатын себептер және ортадағы маршрутизаторды кінәлаудың тағы бір айналымынан қымбат.

Қатысты мақалалар