Домены маршрутизации F5 и MPLS VRF: сопоставьте передачу арендатора
Два арендатора, один адрес, два домена маршрутизации. Закрепите каждый объект через %ID, используйте VRF и цели маршрутов провайдера и проверяйте каждого арендатора отдельно.
Два арендатора запускают одно и то же приложение по адресу 10.50.0.10. Провайдер держит их раздельно в разных MPLS VPN, а BIG-IP хранит их локальный трафик в разных доменах маршрутизации. Эта схема работает вплоть до передачи, где отсутствующий суффикс или скопированная цель маршрута тихо помещает пакет одного арендатора в контекст другого. Это руководство связывает две модели и заканчивается проверкой для каждого арендатора.
Рабочий лист: одна строка на арендатора
Заполните его, прежде чем что-либо менять. Каждый следующий шаг ссылается на ячейку в нём, а пустая ячейка — это решение, которое ещё никто не принял.
| Tenant | BIG-IP side | Provider side |
|---|---|---|
| A | VLAN or tunnel, route domain, self address, virtual server | VRF, attachment, route targets for import and export |
| B | Separate VLAN or tunnel, separate route domain, separate self address | Separate VRF, separate route targets |
Шаг 1: закрепите каждый объект за его доменом маршрутизации
Документация F5 по доменам маршрутизации описывает изолированные контексты трафика, дублирующиеся адреса и нотацию address%ID для объектов конфигурации. Адрес, записанный как 10.50.0.10%2, называет локальный контекст домена маршрутизации, и этот суффикс не является меткой MPLS, переносимой в IP-пакете клиента.
VLAN или поддерживаемый туннель в документированной модели принадлежит одному домену маршрутизации, поэтому интерфейс и адрес должны совпадать. Проверьте также домен маршрутизации по умолчанию административного раздела, потому что пропущенный суффикс означает не отсутствие контекста, а тот контекст, который раздел использует по умолчанию. Именно это единственное значение по умолчанию объясняет большинство инцидентов, когда новый объект тихо отвечал не тому арендатору. Проверьте его, прежде чем добавлять собственный адрес.
tmsh list net route-domain
tmsh list net vlan | grep -i domain
tmsh list ltm virtual one_vsШаг 2: используйте VRF и цели маршрутов провайдера
На границе MPLS арендатор определяется VRF провайдера и согласованной службой маршрутизации клиента. Цели маршрутов управляют тем, какие маршруты провайдер импортирует и экспортирует между VRF, а выбор похожего номера домена маршрутизации BIG-IP не создаёт ничего из этих отношений.
Два идентификатора живут в разных системах и означают разные вещи. ID домена маршрутизации — это локальный контекст на устройстве. Цель маршрута — атрибут политики на стороне провайдера, определяющий распределение маршрутов, а различитель маршрута — это ещё третья вещь, служащая для разделения иначе идентичных префиксов.
Шаг 3: решите, могут ли контексты совместно использовать доступность
Намеренно пересмотрите настройки поиска в родительском домене и строгой изоляции, потому что они меняют то, чего может достичь контекст. Руководство F5 разрешает контролируемую пересылку через такие отношения, и именно поэтому домен маршрутизации не следует сам по себе считать полной политикой безопасности арендатора.
Если обоим арендаторам нужен общий сервис, укажите одобренный путь и разрешения вместо того, чтобы небрежно направлять одного арендатора в контекст маршрутизации другого. Сохраняйте идентичность приложения и любое намеренное преобразование источника вместе с сетевым назначением, иначе общий сервис увидит одного арендатора как другого.
Обычная маршрутизируемая передача соединяет BIG-IP с граничным маршрутизатором провайдера, не делая BIG-IP точкой MPLS PE. Если действительно требуется прямая интеграция MPLS или семейства маршрутов VPN, получите явную поддержку для точной платформы и версии, потому что локальная изоляция домена маршрутизации не создаёт такой возможности.
Шаг 4: проверяйте по одному арендатору за раз
Проверьте арендатора A с конечной точки в контексте A до адреса приложения A, затем повторите для B. Используйте форму %ID в диагностике, чтобы доказать, какой контекст ответил, и подтвердите, что запрос из неправильного контекста завершается неудачей, а не попадает в какое-то правдоподобное место.
Проверьте сторону провайдера в том же проходе: префикс присутствует в правильном VRF, цели маршрутов совпадают с рабочим листом, а обратный путь использует предусмотренное подключение. Ping, работающий с самого устройства, доказывает контекст устройства, а не арендатора.
Запишите итоговое сопоставление в рабочий лист, включая домен маршрутизации по умолчанию каждого раздела и любые включённые вами отношения родительского домена. Следующее изменение в этой среде сделает тот, кто читает эту таблицу, а не тот, кто читает эту статью.