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

Carrier Supporting Carrier (CsC, RFC 4364, раздел 9) - иерархия, в которой backbone-оператор продаёт MPLS VPN другому оператору (customer carrier). Тот строит поверх этого свои L3VPN или интернет-услуги, не арендуя выделенные линии между площадками. Для backbone клиентский оператор - это CE в VRF; в VRF лежат только его внутренние маршруты (loopback-и PE/RR и адреса линков), а не маршруты конечных абонентов. Поэтому PE backbone не может выбирать пакет по IP: на линке PE-CE ходят помеченные пакеты, и метки для внутренних префиксов выдаются через eBGP с метками (IPv4+label, RFC 8277/3107) или через LDP в VRF. Стек в ядре backbone: транспортная метка backbone (LDP/SR), VPN-метка backbone для loopback-а клиентского оператора и внутренняя VPN-метка клиентского оператора, которая идёт без изменений. Ядро backbone ничего не знает о маршрутах конечных абонентов.

Кто есть кто в CsC

Carrier Supporting Carrier (RFC 4364, раздел 9) - услуга MPLS VPN, в которой клиентом является другой оператор. Backbone carrier (AS 65000: PE1 10.255.0.1, PE2 10.255.0.2, RR 10.255.0.100) продаёт customer carrier (AS 65001) связь между его площадками. Роутеры клиентского оператора на границе (CE1 172.16.10.2 и CE2 172.16.20.2 - для backbone они CE, для клиентского оператора - его собственные P/PE/ASBR) подключены к VRF CSC-CUST на PE1 и PE2. У клиентского оператора есть свои абоненты и VPN: backbone-оператору не нужно знать ни их адреса, ни их количество.

Зачем это нужно и что экономится

Если клиентский оператор просто арендует L3VPN у backbone, ему придётся отдавать PE backbone все префиксы своих клиентов (сотни тысяч маршрутов, перекрывающиеся адреса, полный Internet). В CsC backbone видит только внутренние маршруты клиентского оператора: loopback его PE/RR (десятки /32), адреса стыков. Таблица в VRF CSC-CUST маленькая, а клиентские VPN идут как "вложенный" MPLS внутри туннеля backbone. Это иерархия: клиентский оператор строит свои LSP и VPN поверх LSP backbone.

Почему на стыке PE-CE нужны метки

Пакет клиентского оператора идёт с меткой: [метка LSP клиентского оператора | его VPN-метка | IP]. PE1 не знает адресов абонентов и не может сделать IP lookup в VRF: пакеты нужно коммутировать по метке. Поэтому PE1 и CE1 обмениваются метками для префиксов внутри VRF:

  • eBGP с метками (IPv4 + label, RFC 8277/3107): neighbor ... send-label в address-family ipv4 vrf (Cisco), peer ... label-route-capability (Huawei), family inet labeled-unicast в группе внутри routing-instance (Junos). На интерфейсе включается пересылка с метками: mpls bgp forwarding (Cisco), mpls (Huawei), family mpls (Junos).
  • IGP/LDP в VRF: на PE-CE работает IGP (OSPF/RIP/статика) плюс LDP; PE перераспределяет IGP-маршруты клиентского оператора в MP-BGP. LDP на VRF-интерфейсе требует, чтобы LDP router-id был достижим из VRF.

Обычно выбирают eBGP: один протокол несёт и префикс, и метку, масштабируется и фильтруется политиками.

Стек меток по участкам пути

Пусть абонент за PE-cust1 (10.200.0.1/32 за CE1) шлёт трафик абоненту за PE-cust2 (10.200.0.2/32 за CE2):
| Участок | Стек меток (сверху вниз) | Кто выдал |
|---|---|---|
| CE1 -> PE1 | метка PE1 для 10.200.0.2/32, VPN-метка клиентского оператора | PE1 (eBGP-LU), PE-cust2 |
| PE1 -> P1 -> PE2 | транспортная LDP к PE2, VPN-метка backbone для 10.200.0.2/32, VPN-метка клиентского оператора | LDP backbone, PE2 (MP-BGP), PE-cust2 |
| PE2 -> CE2 | метка CE2 для 10.200.0.2/32 (если не implicit-null), VPN-метка клиентского оператора | CE2 (eBGP-LU), PE-cust2 |
В ядре backbone три метки (12 байт), на стыке PE-CE - две. P-роутеры видят только верхнюю метку и ничего не знают ни о CsC, ни о клиентах клиентского оператора. Внутренняя VPN-метка клиентского оператора проходит весь путь без изменений: её ставит и снимает только его собственный PE.

Control plane по шагам

  1. CE1 анонсирует по eBGP (AS 65001) loopback 10.200.0.1/32 и метку; PE1 помещает префикс в VRF CSC-CUST.
  2. PE1 экспортирует префикс в VPNv4 с RD 65000:50, RT 65000:500 и с VPN-меткой backbone; PE2 импортирует его в свою VRF CSC-CUST.
  3. PE2 анонсирует префикс CE2 по eBGP-LU с новой меткой; одинаковый AS 65001 на обоих сайтах - нужен as-override на PE2 (Huawei substitute-as) либо allowas-in на CE.
  4. Клиентский оператор устанавливает свой iBGP/MP-BGP между PE-cust1 и PE-cust2 по loopback; транспорт для него - LSP, созданный на шагах 1-3.

Масштаб и ограничения

  • На PE backbone в VRF CSC-CUST - только инфраструктура клиентского оператора: сотни префиксов вместо миллионов. Ограничьте приём maximum-prefix (Huawei route-limit, Junos prefix-limit) и фильтром на разрешённые /32.
  • Один VRF можно использовать для одного клиентского оператора; все его VPN проходят внутри этого VRF прозрачно.
  • Метки на PE-CE выдаются на каждый префикс: слишком много префиксов в VRF исчерпывают label space платформы.
  • MTU: CsC добавляет метки; для клиентских пакетов 1500 байт нужен backbone MTU не меньше 1500 + 12 (три метки) + L2.
  • QoS: EXP/TC клиентской метки копируется на верхние метки только если настроена политика; по умолчанию backbone классифицирует по верхней метке.