Один и тот же /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 есть состояние. Исправление идентичности значением пересылки или наоборот пройдёт одну проверку и провалит следующую.