MPLS¶

Для усвоения вышеперечисленного материала планирую записывать сюда вольный пересказ этих статей 
с дальнейшим описанием реализации данного функционала на практике… 

Хочу сказать огромное спасибо Маратам за цикл статей СДСМ!!! )

Когда сетевые инженеры достигли совершенства в протоколах динамической маршрутизации, 
то им стало скучно и они решили, что почему бы им не стать на секундочку hardware инженерами 
и не запилить самим коммутаторы и маршрутизаторы на уже существующей основе.

Так и появился MPLS...

P.S. Благо, что новые номера AFI и SAFI преспокойно добавляются в BGP... )))

"LSR – Label Switch Router" – маршрутизаторы, оперирующие метками, которые передают пакеты на основании меток, 
т.е. маршрутизаторы сети MPLS (P, PE)

"Intermediate LSR" они же "P" (Provider) – маршрутизаторы, "молотилки" трафика в MPLS. 
Ничё не умеют, кроме переписывания меток(swap) и перекладывания(forward) пакетов из порта в порт.

"PE – Provider Edge (Engress LSR, Ingress LSR)" – инициируют изначально разбегание новых меток по сети MPLS 
при появления новых FEC.
По сути на PE сосредоточен весь интеллект работы сети MPLS…

"Ingress LSR (тоже PE)" - входной маршрутизатор сети MPLS – 
назначает первоначальную метку для пакета (Push Label) в сети MPLS. 

"Engress LSR (тоже PE)" - выходной маршрутизатор сети MPLS – 
снимает метку для пакета (Pop Label) в сети MPLS и отправляет 
на конечный маршрутизатор абона CE  - Customer Router

"LER – Label Edge Router" – (Ingress LSR, Engress LSR. Они же PE – Provider Edge)

"CE – Client Edge" – клиентский маршрутизатор (на нем уже нет MPLS)

"LSP – Label Switch Path" – путь переключения меток от источника к получателю 
от Ingress LSR до Egress LSR – т.е. это по сути последовательность коммутаторов.
Другими словами LSP - это однонаправленный путь, т.е. путь «туда», 
может не совпадать от пути «оттуда». 
LSP – строится всегда от Egress LSP в сторону Ingress LSP

"FEC – Forwarding Equalence Class" – это эквивалентные классы трафика, 
которые форвардятся использую один и тот же путь в сети MPLS (LSP).

"LIB – Label Information Base" – аналог RIB для IP. 
В LIB указано, какую метку менять на какую и в какой интерфейс отправить 
(рекурсивна, так же как и RIB)

"LFIB – Label Forwarding Information Base" – аналог FIB для IP, находится уже на "Data plane", 
например физически на ASIC-ах линейной карты.

"Label" = 20bit = 2^20= 1048576 – всего меток в MPLS

"TC – Traffic Class" - аналог DSCP в IP  = 3bit =2^3=8 значений

"S – Bottom of Stack" – дно стека меток. Если рано «1» - то больше меток нет, если «0» то есть еще метки дальше

"TTL – Time To Live" – полный аналог IP TTL – 8bit=2^8=255

"DU - Downstream Unsolicited" - как только LSR узнает про новый FEC он тут же 
рассылает всем соседям метки про новые FEC. 
(напоминает механизм PIM SM в мультикасте)

DoD – Downstream on Demand – рассылает метки про новые FEC, только по запросу от соседей.

"Ordered Control" – последовательная отправка инфы, про новые FEC метки, 
когда уже пришла инфа от Egress LSR про метку для данного FEC.

"Independent Control" – подход, когда инфа про новые FEC пересылается неупорядоченно 
даже если не дошла метка для данного FEC со стороны Engress LSR

т.е. "DU-vs-DoD" – это про отправки метки без запроса и по запросу от соседа,
а "OC-vs-IC" – это про отправки меток дожидаясь или не дожидаясь 
метки про данный FEC от соседа со стороны Egress LSR 

"Liberal Label Retention Mode" - Хранит метки для небестовых FEC.

"Conservative Label Retention Mode" - Не Хранит метки для небестовых FEC

"Penultimate Hop Popping (PHP)" – отбрасывание метки на предпоследнем прыжке – 
оптимизация работы MPLS (чтобы не передавать лишний раз метку если известно, что дальше будет последний, 
т.е. Egress LSR в пути следования пакета).
Тут как раз «палится» метка - 3: Implicit Null. Фиктивная метка, которая используется 
для оптимизации процесса передачи пакета MPLS на Egress LSR. 
Эта метка может анонсироваться, но никогда не используется в заголовке MPLS реально.

