Супсед EIGRP ці транзіт DMVPN? Спачатку праверце ролю

Суседства няма, і маршрутызатар пасярэдзіне выглядае відавочным падазроным. Магчыма, ён невінаваты. Перасылка знешніх пакетаў тунеля і ўдзел у пратаколе маршрутызацыі overlay — дзве розныя задачы, і прылада можа выконваць першую, не выконваючы другую. Прайдзіце пяць праверак ніжэй па парадку і спыніцеся на першай, якая не пройдзе.

Крок 1: намалюйце дзве ролі

Намалюйце меркаванае суседства EIGRP як лагічнае злучэнне паміж двума маршрутызатарамі, затым намалюйце маршрутызатары underlay, якія пераносяць яго пакеты тунеля. Адна і тая ж прылада не абавязана з’яўляцца ў абодвух спісах, і блытаніна ў спісах — самая частая прычына, чаму спраўны транзітны маршрутызатар абвінавачваюць у паломцы суседства.

Транзітны маршрутызатар перасылае знешнія пакеты звычайнай IP-маршрутызацыяй і палітыкай. Яму не трэба запускаць пратакол, які пераносіцца ўнутры абароненага тунеля, і не трэба працэс EIGRP, каб перадаваць гэтыя пакеты далей.

Крок 2: праверце, што завяршае сярэдняя прылада

Калі сярэдні маршрутызатар завяршае тунель і павінен утвараць суседствы EIGRP са spoke, адказ цалкам змяняецца. Гэтай прыладзе патрэбны падтрыманыя паводзіны маршрутызацыі overlay, і назва «транзіт» не знімае патрабаванне да суседа. Чытайце канфігурацыю тунеля раней за канфігурацыю маршрутызацыі. Гэты адказ вызначае ўсе наступныя праверкі.

Такім чынам, першае сапраўднае пытанне — не які пратакол наладжваць. Пытанне ў тым, ці скрыня — гэта hub, spoke, чысты хоп underlay або служба Layer 2, якая пераносіць кадры паміж канчатковымі пунктамі.

Крок 3: праверце плоскасць кіравання суседа

На кожнай прыладзе, якая павінна быць суседам, пацвердзіце чатыры рэчы: асобнік EIGRP і нумар аўтаномнай сістэмы, параметры аўтэнтыфікацыі, інтэрфейс, які ўдзельнічае ў працэсе, і сеткавы аператар, які ахоплівае гэты інтэрфейс. Неадпаведнасць у любым з іх трымае суседства выключаным, пакуль інтэрфейс застаецца ўключаным і ping працягвае працаваць.

RFC 7868 апісвае EIGRP як IP-пратакол з мультыкаставым абменам кіравання, таму суседскія адносіны — не тое, што прамежкавы маршрутызатар можа праксіраваць, накіроўваючы пакеты да пункта прызначэння. Альбо абмен кіравання дасягае партнёра, альбо суседства не ўзнікае.

Крок 4: праверце, што транспарт дастаўляе абмен кіравання

Далей, праверце, што overlay сапраўды пераносіць кіраўнічы трафік паміж меркаванымі канчатковымі пунктамі. Агледзьце адлюстраванне NHRP для партнёра і знешні маршрут, што да яго вядзе, затым пацвердзіце, што інтэрфейс тунеля ўключаны і прапускае трафік. Паспяховы ping underlay даказвае, што знешні шлях існуе; ён не даказвае, што абмен кіравання overlay быў дастаўлены.

Празрыстая служба Layer 2, тунель пункт-пункт і шматпунктавы воблак DMVPN дастаўляюць мультыкаст па-рознаму. Ідзіце за падтрыманымі мадэлямі інтэрфейса, NHRP і мультыкаста для таго, што рэальна разгорнута, а не дапушчайце, што ўсе тры паводзяць сябе аднолькава.

Крок 5: перапраектуйце мяжу, калі яна не можа ўдзельнічаць

Калі патрэбная прылада overlay не можа запускаць пратакол, змяніце праект відавочна. Выкарыстайце падтрыманы пратакол або мадэль абмену на гэтай мяжы або арганізуйце прыдатны тунель ад канца да канца, каб суседзі былі канчатковымі пунктамі, якія сапраўды размаўляюць адзін з адным. Не дапушчайце, што статычны маршрут робіць неўдзельніка рэтранслятарам для кожнага кіраўнічага пакета.

Запішыце ролю кожнай прылады на схеме і захоўвайце яе разам з канфігурацыяй. RFC 7868 — вызначэнне пратакольнага абмену і ёсць той аргумент, чаму суседскія адносіны нельга імітаваць транзітнай маршрутызацыяй.

Калі суседства ўсё яшчэ не ўзнікае пасля ўсіх пяці праверак, астатнія падазроныя — гэта магчымасці платформы, такія як апрацоўка мультыкаста на інтэрфейсе тунеля і палітыка, якая фільтруе пратакол 88. Гэта канкрэтныя прычыны, якія можна праверыць, і яны каштуюць больш, чым чарговы круг абвінавачванняў маршрутызатара пасярэдзіне.