Тунель RSVP-TE працює, але клієнтський L3VPN не має шляху

Транспорт і послуга — різні рішення. Прочитайте стек міток, окремо перевірте розв’язання наступного переходу та приєднання VRF, потім перевірте один реальний потік клієнта.

Дві команди можуть бути праві одночасно, коли клієнт повідомляє, що VPN не працює, а транспортна команда повідомляє, що тунель у порядку. LSP з інженерією трафіку та MPLS L3VPN відповідають на різні питання: один переносить помічені пакети через ядро, інший вирішує, до якого контексту маршрутизації належить пакет. Коли їх змішують, суперечка ходить по колу, бо кожна сторона вимірює інший об’єкт, і обидва вимірювання правильні.

Транспорт працює, а послуга ні — це нормальний стан

LSP може бути встановлений, передавати трафік і бути видимим у кожній системі моніторингу, поки клієнтська послуга залишається непридатною. У цій комбінації немає нічого суперечливого, бо тунель не має думки про те, чи існує віддалений префікс, чи прийняла його політика імпорту або чи пропускає кадри приєднаний контур.

Симптом, який зазвичай викриває плутанину, асиметричний: ping з loopback PE проходить, а хост у клієнтській LAN не отримує нічого, або навпаки. Запишіть, які адреси працювали, перш ніж будувати теорію. Щойно ви помітите, що перевіряєте два різні об’єкти, наступним кроком буде прочитати стек міток, а не сперечатися, чий граф правильний. Дві адреси, двоє власників і зазвичай дві різні людини, кожна з яких вважає, що інша щось зламала.

Читайте стек як дві відповідальності

Нижня мітка належить послузі, а верхня мітка належить шляху. RFC 4364 просто описує послідовність: спочатку накладається мітка маршруту VPN, потім цей помічений пакет тунелюється до наступного переходу BGP, де тунель інженерії трафіку кладе зверху свою власну мітку.

ObjectDecision it encodesWho owns it
Attachment and VRFWhich customer context receives the arriving packetEdge configuration
VPN route and service labelWhich remote forwarding context handles the destinationBGP VPN signalling
Transport LSP and tunnel labelHow the core carries the packet to the BGP next hopRSVP-TE or another tunnel mechanism

На дальньому PE мітка послуги вибирає обробку, яка може бути пошуком у VRF або рішенням про приєднання. Цю мітку не можна замінити на ту, що лише перетинає ядро, і вони не взаємозамінні, навіть коли обидві з’являються в одному стеку на одному інтерфейсі.

Що доводить успіх RSVP, а що ні

RSVP-TE встановлює явно маршрутизовані LSP, з резервуванням ресурсів або без нього, і це конкретна та корисна гарантія щодо шляху, який пакет проходить через ядро. Це не твердження про клієнтські маршрути, а налаштоване ім’я тунелю взагалі не маршрут.

Наявність RSVP також не дає обіцянки продуктивності від краю до краю. Резервування смуги пропускання на одному LSP нічого не говорить про приєднаний контур, власну лінію доступу клієнта чи поведінку черги на дальньому краї. Ставлення до цього як до гарантії дає впевнені відповіді на питання, яких ніхто не ставив. Якщо вимога справді є зобов’язанням щодо смуги пропускання, його треба скласти з частин, які реально його забезпечують, а LSP — лише середина цього ланцюга.

Перевіряйте по порядку, потім зупиніться

Працюйте від транспорту назовні й зупиніться на першому кроці, що не вдався, бо кожен наступний крок припускає, що попередні витримали. Спочатку переконайтеся, що LSP встановлено і що запис пересилання для префікса послуги справді вказує на нього. Потім переконайтеся, що маршрут VPN існує в потрібній таблиці, що його прив’язка мітки присутня і що політика імпорту його прийняла. Далі переконайтеся в приєднанні: інтерфейс, інкапсуляція і, де застосовно, ідентифікатор VLAN, що належить цьому договору.

show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMER

Синтаксис команд залежить від платформи, тому ставтеся до цих чотирьох рядків як до чотирьох питань, а не як до сценарію. Важливо те, що кожен із них опитує інший об’єкт, і саме тому збій вказує на конкретного власника.

Простежте один дозволений запит і збережіть добрі докази

Завершіть одним реальним запитом клієнта, дозволеним політикою, і відповіддю на нього. Один робочий потік від краю до краю вирішує більше, ніж сторінка показників лічильників, і він перевіряє комбінацію, а не кожну частину окремо.

Коли пізніший етап не вдається, збережіть успішне спостереження LSP замість того, щоб перебудовувати транспорт. Перебудова робочого тунелю не може виправити відсутній віддалений префікс, неправильне приєднання VRF або правило доступу до призначення, і вона знищує доказ, який спочатку сказав, що транспорт здоровий.

Схожі статті