Лабораторията MPLS L3VPN не отговаря на ping? Проверете тези пет скока

Два клиентски рутера, чифт устройства provider edge и ping, който умира без съобщение за грешка. В малка лаборатория MPLS L3VPN повредата почти винаги седи в една от пет контролни точки и всяка от тях има команда, която показва или че зависимостта работи, или че липсва. Грешката е да рестартирате BGP всеки път, когато ping-ът се провали, вместо да тествате зависимостите по ред. Ако скочите направо в конфигурацията на VRF, можете да прекарате час в проблем, започнал с неразрешен следващ скок два устройства по-нататък.

Работете списъка отдолу нагоре. Контролна точка, която мине, остава взета, и първият провал е този, който си заслужава отстраняването.

Първа контролна точка: PE устройствата се достигат взаимно

Всеки PE се нуждае от маршрут до loopback-а на другия PE и този маршрут трябва да се разреши през нещо реално. Interior gateway protocol е обичайният път дотам, но и статичен маршрут работи, стига рекурсивното търсене да стигне до жив adjacency. На устройства в стил IOS show ip route 10.0.0.2 и след това show ip cef 10.0.0.2 показват дали префиксът съществува и дали зад него има разрешен adjacency. Маршрут в таблицата без adjacency зад него не е достъпност.

Проверете двете посоки. Асиметрични IGP разходи, passive interface от грешната страна или distribute list, който филтрира loopback-а, чупят всяко само една посока, а една посока е достатъчна да убие сесията. Ако loopback-ите отговарят на ping, но BGP сесията стои в Active, погледнете update source, преди да пипнете нещо друго.

Втора контролна точка: съществува път на етикети

IP маршрут до отдалечения loopback не доказва, че транспортът ще сложи етикет. В LDP дизайн потвърдете, че отдалеченият loopback има локално и отдалечено свързване и че изходящият етикет се появява във forwarding таблицата. show mpls ldp bindings 10.0.0.2 32 показва двойките етикети, а show mpls forwarding-table 10.0.0.2 показва какво line card-ът действително ще сложи. Когато втората команда не показва никакъв етикет или се връща към IP, транспортът не носи VPN трафика така, както предполага дизайнът.

Разликата идва от това как MPLS отделя forwarding state от префиксите на дестинацията, моделът, описан в RFC 3031. Ако лабораторията ви използва RSVP-TE или етикети, съседни на BGP, вместо LDP, проверете собственото състояние на този механизъм; да предполагате, че LDP разпределя всеки етикет от долния слой, е чест начин да гоните фантомна грешка. Счупен път на етикети обикновено се появява по-късно като VPN маршрут, който съществува, но е неизползваем.

Трета контролна точка: VPN маршрутът пристигна непокътнат

Вижте VPNv4 или VPNv6 маршрута за точния префикс на клиента, не резюмето на сесията. show bgp vpnv4 unicast all 10.10.1.0/24 трябва да покаже route distinguisher, next hop, зададен на loopback-а на отдалечения PE, и етикет. Ако префиксът липсва, първият заподозрян е експортната политика на изходния PE или импортната политика на приемащия PE, а route target-ите са обичайният виновник.

Четете проверката на route target отделно от BGP приемането. Маршрут може да пристигне с правилния next hop и въпреки това да не кацне във VRF, защото importtarget не съвпада. На приемащия PE show ip route vrf CUSTOMER 10.10.1.0 е тестът, който има значение; BGP таблицата само доказва, че маршрутът е преминал контролната равнина.

Четвърта контролна точка: interface-ът е във VRF

VRF дефиниция с route distinguisher и route target-и не премества нито един interface в нея. Interface-ът към CE се нуждае от VRF присвояване, а show ip vrf interfaces или show ip interface brief трябва да го изброи под правилната инстанция. Това е контролната точка, където копирана конфигурация най-често греши, защото VRF блокът изглежда пълен, докато interface-ът още седи в глобалната таблица.

След това потвърдете, че PE е научил локалния префикс на клиента в този VRF и че CE има маршрут обратно през връзката. Статичен default на CE, сочещ към PE, е достатъчен за лаборатория, при условие че VRF на PE има маршрут до LAN на CE. Ако липсва която и да е от двете половини, ping-ът се проваля, преди да бъде сложен какъвто и да е етикет.

Пета контролна точка: отговорът намира път към дома

Проследете пакета напред и след това обратния пакет, защото използват различни таблици. На входящия PE източникът на клиента трябва да се разреши вътре във VRF до отдалечения префикс с отдалечения етикет. На изходящия PE дестинацията трябва да се разреши вътре в същия VRF до interface-а към CE. Ping, изпратен от самия PE, не е доказателство: може да излезе през глобалната таблица или друг изходен адрес, и затова ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 е тестът, който трябва да се изпълни.

Защитните стени на хостовете, reverse-path filtering и access списъците на CE продължават да важат. Ако пътят напред работи, а отговорът умира, проблемът е маршрут или филтър от обратната страна, не MPLS транспортът.

Водете по един ред за всяка контролна точка с името на първата зависимост, която се е провалила. Този ред превръща оплакването, че клиентът не може да прави ping, в конкретен въпрос за достъпността, състоянието на етикетите, импорта на маршрути, принадлежността на interface-а или обратния път, и пречи следващата сесия за отстраняване на грешки да повтори същите пет команди в същия ред.