Той самий /24 для двох клієнтів? VPNv4 потребує RD і мітки
Два орендарі можуть анонсувати той самий /24 лише тому, що RD дає кожному маршруту власну ідентичність. Мітка відповідає на інше питання: як пересилати.
Два орендарі нумерують свою філію тим самим 10.50.0.0/24, і після зміни маршрут одного з них зникає з краю провайдера, а інший продовжує працювати. Спрощення, що стоїть за цією заявкою, зазвичай полягає у відмові від розрізнювача маршрутів (RD), бо «мітка вже ідентифікує клієнта». Не ідентифікує. RD і мітка відповідають на два різні питання, і розрив стає помітним лише тоді, коли його нав'язують адреси, що перекриваються.
Один маршрут там, де їх має бути два
Звичайний IPv4 unicast порівнює два шляхи до одного префікса й установлює кращий. 10.50.0.0/24 від орендаря A і 10.50.0.0/24 від орендаря B — це один ключ, тому один перемагає, а другий зберігається лише як резервний шлях. Протокол зробив те, що йому сказали; у площини керування попросили зберігати два різні маршрути під одним ідентифікатором.
Результат виглядає як зниклий маршрут, а не як помилка: PE, який програв змагання, досі локально пересилає свого орендаря, тому перевірка всередині майданчика проходить, а тест між майданчиками не проходить. Перш ніж торкатися будь-якої політики, порахуйте записи для цього префікса в таблиці VPNv4.
RD перетворює один ключ на два
Восьмибайтовий розрізнювач маршрутів додається перед префіксом IPv4, і об'єкт, який несе BGP, стає адресою VPN-IPv4 замість префікса IPv4. Два орендарі можуть тримати ті самі 32 біти, бо 64 біти попереду різняться. Існують типи формату для RD на основі AS і для RD на основі адреси, і вибір належить початковому PE. RD на основі AS звичайний, коли PE поділяють AS, а на основі адреси — коли не поділяють.
Не читайте RD як мітку членства. Цілі маршруту керують імпортом і експортом і вирішують, які VRF можуть установити маршрут; RD лише гарантує, що маршрут має власну ідентичність. Давати кожному VRF власний RD — звична практика, бо вона зберігає це зіставлення читабельним у засобі перегляду маршрутів.
Мітка — це локальна інструкція пересилання
Кожен анонс також несе мітку MPLS, і її значення обмежене тим маршрутизатором, який її виділив. Інший PE може видати той самий номер для незв'язаного призначення. Саме тому мітка не може замінити ідентичність клієнта: номер правильний лише поряд із наступним переходом і станом пересилання, який його встановив.
Гранулярність виділення залежить від реалізації та дизайну: одні платформи виділяють одну мітку на VRF, інші на префікс, і мітка може позначати дію пересилання, а не клієнта. Дві різні мітки, що ведуть до одного призначення, не є суперечністю, і той самий номер мітки на двох PE — теж.
| Field | Where it lives | Scope | If you remove it |
|---|---|---|---|
| RD | VPNv4 NLRI | Per advertised route | Overlapping prefixes collide |
| Route target | Extended community | Import and export policy | Route lands in the wrong VRF |
| Label | Labeled NLRI and forwarding state | Per allocating router | No instruction for the data plane |
| Next hop | Path attribute | Per path | The label cannot be resolved |
Чому одне не може замінити інше
Читати анонс — означає дивитися на чотири речі разом: префікс з RD, цілі маршруту, наступний перехід і мітку. Читати пакет користувача — означає дивитися на стек, установлений із цієї інформації. Здоровий дизайн показує збіг обох сторін, а зламаний зазвичай має одну сторону правильною, а іншу застарілою. Це порівняння відокремлює проблему ідентичності від проблеми пересилання.
Охайне протиставлення площини керування та площини даних — навчальний прийом, а не опис кодування. RFC 8277 поміщає мітку всередину позначеного NLRI, тому сам анонс несе прив'язку; використовувати її для пересилання — наступний, окремий крок.
Коли маршрут орендаря зникає, перевіряйте в такому порядку: два записи VPNv4 для префікса, правильна ціль маршруту на кожному, розв'язний наступний перехід і мітка, для якої в приймального PE є стан. Виправлення ідентичності значенням пересилання або навпаки пройде одну перевірку і провалить наступну.