MP-BGP address families: RR-кластер

Теоретические основы и архитектура

Лабораторная работа: развёртывание Multiprotocol BGP (MP-BGP, RFC 4760) и кластера Route Reflector для сервисов VPN. Классический BGP-4 поддерживает исключительно маршрутизацию IPv4 Unicast. Для поддержки виртуальных частных сетей (L3VPN, EVPN, 6VPE) протокол MP-BGP вводит концепцию семейств адресов (Address Families), идентифицируемых через AFI (Address Family Identifier) и SAFI (Subsequent Address Family Identifier). Для L3VPN используется AFI=1 (IPv4) и SAFI=128 (VPNv4 Unicast), для EVPN — AFI=25 и SAFI=70 (L2VPN EVPN). В лабораторной на пограничных PE и центральных Route Reflector отключается передача обычных IPv4-маршрутов через ядро и активируются адресные семейства vpnv4 и l2vpn evpn. Маршрутизаторы RR переносят VPNv4 NLRI (64-битный RD, префикс, метка) вместе с атрибутом Extended Community Route Target, не инсталлируя эти маршруты в свою локальную таблицу маршрутизации, что обеспечивает изоляцию и масштабируемость ядра.

Что добавляет MP-BGP (RFC 4760)

Классический BGP-4 переносит только IPv4 unicast в поле NLRI сообщения UPDATE. Multiprotocol Extensions вводят два атрибута: MP_REACH_NLRI (тип 14: AFI, SAFI, next hop и список NLRI) и MP_UNREACH_NLRI (тип 15: отзыв маршрутов). Поддержка сообщается в OPEN как capability код 1: соседи обмениваются парами AFI/SAFI и используют только общие. Следствия для эксплуатации: семейство адресов нужно включать на обеих сторонах (activate на Cisco, enable на Huawei, family в группе Junos), а добавление семейства на живой сессии обычно приводит к её перезапуску, потому что набор capability меняется только в новом OPEN. Планируйте такие изменения в окно работ.

Семейства адресов, которые встречаются в сети оператора

Что внутри VPNv4 NLRI

Префикс VPN-IPv4 занимает 12 байт: 8 байт Route Distinguisher и 4 байта IPv4. В NLRI дополнительно идёт 3-байтное поле метки (20 бит метки, 3 бита EXP, бит S) и длина в битах, равная 24 + 64 + длина IPv4-префикса. Next hop в MP_REACH для VPNv4 состоит из 12 байт (RD 0:0 и IPv4-адрес PE), для VPNv6 - из 24 байт. RT передаётся как extended community, поэтому на Cisco для vpnv4 и vpnv6 обязателен send-community extended; без него маршрут приходит без RT и не импортируется ни в одну VRF. Метка VPN назначается PE при экспорте маршрута из VRF (per-prefix, per-VRF или per-next-hop); транспортную метку к next hop 10.255.0.1 позже добавляет LDP.

RR для VPN-семейств

Route Reflector для VPNv4 не нуждается в VRF: он хранит маршруты всех клиентов как есть. Здесь есть ловушка, из-за которой лабораторные работы чаще всего "поднимаются, но пусто":

• Cisco IOS-XE: по умолчанию включён bgp default route-target filter, и RR без VRF отбрасывает VPNv4-маршруты, RT которых не совпадает ни с одним локальным import RT. На RR задают no bgp default route-target filter.
• Huawei VRP: в режиме vpnv4 на RR отключают проверку командой undo policy vpn-target.
• Junos: RR (группа с cluster) сохраняет все маршруты в bgp.l3vpn.0 независимо от RT; на маршрутизаторе без cluster и без VRF маршруты без подходящего RT отбрасываются.

Для больших сетей используют RT-constraint (SAFI 132): PE объявляют, какие RT им нужны, и RR отправляет только соответствующие маршруты, что резко сокращает объём обновлений.

Резервирование: два RR и разные уровни

PE подключают к двум RR с одинаковым Cluster-ID (RR1 10.255.0.100 и RR2 10.255.0.101), и каждый PE имеет сессию с обоими. Благодаря уникальному RD в каждой VRF каждого PE маршруты одного и того же клиентского префикса из двух точек подключения имеют разные NLRI, поэтому RR хранит оба и отражает оба, а у PE есть multipath без add-path. Если RD одинаковый на всех PE, RR выбирает один маршрут и скрывает второй. Рекомендуется разделять плоскости: IPv4 unicast, VPN и EVPN на отдельных RR, чтобы сбой или перегрузка одной плоскости не затрагивали остальные.

Порядок проверки при поднятии

Порядок проверки в лабораторной: IGP и LDP между PE и RR (loopback/32 и метки), TCP/179 между loopback, обмен capability (в выводе нужные семейства "advertised and received"), создание VRF и импорт RT, выдача метки VPN, отражение RR (в маршруте на PE2 появляются Originator и Cluster list), наконец, пересылка пакета с двумя метками. Типичные сбои: AF включено только на одной стороне, нет send-community extended, на RR остался RT-filter, RR1 и RR2 с разными Cluster-ID без сессии друг с другом, отсутствие LSP до next hop.

Проверка устойчивости

Работающий ping после выключения RR1 ничего не доказывает: старые маршруты остаются в таблице PE, пока сессия не упала по hold timer. Правильная проверка: выключить RR1, создать на PE1 новый префикс (например, второй интерфейс в VRF A) и убедиться, что на PE2 он появился через RR2. Только это доказывает, что control plane резервирован.

Схема архитектуры и топология

                +--------------------------------+
                |   Route Reflector cluster      |
                |  RR-1: 10.255.0.101            |
                |  RR-2: 10.255.0.102            |
                |  (RR-1 <-> RR-2 peering, both  |
                |   reflect to the PE clients)   |
                +--------------------------------+
                  /                         \
VPNv4 iBGP (PE = RR client)     VPNv4 iBGP (PE = RR client)
                v                             v
        +---------------+             +---------------+
        |     PE-1      |             |     PE-2      |
        | VRF: Cust-A   |             | VRF: Cust-A   |
        +---------------+             +---------------+

Схема прохождения трафика и стек меток

MP-BGP Address Families & NLRI Signaling:
1. PE-1 encodes IPv4 into 96-bit VPNv4 prefix: [RD: 65000:1] + [Prefix: 192.168.10.0/24]
2. Appends Path Attributes: Next-Hop (10.255.0.1), Extended Community RT (65000:100), Service Label (24001).
3. Transmits to RR via AFI 1 (IPv4) / SAFI 128 (VPNv4).
4. RR reflects update to PE-2 without altering Next-Hop or Service Label.

Таблица состояний и параметров

Архитектурная модель и принцип работы

В реальных сетях оператора MPLS объединяет оборудование различных производителей. Ниже представлены практические примеры конфигурации и вывода команд Data Plane / Control Plane для четырёх платформ: Cisco IOS-XE/XR, Huawei VRP, Juniper Junos и MikroTik RouterOS v7. Обратите внимание на различия в синтаксисе и механизмах распределения меток.

Практическая конфигурация (Cisco, Huawei, Juniper, MikroTik)

Cisco (IOS-XE/XR)