Два PE, один префікс: чому RD визначає видимість
Два граничні маршрутизатори, що оголошують один і той самий префікс, поділяють одне призначення, якщо їхні route distinguisher не різняться. Призначайте свідомо, потім перевірте VRF.
Два граничні маршрутизатори, що оголошують той самий префікс клієнта, описують одне призначення VPNv4, доки щось їх не розділить, і цим розділювачем є route distinguisher. Він кваліфікує префікс; він не вирішує, хто імпортує результат, це завдання route target. Призначайте RD із множини маршрутів, які мають залишатися розрізнюваними в кожному домені, де ці оголошення можуть зустрітися, а не з розкладки файлів на одному пристрої. Вибраний номер — це ідентичність, від якої залежатимуть подальші перевірки, тож йому місце в описі до того, як він потрапить у конфігурацію.
RD разом із префіксом — одне призначення
RD разом із префіксом IPv4 утворює призначення VPNv4, яке порівнює площина керування. Дайте двом PE той самий префікс для різних клієнтів, і без різних RD вони оголошують маршрути до одного призначення. Ніщо на екрані не каже, що таке групування хибне, бо платформа робить саме те, що каже ідентичність. Змініть RD на одному з них, і старе оголошення відкликається, а під іншою ідентичністю з’являється нове. Усе нижче за потоком, що спиралося на стару ідентичність, від вибору маршруту до збереженого фільтра оператора, тепер посилається на те, чого вже немає.
Кілька маршрутів на одне призначення — звичайна поведінка BGP, а не симптом. Спікер може тримати кілька отриманих маршрутів, вибираючи один найкращий для пересилання, і розрив між отриманим і вибраним — це місце, де живуть питання видимості. Коли маршрут ніби зник, спершу підтвердьте, чи ідентичність, до якої він належав, ще існує, і лише потім дивіться на сесію.
Ті самі RD і призначення, різні маршрути
Надішліть один RD і один префікс із двох маршрутизаторів від імені однієї послуги, і обидва пропонують маршрути до одного призначення, зазвичай із різними наступними хопами. Який із них передасть відбивач маршрутів — це рішення про відбивач: його вибір маршруту, здатність оголошувати й будь-яка політика, накладена зверху. Жоден граничний маршрутизатор не керує цим вибором. Дайте двом оголошенням різні RD, і кожне стане власним призначенням, тож обидва можуть пережити площину керування, яка інакше несе лише вибраний маршрут для однієї ідентичності.
Видимість і багатопотоковість зустрічаються в приймальному VRF, але це не одне й те саме рішення, і відбивач, що несе дві ідентичності, не налаштував другий установлений маршрут. VRF установлює те, що допускає його політика імпорту, і те, що дозволяє його власне налаштування максимуму маршрутів. Перевірте це налаштування окремо, якщо хочете, щоб другий маршрут використовувався, а не просто був видимий.
Локальне правило унікальності — не політика
Давати кожному PE і кожному екземпляру маршрутизації власний RD — слушна конвенція: він називає джерело, не дає незв’язаним послугам зіткнутися на одній ідентичності й дає опису стабільний ключ. Деякі платформи вимагають унікальності лише всередині пристрою й явно дозволяють маршрутизаторам ділити RD для одного екземпляра VPN. Цей дозвіл — обмеження реалізації, а не міжмережеве правило, яке можна делегувати постачальнику. Якщо домен охоплює кілька команд, напишіть політику розподілу самі.
Належність ніколи не випливає з цифр. Шаблон на кшталт 65000:12 для одного PE і 65000:13 для іншого — звичка, тоді як збіжні цілі експорту й імпорту на кшталт 65000:112 — це те, що поміщає маршрут у VRF. Ставтеся до RD як до ідентичності маршруту, а до route target — як до дозволу, що несе його в VRF.
Доведіть зміну на VRF, а не на екрані
Перш ніж торкатися RD, запишіть чотири речі: що PE оголошує сьогодні, що відображає відбивач, що імпортує приймальний VRF і який маршрут він вибирає. Новий RD відкликає одне оголошення й уводить інше, тому зміна видна з обох боків сесії, і її легко прочитати неправильно, якщо стежити лише за стороною, що оголошує. Приймання має спиратися на потрібну вам доступність, а не на зайвий рядок у списку префіксів. Таблиця нижче не дає трьом ідентифікаторам злитися під час цієї перевірки.
| Identifier | Question it answers | What breaks when it is confused with another |
|---|---|---|
| Route distinguisher | Which route identity is this? | Two services collapse into one destination, so one advertisement withdraws the other |
| Route target | Who is allowed to import it? | Routes arrive in a VRF that should not have them, or never arrive at all |
| VRF import policy | What does this instance accept and install? | The route is visible on the PE but never selected in the VRF |
Почніть з PE, що оголошує, і порівняйте обидві ідентичності для одного префікса, перш ніж щось видаляти. Команди IOS нижче по черзі відповідають на три питання: чи старе оголошення ще там, чи нова ідентичність видима відбивачу і чи вибирає VRF цей префікс.
show bgp vpnv4 unicast rd 65000:12 203.0.113.0/24 show bgp vpnv4 unicast rd 65000:13 203.0.113.0/24 show ip route vrf CUSTOMER-A 203.0.113.0/24
Інші платформи друкують ту саму інформацію в іншому синтаксисі, і питання переживають цю зміну. Якщо нової ідентичності немає у відбивача, а PE перелічує її як оголошену, перший підозрюваний — політика або здатність відбивача оголошувати, а не нумерація.
Запишіть PE, екземпляр, RD, цілі експорту й імпорту та власника префікса в одному місці, бо наступний розподіл стає пошуком, а не здогадом лише тоді, коли цей запис існує. Тримайте старий RD, доки нова ідентичність не стане видимою в приймальному VRF, потім відкличте його другим кроком, щоб кожен етап залишався оборотним.