1.  Данный протокол никак напрямую не использует протоколы IGP 
    (работает в этом плане по принципу PIM)
2.  Не имеет резервных путей
3.  При смене топологии пересчитывается 
    (сначала сходится IGP, потом уже LDP)

"LSA Type 9" — link-local scope
"LSA Type 10" — area-local scope
"LSA Type 11" — AS scope

"L3VPN" – функционал на базе сети MPLS, обеспечивающий прозрачную маршрутизацию для клиента, 
между его филиалами через сеть вышестоящего провайдера.

1.  Клиент передает данные о своих сетях провайдеру 
через один из протоколов маршрутизации ISIS, OSPF, BGP
2.  Провайдер изолирует и передает данные на другую точку присутствия клиента.

Для решения данной задачи используется сеть MPLS, отдельные VRF для точек присутствия клиента 
и через интеграцию посредством протокола BGP в секции «vpnv4 unicast» (AFI=1/SAFI=128) 
передаются от PE точки входа в PE точки выхода (от Ingress PE до Engress PE).

На входе от клиента в сеть провайдера пакету добавляется 
дополнительная метка - сервисная, которая будет идентифицировать пакет при выходе 
из сети MPLS – куда данный пакет в какой VRF форвардить. 

Верхняя метка добавляется как обычно транспортная, которая "пушится" (push), т.е. "добавляется" на входящем «PE», 
"свапается" (swap), т.е. "меняется" на «P» маршрутизаторах сети MPLS 
и "попается" (pop), т.е. "удаляется" на выходном «PE».

Данные о префиксах "клиентских" сетей передаются в BGP Update сообщениях.

Для идентификации уникальности префиксов внутри BGP используется "Router Destignisher", 
уникальный иденитфикатор, который добавляется к префиксу при выходе из VRF. 

Для идентификации передачи префикса в нужный VRF используется идентификатор "Router Target",
с помощью которого префикс передается в таблицу маршрутизации нужного VRF-а. 

R1,R2,R3,R4,R5,R6 – маршрутизаторы сети провайдера
Имеются 3 клиента: C3PO, DARKSIDE, R2D2
"C3PO1(CE)" – подключен в R1(PE)
  ip plan:
  - lo0      - 10.10.10.10/32
  - int f0/0 - 192.168.1.1/24

"C3PO2(CE)" – подключен в R6(PE)
  ip plan:
  - lo0      - 20.20.20.20/32
  - int f0/0 - 192.168.2.1/24

"DARKSIDE1(CE)" – подключен в R1(PE)
 ip plan:
  - lo0      - 11.11.11.11/32
  - int f0/0 - 192.168.1.1/24

"DARKSIDE2 (CE)" – подключен в R6(PE)
 ip plan:
  - lo0      - 22.22.22.22/32
  - int f0/0 - 192.168.2.1/24


"R2D2 (CE)" – подключен в R4(PE)
 ip plan:
  - lo0      - 222.222.222.222/32
  - int f0/0 - 192.168.222.1/24

C3PO и DARKSIDE – не имеют доступа друг к другу
R2D2 и DARKSIDE – не имеют доступа друг к другу
C3PO и R2D2 –имеют связность друг с другом (маршруты ликаются чз взаимный RT import)

C3PO передает маршруты провайдеру по OSPF 
DARKSIDE и R2D2 передает маршруты провайдеру по BGP 
В сети провайдера IGP - ISIS, MPLS - LDP
BGP vpnv4 настроен на R1,R4,R6.

Соответственно для C3PO мы редистрибъютим маршруты между OSPF клиента и BGP провайдера

1. Взаимодействие внутри/между VRF 
  - С3PO - работает по OSPF
  - R2D2 - по BGP

Для организации взаимодействия между разными VRF необходимо "ликать" их маршруты между собой,
для этого используется механизм импорта в VRF

На PE R1, к которому подключен CE C3PO1:

R1#
!
ip vrf C3PO
 rd 64500:100
 route-target export 64500:100
 route-target import 64500:100
 route-target import 64500:300

Комментарии:
 - rd 64500:100 - Это Router Destignisher, который используется как уникальный идентификатор, 
                  при передачи префиксов в BGP Update сообющениях.

 - route-target 64500:100 - это "родной" Route Target VRF C3P0
 - route-target 64500:300 - это  Route Target VRF R2D2

 Соответственно:
 - для импорта добавляются оба-два эти RT - чтобы принимать префиксы от VRF, 
   принадлежащих VRF C3P0 и R2D2
 - для экспорта добавляется RT своего VRF (C3PO)

