Сесія BGP піднята, шлях клієнта зламаний: MPLS поверх DMVPN

Піринг піднято вже тижнями, кількість префіксів виглядає правильною, і все ж трафік одного клієнта йде довгим шляхом або взагалі не доходить. Один і той самий індикатор оцінює дві різні речі. Сесія BGP повідомляє, що два піри можуть обмінюватися повідомленнями через TCP-з'єднання; про те, чи здатний оверлей нести позначений пакет саме для цього клієнта, вона не каже нічого.

Цю прогалину найпростіше побачити в схемі MPLS поверх DMVPN, де шлях через хаб і прямий шлях через spoke можуть поводитися по-різному з причин, не пов'язаних із пірингом.

Що сесія справді доводить

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

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

Чотири механізми, а не один

Документація Cisco щодо MPLS поверх DMVPN чітко розділяє частини. MP-BGP поширює мітки оверлею клієнта між пристроями на краю провайдера. MPLS використовує ці мітки для вибору контексту пересилання пакета. NHRP зіставляє адресу оверлею з транспортним кінцем, потрібним динамічному тунелю. IPsec захищає шлях між пірами там, де це застосовно.

Будь-який із чотирьох може бути правильним, а інший — хибним, і трафік несе саме поєднання. Обмін маршрутами може завершитися, коли прив'язка мітки для одного VRF відсутня, коли зіставлення NHRP указує на застарілу транспортну адресу або коли тунель існує, але жодна політика не пропускає внутрішній пакет. Жодна з цих умов не валить сесію.

Порівняйте шлях через хаб із коротким шляхом, по одній змінній

Зафіксуйте хост-джерело, хост-призначення та VRF, потім двічі прослідкуйте той самий потік. На шляху через хаб занотуйте наступний хоп, сервісну мітку, що визначає контекст віддаленого клієнта, і використовуване зіставлення оверлею з транспортом. На передбачуваному прямому шляху занотуйте ті самі три речі. Різниця між двома списками і є несправність або її відсутність.

Тримайте потік незмінним під час порівняння. Зміна хоста-джерела, VRF або призначення між спостереженнями дає дві незв'язані історії, і це найпоширеніший спосіб зіпсувати цю вправу.

Тримайте тести loopback в окремому відсіку

Ping із loopback маршрутизатора — корисний тест, і він перевіряє інший випадок, ніж потік із хоста. Адреса джерела належить маршрутизатору, його контекст маршрутизації може бути глобальним, а не VRF, а зворотний шлях може відрізнятися від того, яким пішов би префікс клієнта. Тому loopback, що відповідає, і застосунок, що працює через короткий шлях, — різні результати, і лише другий описує клієнта.

Перевірте обидва, потім позначте їх окремо у своїх записах. Коли вони розходяться, ви дізналися щось конкретне про те, де схема відхиляється, і це більше, ніж коли-небудь скаже одна зелена галочка.

Твердження про версію та про дефект потребують власних доказів

Польові звіти іноді радять змінити маску хоста або адресу джерела BGP, і такі звіти варто читати лише разом із дефектом, про який їх написано, і випусками, яких він торкнувся. Обхідне рішення з одного випуску не є твердженням, що архітектура не підтримує жодного префікса /32.

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