Обобщение на маршрути в DMVPN срещу карта за обобщение NHRP: различни таблици
Обобщението на маршрути променя обявения префикс и следващия хоп. Картата за обобщение NHRP променя това, което връща отговорът за резолюция. Същата дума, различна таблица.
Някой ви моли да обобщите spoke-овете и тикетът се затваря с по-малко префикси на hub-а. Седмица по-късно трафикът между клоновете, който преди минаваше директно, отново минава през hub-а и никой не свързва двете промени. Изразът „обобщи spoke-овете“ покрива две различни операции, които засягат две различни таблици. Назовете кое състояние намалявате, преди да вземете команда от друг пример за DMVPN.
Симптомът: директният трафик между spoke-ове се върна към hub-а
Разликата е най-важна, когато обсъждане за Phase 2 се приложи към дизайн за Phase 3. Едни и същи думи се появяват и в двата разговора, а ефектът върху препращането не е еднакъв.
Затова и промяната изглеждаше правилна при прегледа: прегледът провери таблицата за маршрутизация, а тя е само едно от трите участващи състояния.
Едно обобщение, две таблици
Двете операции изглеждат така:
| Operation | What it actually changes |
|---|---|
| Routing summary | Aggregates the prefixes the routing protocol advertises and changes the next hop the receiver installs |
| NHRP summary map | Changes the network returned in a resolution reply, so a requesting spoke resolves to a different address |
| Protection path | IPsec state for the peer you actually resolved; neither aggregation changes it |
Обобщението на маршрути е твърдение за това какво обявява hub-ът и какво получаващият spoke инсталира като маршрут. Картата за обобщение NHRP е твърдение за отговора, който spoke изпраща, когато друг spoke попита как да достигне даден адрес. Това са различни въпроси с различни режими на отказ и един дизайн може да промени едното, оставяйки другото точно както е било. Третирането им като едно копче е начинът, по който промяна в обобщението тихо се превръща в промяна в препращането.
Нито една от двете операции не е твърдение за пътя на защита, защото той се договаря за peer-а, който реално сте резолвнали.
Какво всъщност променя обобщението на hub-а
Ръководството на Cisco за карти за обобщение NHRP между spoke-ове описва схема за Phase 3, при която hub-ът обявява обобщение и остава следващият хоп при маршрутизацията. Пренасочване и последваща резолюция по NHRP дават след това по-пряк път за препращане. Затова четенето само на агрегирания маршрут не описва цялото състояние на препращането и не означава, че всеки пакет трябва вечно да минава през hub-а. Обобщението е за достижимостта, не за пътя.
Ето защо преглед на дизайна, който спира до таблицата за маршрутизация, може да одобри промяна, която изменя поведението на резолюцията. Проверете избрания маршрут, резултата от NHRP и пътя на защита като три отделни наблюдения.
Ако не можете да кажете кое от трите се е променило, не сте приключили промяната.
Какво променя картата за обобщение NHRP
Вземете spoke, който притежава 10.32.0.0/19 чрез няколко по-конкретни LAN маршрута, докато hub-ът обявява по-голяма обобщена мрежа на останалите spoke-ове. Заявка за 10.32.12.10 иначе би получила информация за резолюция за съответната по-малка мрежа. Документираната функция карта за обобщение NHRP позволява на spoke-а да върне вместо това конфигурирания от него покриващ префикс, което може да намали повторната работа по резолюция за мрежите, принадлежащи на този spoke. Това не прави обобщението на маршрутите на hub-а и обобщението на резолюцията на spoke-а един и същ обект.
Дайте на този покриващ префикс обмислен модел на собственост. Широк отговор, който включва адреси, принадлежащи другаде, или празнини, които са недостъпни, може да насочи последващия трафик към неподходящ peer.
Проверете реалните маршрути и предвидените откази, преди да разширите префикса, а не след това.
Сравнете първата дестинация и една вътре в обобщението
Изберете две дестинации: първата, която тествахте, и друга, която стои вътре в предложеното обобщение. За всяка запишете избрания маршрут, състоянието на NHRP, използвано за достигане до нея, и реалния път на отговора. Това сравнение ви казва дали сте променили мащаба на маршрутизацията, мащаба на резолюцията или грешка в препращането, а това е единственото полезно заключение. Дисплей с по-малко префикси не е доказателство за нито едно от тях.
Потвърдете внедрената фаза и поведението на следващия хоп на протокола за маршрутизация, преди да приложите пример за Phase 3 към вашата мрежа. Краткият пример не е доказателство, че друг дизайн запазва същия директен път между spoke-ове.
Тикетът трябва да казва коя таблица сте намалили и коя сте оставили непипната. Всичко по-малко ще бъде диагностицирано отначало след месец.