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

Взаимодействие между пограничным маршрутизатором оператора (PE) и маршрутизатором клиента (CE) осуществляется через протоколы маршрутизации PE-CE. Поддерживаются три основных варианта: 1. Статическая маршрутизация (Static Routing): простейший вариант для небольших филиалов с одним линком (на PE настраивается статический маршрут в VRF, перераспределяемый в MP-BGP). 2. OSPF в качестве PE-CE: часто используется корпоративными клиентами. Для предотвращения петель между сайтами клиента через MPLS ядро протокол OSPF использует специальные расширения: DN-бит (Down-bit в LSA Type 3) и атрибут VPN Route Tag. PE, получив от CE LSA Type 3 с установленным DN-битом, не использует его в SPF и не возвращает маршрут в MP-BGP. Также применяется Sham-Link для сохранения Intra-Area метрик поверх MPLS. 3. eBGP в качестве PE-CE: наиболее масштабируемый и рекомендуемый протокол для крупных сетей. Главный вызов: если все сайты клиента используют одну и ту же частную автономную систему (например, AS 65100), то при получении маршрута удалённый CE отбросит его по правилу loop prevention (обнаружив свой номер AS в AS_PATH). Для решения этой проблемы на PE оператора включается функция as-override, которая заменяет номер AS клиента на номер AS оператора перед отправкой на CE.

Роль протокола PE-CE

PE-CE протокол выполняет два действия: передаёт клиентские маршруты в VRF (PE выучил префиксы CE) и принимает маршруты из VRF к CE (PE отдал префиксы удалённых сайтов). Между собой PE обмениваются маршрутами только через MP-BGP, поэтому любой клиентский протокол на PE нужно переиздать в BGP (redistribute/import-route/export policy) и в обратную сторону - из BGP в клиентский протокол. Провайдер не обязан использовать тот же протокол, что у клиента, но обязан сохранить смысл маршрутов.

Статика

Самый предсказуемый вариант: ip route vrf A <prefix> <next-hop> на PE и default на CE. Статические маршруты не создают соседей и не зависят от таймеров, но не реагируют на падение CE: нужен BFD (static-route track) или ip route ... track. В BGP они попадают через redistribute static; без него клиентская сеть не покинет PE. Для больших стендов практикуют явный allowlist (route-map/policy) на экспорт, иначе случайный static станет клиентским маршрутом.

eBGP PE-CE и проблема одинаковых AS

eBGP - наиболее масштабируемый вариант: у CE есть собственная политика, есть BFD, метки communities, ограничение префиксов. Главная ловушка: все сайты клиента нередко используют один AS (65101). PE2 передаёт маршрут CE2 с AS_PATH 65000 65101, и CE2 отбрасывает его, видя свой AS (loop prevention). Два решения:

  • as-override на PE: при отправке CE PE заменяет в AS_PATH все вхождения AS CE на собственный AS (Cisco neighbor ... as-override, Huawei peer ... substitute-as, Junos as-override в группе). CE не меняют.
  • allowas-in на CE: CE разрешает N вхождений собственного AS (neighbor ... allowas-in 1). Требует правки на клиентской стороне.

Побочный эффект as-override: потеря AS_PATH-защиты от петли. Если у клиента есть backdoor-связь между сайтами, маршрут может вернуться и зациклиться. Защита - Site of Origin (SoO): PE добавляет в маршрут extended community SoO (тип origin) при выучивании от CE; при отправке этому же сайту PE отбрасывает маршруты с тем же SoO. Cisco: set extcommunity soo 65000:11 в route-map на входе от CE; Junos: community origin:65000:11.

OSPF PE-CE: DN-бит, domain-id, sham-link

OSPF в VRF - отдельный экземпляр процесса (router ospf 2 vrf B), с собственной базой LSDB. Маршруты MP-BGP превращаются в LSA на PE:

  • Если OSPF domain-id на обоих PE одинаков, маршрут представляется как межобластной (LSA type 3, Inter-area): CE считает, что сайты в одном домене и предпочитает такой путь по приоритету OSPF (intra/inter-area перед external).
  • Если domain-id разные или отсутствует совпадение, маршрут представляется как LSA type 5 (External, E2 по умолчанию): метрика не наращивается, а приоритет ниже.
  • PE выставляет DN-бит (Down bit) в LSA type 3/5/7 и не принимает LSA с DN-битом из VRF обратно в MP-BGP; для Type 5 используется route tag. Это защищает от петли между PE через клиента.
  • Backdoor link: если между сайтами есть прямой OSPF-линк (area 0), клиент предпочтёт его (intra-area) пути через MPLS (inter-area). Решение - sham-link: виртуальный внутриобластной линк между двумя PE в VRF; его концы - /32-адреса loopback в VRF (не в глобальной таблице), которые анонсируются через MP-BGP, но не через OSPF. Стоимость sham-link (cost) подбирают меньше стоимости backdoor.
  • Требования sham-link: loopback в VRF с /32, распространение этого /32 в BGP, одинаковая area на концах, согласованные cost/hello/dead.

Таймеры и поведение при отказах

  • eBGP PE-CE: keepalive 60/hold 180 по умолчанию на Cisco, меняйте BFD. Без BFD отказ линка скрывается до 3 минут.
  • OSPF: hello 10/dead 40 на broadcast; BFD для OSPF сокращает сходимость.
  • Статика: без track блэкхол до ручного вмешательства.

Выбор протокола

Статика - простые CE и один префикс; eBGP - большинство корпоративных клиентов и multihoming; OSPF - клиент уже имеет OSPF-дизайн, а sham-link решает проблему backdoor. RIP/EIGRP используют редко; логика переноса в MP-BGP та же.

Метрики и атрибуты через VPN

BGP MED/AS_PATH сохраняются при передаче между PE, но в VRF routing LP, MED и community переписываются политикой. Для OSPF метрика при переносе из BGP может быть задана явно (metric в redistribute), иначе берётся стандартная.

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