Аналогичным способом "ликаются" и маршруты и на R4 (PE), к которому подключен R2D2

R4#
!
ip vrf R2D2
 rd 64222:300
 route-target export 64500:300
 route-target import 64500:300
 route-target import 64500:100

Особо обращу тут внимание на то, что rd и rt - это совершенно независимые друг от друга вещи.
В данном случае, RD - вообще мог бы быть произвольным, достаточно, чтобы он был просто уникальным.
А вот RT должен быть именно такой каким его будут импортировть к себе другие VRF-ы. 

Теперь, когда на обоих PE настроено взаимодействие между VRF надо настроить связность между самими PE.

Для этого используется как раз протокол BGP секция vpnv4 (AFI=1/SAFI=128), оно же "L3VPN unicast"

R1#
!
router bgp 64500
 no synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 4.4.4.4 remote-as 64500
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 6.6.6.6 remote-as 64500
 neighbor 6.6.6.6 update-source Loopback0
 no auto-summary
 !
 address-family vpnv4
  neighbor 4.4.4.4 activate
  neighbor 4.4.4.4 send-community both
  neighbor 6.6.6.6 activate
  neighbor 6.6.6.6 send-community both
 exit-address-family
 !
 address-family ipv4 vrf DARKSIDE
  neighbor 192.168.1.1 remote-as 64501
  neighbor 192.168.1.1 activate
  no synchronization
 exit-address-family
 !
 address-family ipv4 vrf C3PO
  redistribute ospf 2 vrf C3PO
  no synchronization
 exit-address-family

 Комментарии:
 - в секция "address-family vpnv4" - перечисляются соседи по BGP для L3VPN, т.е. PE (R4 и К6)
 - Для взаимодействия с клиентами L3VPN по BGP должны передаваться и приниматься маршруты 
   для "родных" протоколов маршрутизации самих клиентов.
   Для C3PO - Это OSPF
   Для DARKSIDE - Это BGP
   Соответственно должен происходить и редистрибьюция маршрутов с клиенского IGP VRF в BGP (PE) и наоборот.
   За этот функционал в нашем, рассматриваемом случае, отвечает секция "address-family ipv4 vrf C3PO"

   "address-family ipv4 vrf C3PO
    redistribute ospf 2 vrf C3PO"

   При чем, обращаю особое внимание, что тип IGP протокола "клиента" L3VPN настраиется и на самом PE маршрутизаторе.

    "router ospf 2 vrf C3PO
     router-id 1.1.1.1
     log-adjacency-changes
     redistribute bgp 64500 subnets
     network 192.168.0.0 0.0.255.255 area 0"

   При этом в OSPF 2 RIB естественно хранятся маршруты известные с C3PO

    "R1#sh ip ospf 2 rib

    OSPF local RIB for Process 2
    Codes: * - Best, > - Installed in global RIB

    *>  10.10.10.10/32, Intra, cost 2, area 0
          via 192.168.1.1, FastEthernet1/0
    *   192.168.1.0/24, Intra, cost 1, area 0, Connected
          via 192.168.1.2, FastEthernet1/0"

1. от R4 на R1 gо BGP приходит BGP Update вида:

где:
- Передается L3VPN unicast (AFI=1/SAFI=128) 
- Передается "RT = 64222:300" в виде BGP Extended Community
- В NLRI содержится 2 префикса "192.168.222.0" и "222.222.222.222", у которых "RD = 64222:300"
- Также для данных префиксов передается сервисная метка, которая сгенерирована на R4:
  - Для префикса "192.168.222.0" она равна 26
  - Для префикса "222.222.222.222" она равна 25
- слово "bottom" в метке означает, что это нижняя метка для R4.

Как видно из LFIB на R4 - всё так и есть:

По CEF на R1 для VRF C3PO видно, что:
- для достижения сети 192.168.222.0/24 нужно добавить две метки "18 и 26" и отправить в интерфейс fa0/0
- для достижения сети 222.222.222.222/32 нужно добавить две метки "18 и 25" и отправить в интерфейс fa0/0

Транспортную метку "18" генерит уже сам R1 по LDP для FEC 4.4.4.4:

Соответственно данные маршруты попали на R1 в VRF C3PO по BGP:

И соответственно данные маршруты попали на CE C3PO по OSPF

Теперь при пинге в C3PO адреса, находящегося на R2D2 на сети MPLS можно увидеть icmp инкапсулированные в MPLS,
как раз с теми самыми транспортыми и сервисыми метками

