Лабораторія 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 клієнта. Якщо відсутня будь-яка з двох половин, 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.

Тримайте один рядок на кожну контрольну точку з ім'ям першої залежності, що впала. Цей рядок перетворює скаргу, що клієнт не може пінгувати, на конкретне питання про досяжність, стан міток, імпорт маршрутів, належність interface або зворотний шлях, і заважає наступній сесії налагодження повторити ті самі п'ять команд у тому ж порядку.