Липсващ маршрут във VRF: локален, VPNv4 или таблица за препращане?

Клиент казва, че префикс е изчезнал след промяна на цел на маршрут, и първата снимка на екран, която изпраща, обикновено показва грешната таблица. Три различни таблици отговарят на три различни въпроса: дали префиксът съществува във VRF, дали е бил обявен и импортиран като маршрут VPNv4 и дали запис за препращане действително е инсталиран. Четенето им в грешен ред дава уверени, но погрешни заключения. Това ръководство прекарва един локален и един отдалечен префикс през трите таблици по ред и завършва с план за връщане назад за промяната на RT, която го е започнала.

Назовавайте префикса и таблицата, към която принадлежи

Запишете два префикса, преди да въведете каквото и да е. Единият е локален за обекта на клиента, научен от свързан интерфейс или от обява на CE. Другият е отдалечен и се очаква да пристигне по опорната мрежа на доставчика. Те поемат по различни пътища към един и същ VRF и повреда в единия не казва нищо за другия.

Пазете ясна разликата между двата идентификатора, защото по-голямата част от объркването в тези заявки идва именно оттам. Идентификаторът на маршрут е част от NLRI на VPNv4 и съществува, за да прави иначе еднаквите клиентски префикси уникални в опорната мрежа. Целта на маршрут е разширена общност, носена като атрибут, и именно с нея съвпада политиката за импорт и експорт. Тя не е второ име на идентификатора и не се носи в пакетите на клиента.

Стъпка 1: докажете, че префиксът е във VRF

Започнете с локалния изглед, после с RT, които управляват импорта. Ако локалният префикс липсва тук, нищо по-нагоре не може да е виновно:

show ip route vrf CUST-A 172.21.4.0 255.255.255.0
show ip route vrf CUST-A | include 172.21.4.0
show ip vrf CUST-A

Префикс, който се показва като свързан или статичен, е научен локално и присъствието му не казва нищо за това дали е бил експортиран. Това е най-често срещаното погрешно четене в този работен процес: здравата таблица на VRF е доказателство само за локалното научаване. Страната на експорта е отделен въпрос, на който отговарят изгледът на съседа и прикачената цел за експорт.

Проверете списъците с RT на VRF, докато сте тук. Ако предвидената цел за импорт не е в списъка, всичко надолу е без значение. Ако е налична, но се различава от това, което отдалеченият PE експортира, открили сте повредата, без да отваряте нито един запис на пакети.

Стъпка 2: прочетете таблицата VPNv4 и нейните цели

Таблицата VPNv4 показва какво контролната равнина действително е обменила. Търсете отдалечения префикс под правилния идентификатор, после вижте общностите, прикачени към него:

show ip bgp vpnv4 all 10.60.9.0/24
show ip bgp vpnv4 all | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A neighbors 192.0.2.17 advertised-routes

Запис с правилната цел на маршрут, но без локална инсталация, сочи към политиката за импорт или към избора на маршрут, а не към достижимостта. Запис, който изобщо не се появява в таблицата VPNv4, сочи нагоре: PE източникът може да не го е експортирал или сесията може да не носи семейството адреси.

Има и трети случай, който обърква хората по време на промени. Някои платформи ограничават кои VPN маршрути заявяват или задържат, използвайки информация за членство в цели на маршрути, така че липсата на отдалечен NLRI в един филтриран изглед не е доказателство, че обявата не съществува никъде. Проверете нефилтрираната таблица и обявените маршрути на съседа, преди да заключите, че маршрут е оттеглен глобално.

Стъпка 3: потвърдете, че нещо е инсталирано и етикетирано

Записът в BGP е решение, а не път. Таблиците за препращане ви казват дали пакетите имат накъде да отидат:

show ip cef vrf CUST-A 10.60.9.0/24
show mpls forwarding-table vrf CUST-A | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A

Запис в CEF с разрешена съседност и изходящ етикет означава, че трафикът на равнището на данните би трябвало да работи, а всеки останал симптом принадлежи на приложението или на филтриране във VRF. Запис в CEF с неразрешен следващ хоп означава, че пътят на етикета е непълен, дори когато BGP изглежда здрав, и точно това е случаят, в който снимка на таблицата на BGP е подвела преглед на промяна.

Сравнете етикета, който локалният PE налага, с този, който отдалеченият PE очаква да получи. Несъответствие между двата изгледа е проблем с разпределението на етикети или със сесията и няма да се оправи с редактиране на цели на маршрути, колкото и пъти да го правите.

Върнете промяната на RT с обявен обхват

Ако повредата е започнала с редакция на цел на маршрут, отменете я като една умишлена стъпка и кажете какъв обхват променяте. Премахването на цел за импорт отнема допустимостта във VRF. То не изтрива обявата VPNv4 от опорната мрежа и на някои платформи маршрутът остава задържан в таблицата. Това са различни резултати и видимият за потребителя ефект зависи от това кой от тях имате предвид.

configure terminal
vrf definition CUST-A
 address-family ipv4
  no route-target import 65000:410
 end
clear ip bgp vpnv4 vrf CUST-A soft in

Мека входяща реконфигурация е достатъчна, когато сесията вече пази префиксите; твърдо нулиране на сесия, обърната към доставчик, в работно време е решение, което друг трябва да вземе. В Junos еквивалентните проверки четат директно таблицата за всеки VRF и таблицата на VPN, а връщането назад е връщане при commit, а не отмяна команда по команда, затова запишете разликата в конфигурацията, преди да започнете.

Завършете със същите три команди, с които започнахте, в същия ред, и запишете изхода им с времева марка. Заявка, която казва, че целта е била грешна, а сега е вярна, не може да се използва повторно; тази, която показва префикса във VRF, във VPNv4 и инсталиран в CEF, е доказателство, с което следващият човек може да сравни. Ако само първите две са се променили, не сте завършили промяната.