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

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

Ако потребен overlay уред не може да го извршува протоколот, сменете го дизајнот експлицитно. Користете поддржан протокол или модел на размена на таа граница, или обезбедете соодветен тунел од крај до крај за да бидат соседите крајните точки што навистина разговараат меѓу себе. Не претпоставувајте дека статична рута го претвора неучесникот во реле за секој контролен пакет.

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

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