EIGRP коңшусубу же DMVPN транзитиби? Адегенде ролду текшериңиз

Коңшулук жок, ал эми ортодогу маршрутизатор ачык шектүү болуп көрүнөт. Ал күнөөсүз болушу мүмкүн. Сырткы туннелдик пакеттерди өткөрүп берүү жана 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 протоколун чыпкалаган саясат. Булар конкреттүү, текшерүүгө боло турган себептер жана ортодогу маршрутизаторду күнөөлөөнүн дагы бир айлампасынан кымбат.