1.  Должна быть сеть MPLS (LDP или RSVP-TE – без разницы)
2.  Клиент должен передавать анонсы своих сетей через один из протоколов (ISIS, OSPF, BGP) – 
ответочка поднимается на стороне PE.
Если клиентский протокол не BGP, то в него и из него нужно редистрибьютить сети клиента.
3.  На PE с обоих сторон настраивается:
- VRF для данного клиента, туда заносятся RD и RT
- В BGP добавляется секция vpnv4, а также  ipv4 для VRF

1.  NAT – на стороне клиента + static +VRF leak
2.  NAT на стороне PE + static +VRF leak
3.  “Common Service” – жонглирование RT на стороне граничного с инетом маршрутизатора

L2VPN - по сути, это технология организации L2 связности между двумя или более чем двумя точками через вышестоящую сеть провайдера на сети MPLS.

"AToM – Any Transport over MPLS" – возможность инкапсулировать трафик любого канального уровня в MPLS

1.  точка-точка -  VPWS – Virtual Pseudo Wire Service
2.  точка-многоточка - VPLS – Virtual Private LAN Service

VPWS - Point-to-Point – общее название услуги VPWS – Virtual Private Wire Service.
Организации L2 связности между двумя точками через MPLS сеть провайдера.

"PW – Pseudo Wire" – это виртуальный двунаправленный канал передачи данных между двумя PE, 
который состоит из пары однонаправленных VC.

"VC – Virtual Curcuit" - однонаправленное  виртуальное соединение, 
которое соединяет две точки клиента через сеть провайдера, от одной AC, до второй AC.

"AC – Attached Curcuit" – интерфейс на PE для подключения клиента

Знакомые уже определения:
"PE - Provider Edge" – граничный маршрутизатор сети MPLS, к которому подсоединяется клиент

"CE – Client Edge" – оборудование клиента, подключаемое к PE

1.  MPLS сеть обменялась метками между P-PE маршрутизаторами сети по протоколу LDP или RSVP-TE. 
    В нашем случае рассмотрим вариант LDP.
2.  После указание на интерфейсах AC настроек принадлежности интерфейса 
    к xconnect и указанию номера VC с обоих сторон:

    ---------------------------------------------------
    "R1"
    int gi3
     xconnect  4.4.4.4  127 encapsulation mpls

    "R4"
    int gi3
     xconnect 1.1.1.1 127 encapsulation mpls
    ! Важно, чтобы VC ID совпадали
    ---------------------------------------------------

    Тут начинает работать протокол tLDP, который организует связность 
    уже напрямую R1 и R4 коммутаторов по LDP, в отличии от стандарного LDP, 
    который устанавливает связь только с непосредственным соседом, в LDP - TTL=1, 
    в tLDP TTL - уже больше 1 и позволяет проходить через несколько 
    промежуточных маршрутизаторов, по сути организуя туннель 
    между точкой A и точкой B.

    После установки соединения по tLDP передается информация о сервисной метке, 
    чтобы можно было достичь второй стороны.
    Т.о. на кадр пришедший от клиента на R1 навешивается две метки 
    (одна сервисная, которая характеризует xconnect на второй стороне, 
    и транспортной, чтобы кадр передавался на второй xconnect по MPLS сети,
    метки "свапаваются" на P-шках – всё стандартно)...

    Схема работы xconnect весьма проста: 
    - Кадры передаются по сети MPLS с двумя метками сервисной и транспортной. 
    - Сервисная и транспортная метка «пушится» на начальном PE, 
    = Транспортная «свапается» на P маршрутизаторах 
    - Сервисная и транспортная метка «попится» на  конечном PE.

Виды VPWS – их много, то что было описано выше:
- это "EoMPLS" (Ethernet over MPLS), оно же "PWE3" (Pseudo Wire Emulation Edge to Edge)

"VLL (Virtual Leased Line)" — это уже технология, которая позволяет инкапсулировать кадры 
различных протоколов канального уровня в MPLS и передавать их через сеть провайдера.

В природе есть Martini  VLL, Kompella VLL … 
Вообщем? зоопарк – « но, то ли еще будет»…

"VPLS-домен" – изолированная виртуальная L2 сеть.

"VSI" – Virtual Switch Instance – виртуальный коммутатор в пределах одного маршрутизатора 
(аналог VRF – в L3VPN).

"VFI" – Virtual Forwarding Instance - тоже самое, что и VSI, только в терминологии Cisco.

"VE" – Virtual Edge – узел PE, участник VPLS домена.

