Деякі маршрути L2VPN зникають після додавання відбивачів маршрутів

Сесії залишаються встановленими, IGP стабільний, і все ж кілька маршрутів L2VPN так і не з’являються на двох із чотирьох меж провайдера. Цей шаблон належить до проблеми відбиття, а не транспорту, бо зламана сесія падає повністю, а повторно використана межа відбиття падає вибірково. Фізичне кільце тут ні до чого; логічний граф розподілу — це місце, де ці маршрути зупинилися. Пошук цієї точки не потребує перебудови площини керування.

Втрата вибіркова, що звужує пошук

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

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

Що насправді змінює відбиття

Відбиття маршрутів послаблює правило, за яким мовник iBGP не може повторно оголошувати маршрут, вивчений від іншого мовника iBGP. RFC 4456 виражає виняток через стосунок між мовником і джерелом маршруту, і напрямок цього стосунку важливіший, ніж припускає більшість оглядів. Маршрут, вивчений від клієнта, може відбиватися іншим клієнтам і не-клієнтам, тоді як маршрут, вивчений від не-клієнта, може відбиватися лише клієнтам. Прочитайте асиметрію двічі, бо вона пояснює, як додавання клієнтського стосунку може приховати помилку проєктування: воно відкриває шлях, якого топологія ніколи не передбачала.

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

Повторно використані ідентифікатори кластерів — це те, як маршрути зникають

Невелика мережа спокушає коротким шляхом: задайте кожному маршрутизатору ідентифікатор кластера, що дорівнює його loopback, пізніше додайте ще один відбивач і повторно використайте наявний loopback, бо він під рукою. Якщо цей ідентифікатор тепер з’являється на двох незалежних ступенях відбиття, друга ступінь бачить власний ID у CLUSTER_LIST і відкидає маршрут. Ніщо не записує помилку, бо відкидання — правильна відповідь на петлю.

Резервні відбивачі, що обслуговують один кластер, — законний виняток: вони навмисно ділять один ID, щоб будь-який із них міг обслуговувати тих самих клієнтів. Ідентифікатор має відповідати проєкту відбиття, а не розрізняти назви корпусів.

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

Опирайтеся спокусі зробити кожного сусіда клієнтом

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

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

Перевірте родину адрес, перш ніж звинувачувати відбиття

TCP-сесія на порту 179 доводить, що два мовники можуть розмовляти, і нічого не каже про те, чи родина адрес VPN обмінялася хоч одним маршрутом. Встановіть стан сесії, потім родину, потім окремий префікс.

vtysh -c "show bgp summary"
vtysh -c "show bgp l2vpn evpn summary"
vtysh -c "show bgp l2vpn evpn"

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

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