DMVPN фаза 3: читање пречице у оба смера

Посматрате како један ping иде од spoke-а до spoke-а дугим путем кроз hub, а други иде директно. Примамљиво је у том тренутку прогласити пречицу исправном. Тај закључак је напола тачан. Пут напред може бити пречица док пут назад још иде кроз hub, а стање које доказује сваки смер је различито стање. Прођите оба смера и прочитајте три табеле пре него што дизајн прихватите као здрав.

Почните с путањом пакета коју заиста можете видети

Почните на spoke-у с одредиштем које би требало бити директно. Пратите први пакет: он следи руту spoke-а према hub-у, јер пречица још не постоји. Hub га прослеђује и, у дизајну фазе 3, такође шаље преусмерење извору с поруком да постоји бољи пут.

То преусмерење је окидач, а не доказ. Оно каже да је hub видео саобраћај који се може оптимизовати. Не каже да је извор изградио пречицу, да је одредиште одговорило на резолуцију или да га пут одговора користи.

Зато је прво корисно запажање пре и после: први ток кроз hub, каснији ток директно.

Три стања која изгледају као један тунел

Пречица зависи од три дела стања, а сваки има свој век трајања и своју команду.

Унос у NHRP кешу пресликава overlay адресу у NBMA транспортну адресу. Рута или пречица одлучује куда се прослеђује једно унутрашње одредиште. IPsec асоцијација штити саобраћај који из тога настане. Одговор који недостаје може доћи из било ког од три дела, а команде вам говоре који недостаје.

Читајте их тим редом, јер пресликавање које недостаје чини друга два незанимљивима.

Прођите захтев и одговор одвојено

Са spoke-а A затражите резолуцију и гледајте шта се враћа. Захтев иде подржаним NHRP путем прослеђивања, а одредиште може одговорити директно уместо кроз hub. Та асиметрија је нормална и зато је одговор занимљива половина размене.

Сада замените улоге. Пошаљите са B на A и поновите иста три читања. Дизајн који прави пречицу у једном смеру, а у другом не, није симетричан, а асиметрија обично долази од префикса који недостаје на једној страни или од резолуције која никада није добила одговор.

Одговор партнера не мора проћи кроз hub само зато што је захтев прошао. Не читајте то као грешку и не почињите да ловите рутиншку грешку која не постоји.

Читајте hub-ово преусмерење, не само његову руту

Hub-ова табела рута вам каже куда би hub послао пакет. Преусмерење вам каже шта је hub тражио од извора да уради у вези с тим. То су различите чињенице, а hub с исправном рутом и без преусмерења држаће сваки ток на дугом путу неограничено. Проверите NHRP догађаје на hub-у и потврдите да се преусмерења генеришу за саобраћај који вас занима.

Фаза 3 мења и шта значи сумаризација. Уз понашање пречице, spoke-овима не треба цео скуп конкретних удаљених рута које је дизајн фазе 2 очекивао, па сумирана рута на spoke-у није аутоматски мрежа која недостаје. Потврдите фазу и рутиншку политику пре него што сумаризацију прочитате као квар.

Тај један неспоразум ствара више DMVPN тикета него било шта друго.

Запишите закључак као објекат који недостаје

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

Рутиншко суседство и заједничка безбедносна асоцијација доказ су здравља, а не доказ путање. Оба могу бити савршена док сваки пакет ипак иде около дугим путем. Прво проверите одлуку о прослеђивању, а затим асоцијацију која је носи. Редослед је важан, јер асоцијација настаје у сваком случају.

Та навика се исплати на следећем тикету. „Тунел је подигнут али спор“ постаје „B нема пречицу до A-овог хоста“, а друга тврдња је поправка за пет минута. Чувајте излаз команди уз закључак и држите добављачев водич за фазу 3 поред њега.