1. Ручная настройка (Martini draft) – стал дефакто для L2VPN
2. Автоматическая настройка (Kompella draft) – «почил в бозе»…

1.  Создаем VFI с одинаковыми VPN ID на всех PE, входящих в VPLS
2.  Привязываем AC интерфейсы к Service Instance
3.  Объединяем в один Bridge домен VFI и соответствующие Service Inctance

R1#
l2vpn vfi context Blue 
    vpn id 63
    ! R3 является участником данного VPLS (1.1.1.1 - его Loopback)
    member 3.3.3.3 encapsulation mpls
    ! R4 является участником данного VPLS (4.4.4.4 - его Loopback)
    member 4.4.4.4 encapsulation mpls
!
! VC, принадлежащий данному VPLS
int gi3
  ! service instance еще одна абстракция - удобна для объединения сервисов 
    service instance 10 ethernet
    description Blue-A
    encapsulation default
!
! VC, принадлежащий данному VPLS
int gi4
  ! service instance еще одна абстракция - удобна для объединения сервисов - только где? :)
    service instance 12 ethernet
    description Blue-C
    encapsulation default
!
! Объединяем наш VFI и VС в один бридж домен
bridge-domain 255
    member vfi Blue
    member gigabitEthernet 3 service-instance 10
    member gigabitEthernet 4 service-instance 12
!

"VE ID" (настраивается вручную) — это идентификатор PE-маршрутизатора в домене VPLS (его порядковый номер). 
Должен быть уникален в пределах одного VSI.

"LBB" — Label Base — это начало диапазона, первая метка, которая может быть использована.

"VBS" — VE Block Size — это длина блока меток — или проще, минимальное количество меток в этом VSI. 
Для Cisco по умолчанию это 10. Для Juniper — 8 (может быть уменьшен до 2 или увеличен).

"VBO" — VE Block Offset — смещение блока. Используется если меток из одного блока не хватает.

т.е. приняв такие данные соседи для себя выберут метки LDP в зависимости от своего VE ID. 
Т.е. PE с:
 -VE-ID 100 назначит для такого соседа LDP метку 1000
 -VE-ID 101  - это сам PE1
 -VE-ID 102  назначит для такого соседа LDP метку 1002 
и т.д…

Точно также будет и в обратку…

По сути, PE1 передавая свою информацию VE ID, LB, VBS соседям, 
соседи вычисляют какие метки будут приходить от данного PE

В ИТОГЕ получается, что все участники L2VPN знают, что:

"LB 1002" - это метка от PE1 к PE2
"LB 1003" - это метка от PE1 к PE3

"LB 2001" - это метка от PE2 к PE2
"LB 2005" - это метка от PE2 к PE5

"LB 5001" - это метка от PE5 к PE1
"LB 5002" - это метка от PE5 к PE2

R1#
!
l2vpn vfi context Blue 
    vpn id 63 
    autodiscovery bgp signaling bgp 
    ve id 101
!
!Можно задать вручную диапазон динамически назначаемых меток (но это не обязательно)
mpls label range 1000 1999
!
! Назначаем Service instance для AC
int gi3
    service instance 10 ethernet 
    description Blue-A
    encapsulation default
!
int gi4
    service instance 12 ethernet 
    description Blue-C
    encapsulation default 
!
! Связываем VFI и Service Instance в один bridge домен
!
bridge-domain 255
    member vfi Blue
    member gigabitEthernet 3 service-instance 10
    member gigabitEthernet 4 service-instance 12
!

! Настраиваем BGP
!
router bgp 64500 
  neighbor 3.3.3.3 remote-as 64500
  neighbor 3.3.3.3 update-source Loopback 0
  neighbor 4.4.4.4 remote-as 64500
 neighbor 4.4.4.4 update-source Loopback 0

! Cоздаём address-family l2vpn vpls и указываем всех соседей, 
! которые будут участвовать в L2VPN без привязки к VFI 
!
  address-family l2vpn vpls 
        neighbor 3.3.3.3 activate 
        neighbor 3.3.3.3 send-community extended 
        neighbor 3.3.3.3 suppress-signaling-protocol ldp
        neighbor 4.4.4.4 activate 
        neighbor 4.4.4.4 send-community extended 
        neighbor 4.4.4.4 suppress-signaling-protocol ldp

bash
"mesh-group" -это из Juniper-a
...
"Нора" - это из Ибсена...)

"В общем, вариативности и разнообразия сочитаний L2VPN на практике хватает с избытком, исходя из моего практического опыта..."