MPLS L3VPN лабораторија не одговара на пинг? Проверете ги овие пет скока

Два клиентски рутери, пар provider edge уреди и пинг што умира без порака за грешка. Во мала MPLS L3VPN лабораторија дефектот речиси секогаш седи на една од пет контролни точки, и секоја од нив има наредба што покажува или дека зависноста работи или дека недостасува. Грешката е да се рестартира BGP секој пат кога пингот не успева, наместо зависностите да се тестираат по ред. Ако веднаш скокнете на 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-овите одговараат на пинг, но 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 да има рута до CE LAN-от. Ако недостасува која било од двете половини, пингот паѓа пред да се стави било каква ознака.

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

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

Firewall-овите на домаќините, reverse-path filtering и access листите на CE уште важат. Ако патот напред работи, а одговорот умира, проблемот е рута или филтер на повратната страна, не MPLS транспортот.

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