Linux MPLS: различия между версиями

Материал из noname.com.ua
Перейти к навигацииПерейти к поиску
 
(не показано 30 промежуточных версий этого же участника)
Строка 10: Строка 10:
 
В век взаимного огораживания, даже техническую документацию приходится доставать через VPN, по этой причине я совершенно не стесняюсь копировать, но всегда оставляю ссылку на источник.
  
В век взаимного огораживания, даже техническую документацию приходится доставать через VPN, по этой причине я совершенно не стесняюсь копировать, но всегда оставляю ссылку на источник.
   
−
=Что нужно понимать прежде чем начасть=
 +
=Что нужно понимать прежде чем начать=
  +
* MPLS НЕ ЗАМЕНЯЕТ маршрутизацию. Пути MPLS строятся на основе уже существующей информации о маршрутах
−
* ????
  
  +
* Если просто включить MPLS то несмотря на дополнительные заголовки, путь прохождения трафика не изменится
  +
* MPLS - коммутация по меткам. Суть (без деталей простая)
  +
** Маршруты метятся метками
  +
** Роутеры "знают" какую метку использовать для достижения какого маршрута
  +
** Все, вместо того что бы смотреть в таблицу маршрутизации смотрим в таблицу меток, экономими СPU и память
   
 
=Пример топологии (для примеров)=
  
=Пример топологии (для примеров)=
Строка 19: Строка 24:
 
==<code>Label</code>==
  
==<code>Label</code>==
 
<code>Label</code> — метка — значение от 0 до 1 048 575. <BR>
  
<code>Label</code> — метка — значение от 0 до 1 048 575. <BR>
  +
На основе неё <code>[[Linux_MPLS#LSR_.E2.80.94_Label_Switch_Router|LSR]]</code>
−
На основе неё LSR принимает решение, что с пакетом делать:
  
  +
принимает решение, что с пакетом делать:
 
какую новую метку повешать, куда его передать.
  
какую новую метку повешать, куда его передать.
 
<BR>
  
<BR>
Строка 43: Строка 49:
 
<code>Swap Label</code> — операция замены метки — происходит на промежуточных маршрутизаторах в сети MPLS — узел получает пакет с одной меткой, меняет её и отправляет с другой
  
<code>Swap Label</code> — операция замены метки — происходит на промежуточных маршрутизаторах в сети MPLS — узел получает пакет с одной меткой, меняет её и отправляет с другой
   
−
==Pop Label==
 +
==<code>Pop Label</code>==
−
Pop Label — операция удаления метки — выполняется последним маршрутизатором — узел получает пакет MPLS и убирает верхнюю метку перед передачей его дальше (R6).
 +
<code>Pop Label</code> — операция удаления метки — выполняется последним маршрутизатором — узел получает пакет MPLS и убирает верхнюю метку перед передачей его дальше.
  +
<BR>
 
На самом деле метка может добавляться и удаляться где угодно внутри сети MPLS.
  
На самом деле метка может добавляться и удаляться где угодно внутри сети MPLS.
−
Всё зависит от конкретных сервисов. Правильнее будет сказать, что метка добавляется первым маршрутизатором пути (LSP), а удаляется последним.
 +
Всё зависит от конкретных сервисов.
  +
<BR>
−
Но в этой статье для простоты мы будем говорить о границах сети MPLS.
  
  +
Правильнее будет сказать, что метка добавляется первым маршрутизатором пути (LSP), а удаляется последним.
−
Кроме того, удаление верхней метки ещё не означает, что остался чистый IP-пакет, если речь идёт о стеке меток. То есть если над пакетом с тремя метками совершили операцию Pop Label, то меток осталось две и дальше он по-прежнему обрабатывается, как MPLS. А в нашем примере была одна, а после не останется ни одной — и это уже дело IP.
  
  +
<BR>
−
==LSR — Label Switch Router==
  
  +
Кроме того, удаление верхней метки ещё не означает, что остался чистый IP-пакет, если речь идёт о стеке меток. То есть если над пакетом с тремя метками совершили операцию Pop Label, то меток осталось две и дальше он по-прежнему обрабатывается, как MPLS. <BR>
−
LSR — Label Switch Router — это любой маршрутизатор в сети MPLS. Называется он так, потому что выполняет какие-то операции с метками. В нашем примере это все узлы: R1, R2, R3, R4, R5, R6.
  
  +
−
LSR делится на 3 типа:
  
  +
==<code>LSR</code> — <code>Label Switch Router</code>==
−
Intermediate LSR — промежуточный маршрутизатор MPLS — он выполняет операцию Swap Label (R2, R5).
  
−
Ingress LSR — «входной», первый маршрутизатор MPLS — он выполняет операцию Push Label (R1).
 +
<code>LSR</code> — Label Switch Router — это любой маршрутизатор в сети MPLS. Называется он так, потому что выполняет какие-то операции с метками.
  +
<code>LSR</code> делится на 3 типа:
−
Egress LSR — «выходной», последний маршрутизатор MPLS — он выполняет операцию Pop Label (R6).
  
  +
* <code>Intermediate LSR</code> — промежуточный маршрутизатор MPLS — он выполняет операцию Swap Label
−
LER — Label Edge Router — это маршрутизатор на границе сети MPLS.
  
  +
* <code>Ingress LSR</code> — «входной», первый маршрутизатор MPLS — он выполняет операцию Push Label
  +
* <code>Egress LSR</code> — «выходной», последний маршрутизатор MPLS — он выполняет операцию Pop Label
  +
<code>LER</code> — Label Edge Router — это маршрутизатор на границе сети MPLS.
 
В частности Ingress LSR и Egress LSR являются граничными, а значит они тоже LER.
  
В частности Ingress LSR и Egress LSR являются граничными, а значит они тоже LER.
  +
 
==LSP — Label Switched Path==
  
==LSP — Label Switched Path==
 
LSP — Label Switched Path — путь переключения меток.
 
LSP — Label Switched Path — путь переключения меток.
   
−
Это однонаправленный канал от Ingress LSR до Egress LSR, то есть путь, по которому фактически пройдёт пакет через MPLS-сеть.
+
Это однонаправленный канал от Ingress <code>[[Linux_MPLS#LSR_.E2.80.94_Label_Switch_Router|LSR]]</code> до Egress <code>[[Linux_MPLS#LSR_.E2.80.94_Label_Switch_Router|LSR]]</code>, то есть путь, по которому фактически пройдёт пакет через MPLS-сеть.
−
Иными словами — это последовательность LSR.
 +
Иными словами — это последовательность <code>[[Linux_MPLS#LSR_.E2.80.94_Label_Switch_Router|LSR]]</code>.
−
Важно понимать, что LSP на самом деле однонаправленный. Это означает, что, во-первых, трафик по нему передаётся только в одном направлении, во-вторых, если существует «туда», не обязательно существует «обратно», в-третьих, «обратно» не обязательно идёт по тому же пути, что «туда». Ну, это как туннельные интерфейсы в GRE.
 +
Важно понимать, что LSP на самом деле однонаправленный. Это означает, что, во-первых, трафик по нему передаётся только в одном направлении, во-вторых, если существует «туда», не обязательно существует «обратно», в-третьих, «обратно» не обязательно идёт по тому же пути, что «туда».
  +
Ну, это как туннельные интерфейсы в GRE.
 
<BR>
  
<BR>
−
Как выглядит LSP?
  
   
  +
==<code>FE</code>C — Forwarding Equivalence Class==
−
Да, вот так непрезентабельно.
  
  +
И одно из самых важный понятий, с которым необходимо разобраться — FEC — Forwarding Equivalence Class.
−
Это компилированный вывод с четырёх LSR — R1, R2, R5, R6. То есть на LSR вы не увидите законченной последовательности узлов от входа до выхода, по типу атрибута AS-PATH в BGP. Здесь каждый узел знает только входную и выходную метки. Но LSP при этом существует.
  
  +
−
Это похоже немного на IP-маршрутизацию. Несмотря на то, что существует путь от точки А до точки Б, таблица маршрутизации знает только следующий узел, куда надо отправлять трафик. Но разница в том, что LSR не принимает решение о каждом пакете на основе адреса назначения — путь определён заранее.
  
  +
Мне оно почему-то давалось очень тяжело, хотя по сути — всё просто. FEC — это классы трафика.
−
==FEC — Forwarding Equivalence Class==
  
  +
−
И одно из самых важный понятий, с которым необходимо разобраться — FEC — Forwarding Equivalence Class. Мне оно почему-то давалось очень тяжело, хотя по сути — всё просто. FEC — это классы трафика. В простейшем случае идентификатором класса является адресный префикс назначения (грубо говоря, IP-адрес или подсеть назначения).
  
  +
В простейшем случае идентификатором класса является адресный префикс назначения (грубо говоря, IP-адрес или подсеть назначения).
  +
 
Например, есть потоки трафика от разных клиентов и разных приложений, которые идут все на один адрес — все эти потоки принадлежат одному классу — одному FEC — используют один LSP.
  
Например, есть потоки трафика от разных клиентов и разных приложений, которые идут все на один адрес — все эти потоки принадлежат одному классу — одному FEC — используют один LSP.
 
Если мы возьмём другие потоки от других клиентов и приложений на другой адрес назначения — это будет соответственно другой класс и другой LSP.
  
Если мы возьмём другие потоки от других клиентов и приложений на другой адрес назначения — это будет соответственно другой класс и другой LSP.
−
В теории помимо адреса назначения FEC может учитывать, например, метки QoS, адрес источника, идентификатор VPN или тип приложений. Важно понимать тут, что пакеты одного FEC не обязаны следовать на один и тот же адрес назначения. И в то же время, если даже и два пакета следуют в одно место, не обязательно они будут принадлежать одному FEC.
  
−
Я поясню для чего всё это нужно. Дело в том, что для каждого FEC выбирается свой LSP — свой путь через сеть MPLS. И тогда, например, для WEB-сёрфинга вы устанавливаете приоритет QoS BE — это будет один FEC — а для VoIP — EF — другой FEC. И далее можно указать, что для FEC BE LSP должен идти широким, но долгим и негарантированным путём, а для FEC EF — можно узким, но быстрым.
  
−
К сожалению или к счастью, но сейчас в качестве FEC может выступать только IP-префикс. Такие вещи, как маркировка QoS не рассматриваются.
  
−
Если вы обратите внимание на таблицу меток, FEC там присутствует, поскольку параметры замены меток определяются как раз таки на основе FEC, но делается это только в первый момент времени — когда эти метки распределяются. Когда же по LSP бежит реальный трафик, никто, кроме Ingress LSR, уже не смотрит на него — только метки и интерфейсы. Всю работу по определению FEC и в какой LSP отправить трафик берёт на себя Ingress LSR — получив чистый пакет, он его анализирует, проверяет какому классу тот принадлежит и навешивает соответствующую метку. Пакеты разных FEC получат разные метки и будут отправлены в соответствующие интерфейсы. Пакеты одного FEC получают одинаковые метки.
  
−
То есть промежуточные LSR — это молотилки, которые для всего транзитного трафика только и делают, что переключают метки. А всю интеллектуальную работу выполняют Ingress LSR.
  
   
  +
''Вот тут стоит остановиться и считать в первом приближении FEC аналогом понятия префикса''.
−
==LIB — Label Information Base==
  
  +
−
LIB — Label Information Base — таблица меток. Аналог таблицы маршрутизации (RIB) в IP. В ней указано для каждой входной метки, что делать с пакетом — поменять метку или снять её и в какой интерфейс отправить.
  
  +
−
==LFIB — Label Forwarding Information Base==
  
  +
{{#spoiler:show=Пространные, но на мой взгляд не очень полезные рассуждения|
−
LFIB — Label Forwarding Information Base — по аналогии с FIB — это база меток, к которой обращается сетевой процессор. При получении нового пакета нет нужды обращаться к CPU и делать lookup в таблицу меток — всё уже под рукой.
  
  +
В теории помимо адреса назначения FEC может учитывать, например, метки QoS, адрес источника, идентификатор VPN или тип приложений.
  +
Важно понимать тут, что пакеты одного FEC не обязаны следовать на один и тот же адрес назначения. И в то же время, если даже и два пакета следуют в одно место, не обязательно они будут принадлежать одному FEC.
  +
Я поясню для чего всё это нужно.
  +
  +
Дело в том, что для каждого FEC выбирается свой LSP — свой путь через сеть MPLS.
  +
И тогда, например, для WEB-сёрфинга вы устанавливаете приоритет QoS BE — это будет один FEC — а для VoIP — EF — другой FEC.
  +
  +
И далее можно указать, что для FEC BE LSP должен идти широким, но долгим и негарантированным путём, а для FEC EF — можно узким, но быстрым.
  +
  +
К сожалению или к счастью, но сейчас в качестве FEC может выступать только IP-префикс.
  +
Такие вещи, как маркировка QoS не рассматриваются.
  +
Если вы обратите внимание на таблицу меток, FEC там присутствует, поскольку параметры замены меток определяются как раз таки на основе FEC, но делается это только в первый момент времени — когда эти метки распределяются. Когда же по LSP бежит реальный трафик, никто, кроме Ingress <code>[[Linux_MPLS#LSR_.E2.80.94_Label_Switch_Router|LSR]]</code>, уже не смотрит на него — только метки и интерфейсы. Всю работу по определению FEC и в какой LSP отправить трафик берёт на себя Ingress LSR — получив чистый пакет, он его анализирует, проверяет какому классу тот принадлежит и навешивает соответствующую метку. Пакеты разных FEC получат разные метки и будут отправлены в соответствующие интерфейсы. Пакеты одного FEC получают одинаковые метки.
  +
То есть промежуточные <code>[[Linux_MPLS#LSR_.E2.80.94_Label_Switch_Router|LSR]]</code> — это молотилки, которые для всего транзитного трафика только и делают, что переключают метки. А всю интеллектуальную работу выполняют Ingress <code>[[Linux_MPLS#LSR_.E2.80.94_Label_Switch_Router|LSR]]</code>.
  +
}}
  +
  +
==<code>LIB</code> — Label Information Base==
  +
<code>LIB</code> — Label Information Base — таблица меток. Аналог таблицы маршрутизации (RIB) в IP.
  +
  +
В ней указано для каждой входной метки, что делать с пакетом — поменять метку или снять её и в какой интерфейс отправить.
  +
  +
==<code>LFIB</code> — Label Forwarding Information Base==
  +
LFIB — Label Forwarding Information Base — по аналогии с FIB — это база меток, к которой обращается сетевой процессор.
  +
  +
При получении нового пакета нет нужды обращаться к CPU и делать lookup в таблицу меток — всё уже под рукой.
  +
  +
Тут нужно понимать что Routing Table содержит все известные маршруты, в том числе и не оптимальные (и соответвенно не активные) а FIB - только те маршруты которые активны. Это же актуально и для LIB/LFIB
  +
  +
{{#spoiler:show=Дополнительная информация|
 
Одна из первоначальных идей MPLS — максимально разнести Control Plane и Data Plane — ушла в небытие.
  
Одна из первоначальных идей MPLS — максимально разнести Control Plane и Data Plane — ушла в небытие.
 
Разработчикам хотелось, чтобы при передаче пакета через маршрутизатор не было никакого анализа — просто прочитал метку, поменял на другую, передал в нужный интерфейс. Чтобы добиться этого, как раз и было два разнесённых процесса — относительно долгое построение пути (Control Plane) и быстрая передача по этому пути трафика (Data Plane)
  
Разработчикам хотелось, чтобы при передаче пакета через маршрутизатор не было никакого анализа — просто прочитал метку, поменял на другую, передал в нужный интерфейс. Чтобы добиться этого, как раз и было два разнесённых процесса — относительно долгое построение пути (Control Plane) и быстрая передача по этому пути трафика (Data Plane)
 
Но с появлением дешёвых чипов (ASIC, FPGA) и механизма FIB обычная IP-передача тоже стала быстрой и простой.
  
Но с появлением дешёвых чипов (ASIC, FPGA) и механизма FIB обычная IP-передача тоже стала быстрой и простой.
 
Для маршрутизатора без разницы, куда смотреть при передаче пакета — в FIB или в LFIB.
  
Для маршрутизатора без разницы, куда смотреть при передаче пакета — в FIB или в LFIB.
−
А вот что, несомненно, важно и полезно — так это, что безразличие MPLS к тому, что передаётся под его заголовком — IP, Ethernet, ATM. Не нужно городить GRE или какие-то другие до боли в суставах неудобные VPN. Но об этом ещё поговорим.
 +
А вот что, несомненно, важно и полезно — так это, что безразличие MPLS к тому, что передаётся под его заголовком — IP, Ethernet, ATM.
  +
Не нужно городить GRE или какие-то другие до боли в суставах неудобные VPN. Но об этом ещё поговорим.
  +
}}
  +
  +
=Практика=
  +
Есть вот такая схема
  +
[[Файл:MPLS LAB1.drawio.png]]
  +
<BR>
  +
Все маршрутизаторы в примере - FRR
  +
<BR>
  +
==Linux==
  +
{{caution|text=
  +
Рекомендую убедиться что все настройки сделаны верно и перезагрузить роутер что бы убедиться что ничего не забыли вписать в конфиг (не повторяйте мою ошибку)
  +
}}
  +
Для того что бы включить поддержку требуется сделать следующее (некоторые шаги не обязательны)
  +
===Отключить ipv6===
  +
<code>/etc/default/grub.d/50-cloudimg-settings.cfg</code>
  +
<PRE>
  +
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 ipv6.disable=1"
  +
</PRE>
  +
===Загрузка модулей===
  +
<code>/etc/modules-load.d/mpls.conf</code>
  +
<PRE>
  +
mpls_router
  +
mpls_iptunnel
  +
mpls_gso
  +
</PRE>
  +
===Форвардинг и включение поддержки MPLSна интерфейсах===
  +
<code>/etc/sysctl.d/11-network.conf</code>
  +
<PRE>
  +
net.ipv4.ip_forward = 1
  +
  +
net.ipv6.conf.default.disable_ipv6 = 1
  +
net.ipv6.conf.all.disable_ipv6 = 1
  +
  +
  +
net.mpls.conf.ens3.input = 1
  +
net.mpls.conf.ens4.input = 1
  +
net.mpls.conf.ens6.input = 1
  +
net.mpls.conf.loopback0.input = 1
  +
net.mpls.platform_labels = 1048575
  +
</PRE>
  +
* <code>net.mpls.conf.ens3.input = 1</code> - тут имя инерфейса <code>ens3</code> ДО переименования netplan, далее этот же интерфейс уже фигурирует с именем set-name: <code>"br-p1-p2"</code>
  +
  +
<PRE>
  +
network:
  +
version: 2
  +
dummy-devices:
  +
loopback0:
  +
addresses:
  +
- 192.168.32.11/32
  +
ethernets:
  +
ens3:
  +
dhcp4: false
  +
dhcp6: false
  +
set-name: "br-p1-p2"
  +
match:
  +
macaddress: "00:99:00:00:10:10"
  +
addresses: ["192.168.40.5/30"]
  +
</PRE>
  +
  +
=Базовая маршрутизация между маршрутизаторами=
  +
На всех маршрутизаторах на всех интерфейсах которые подключены к другим маршрутизаторам включить OSPF
  +
В файле<code> /etc/frr/daemons</code>
  +
<PRE>
  +
ospfd=yes
  +
</PRE>
  +
Можно сразу (для будущего использования)
  +
<PRE>
  +
ldpd=yes
  +
bgpd=yes
  +
</PRE>
  +
  +
<BR>
  +
Редистрибьюция нужна что бы маршрут/адрес на Loopback0 попал в OSPF но конечно можно сделать проще - <code> network 192.168.32.11/32 area 0</code>, я не знаю какой способ более правильный <BR>
  +
  +
Конфиг разделен на логические блоки
  +
<PRE>
  +
hostname p-frr-1.home
  +
  +
ip prefix-list REDISTRIBUTE-KERNEL-TO-OSPF-LOOPBACK-BLOCK seq 10 permit 192.168.32.0/24 ge 32
  +
ip prefix-list REDISTRIBUTE-STATIC-TO-OSPF-LOOPBACK-BLOCK seq 10 permit 192.168.32.0/24 ge 32
  +
ip prefix-list REDISTRIBUTE-CONNECTED-TO-OSPF-LOOPBACK-BLOCK seq 10 permit 192.168.32.0/24 ge 32
  +
!
  +
</PRE>
  +
<PRE>
  +
!
  +
interface br-p1-p2
  +
no ip ospf passive
  +
exit
  +
!
  +
interface br-p3-p1
  +
no ip ospf passive
  +
exit
  +
!
  +
interface frr
  +
no ip ospf passive
  +
exit
  +
!
  +
<PRE>
  +
router ospf
  +
ospf router-id 192.168.32.11
  +
redistribute kernel route-map REDISTRIBUTE-KERNEL-TO-OSPF
  +
redistribute connected route-map REDISTRIBUTE-CONNECTED-TO-OSPF
  +
redistribute static route-map REDISTRIBUTE-STATIC-TO-OSPF
  +
passive-interface default
  +
network 192.168.40.0/30 area 0
  +
network 192.168.40.4/30 area 0
  +
network 192.168.40.8/30 area 0
  +
exit
  +
</PRE>
  +
<PRE>
  +
route-map REDISTRIBUTE-KERNEL-TO-OSPF permit 10
  +
match ip address prefix-list REDISTRIBUTE-KERNEL-TO-OSPF-LOOPBACK-BLOCK
  +
exit
  +
!
  +
route-map REDISTRIBUTE-STATIC-TO-OSPF permit 10
  +
match ip address prefix-list REDISTRIBUTE-STATIC-TO-OSPF-LOOPBACK-BLOCK
  +
exit
  +
!
  +
route-map REDISTRIBUTE-CONNECTED-TO-OSPF permit 10
  +
match ip address prefix-list REDISTRIBUTE-CONNECTED-TO-OSPF-LOOPBACK-BLOCK
  +
exit
  +
</PRE>
  +
  +
После того как OSPF запусттился, обнаружил соседей и законфил процесс схождения, каждый из маршрутизаторов сможет пинговать loopback любого другого, и все адреса в area0
  +
  +
Отличия на других маршрутизаторах
  +
* <code>network 192.168.40.0/30 area 0</code> - сети соответвующие маршрутизатору, везде /30
  +
* <code> ospf router-id 192.168.32.11</code> - уникальный идентификатор роутера, это адрес loopback интерфейса
   
  +
=MPLS=
 
=Ссылки=
  
=Ссылки=
 
* https://habr.com/ru/articles/884824/
  
* https://habr.com/ru/articles/884824/

Текущая версия на 15:54, 6 мая 2025

MPLS в Linux/FRR и не только

Статья основана на Вот этой отличной статье про FRR (в основном) но с некоторыми моими доработками и пояснениями

так же я активно копировал (но внимательно читал и исправлял на более понятные мне формулировки) из https://linkmeup.ru/blog/

В век взаимного огораживания, даже техническую документацию приходится доставать через VPN, по этой причине я совершенно не стесняюсь копировать, но всегда оставляю ссылку на источник.

Что нужно понимать прежде чем начать

  • MPLS НЕ ЗАМЕНЯЕТ маршрутизацию. Пути MPLS строятся на основе уже существующей информации о маршрутах
  • Если просто включить MPLS то несмотря на дополнительные заголовки, путь прохождения трафика не изменится
  • MPLS - коммутация по меткам. Суть (без деталей простая)
    • Маршруты метятся метками
    • Роутеры "знают" какую метку использовать для достижения какого маршрута
    • Все, вместо того что бы смотреть в таблицу маршрутизации смотрим в таблицу меток, экономими СPU и память

Пример топологии (для примеров)

Терминология

Я намерено опускаю здесь форматы заголовков, так как статья требует некоторого упрощения, так или иначе

Label

Label — метка — значение от 0 до 1 048 575.
На основе неё LSR принимает решение, что с пакетом делать: какую новую метку повешать, куда его передать.
Является частью заголовка MPLS.

Label Stack

Label Stack — стек меток. Стек в значении что они добавляются одна над одной
Каждый пакет может нести одну, две, три, да хоть 10 меток — одну над другой.
(но не каждое оборудование позволяет - могут быть ограничения)
Решение о том, что делать с пакетом принимается на основе верхней метки. Каждый слой играет какую-то свою роль.
Например, при передаче пакета используется транспортная метка, то есть метка, организующая транзит от первого до последнего маршрутизатора MPLS.
Другие могут нести информацию о том, что данный пакет принадлежит определённому VPN.
Прямой вывод - более чем 2 метки используются редко

Push Label

Push Label — операция добавления метки к пакету данных — совершается в самом начале — на первом маршрутизаторе в сети MPLS

Swap Label

Swap Label — операция замены метки — происходит на промежуточных маршрутизаторах в сети MPLS — узел получает пакет с одной меткой, меняет её и отправляет с другой

Pop Label

Pop Label — операция удаления метки — выполняется последним маршрутизатором — узел получает пакет MPLS и убирает верхнюю метку перед передачей его дальше.
На самом деле метка может добавляться и удаляться где угодно внутри сети MPLS. Всё зависит от конкретных сервисов.
Правильнее будет сказать, что метка добавляется первым маршрутизатором пути (LSP), а удаляется последним.
Кроме того, удаление верхней метки ещё не означает, что остался чистый IP-пакет, если речь идёт о стеке меток. То есть если над пакетом с тремя метками совершили операцию Pop Label, то меток осталось две и дальше он по-прежнему обрабатывается, как MPLS.

LSR — Label Switch Router

LSR — Label Switch Router — это любой маршрутизатор в сети MPLS. Называется он так, потому что выполняет какие-то операции с метками. LSR делится на 3 типа:

  • Intermediate LSR — промежуточный маршрутизатор MPLS — он выполняет операцию Swap Label
  • Ingress LSR — «входной», первый маршрутизатор MPLS — он выполняет операцию Push Label
  • Egress LSR — «выходной», последний маршрутизатор MPLS — он выполняет операцию Pop Label

LER — Label Edge Router — это маршрутизатор на границе сети MPLS. В частности Ingress LSR и Egress LSR являются граничными, а значит они тоже LER.

LSP — Label Switched Path

LSP — Label Switched Path — путь переключения меток.

Это однонаправленный канал от Ingress LSR до Egress LSR, то есть путь, по которому фактически пройдёт пакет через MPLS-сеть. Иными словами — это последовательность LSR. Важно понимать, что LSP на самом деле однонаправленный. Это означает, что, во-первых, трафик по нему передаётся только в одном направлении, во-вторых, если существует «туда», не обязательно существует «обратно», в-третьих, «обратно» не обязательно идёт по тому же пути, что «туда». Ну, это как туннельные интерфейсы в GRE.

FEC — Forwarding Equivalence Class

И одно из самых важный понятий, с которым необходимо разобраться — FEC — Forwarding Equivalence Class.

Мне оно почему-то давалось очень тяжело, хотя по сути — всё просто. FEC — это классы трафика.

В простейшем случае идентификатором класса является адресный префикс назначения (грубо говоря, IP-адрес или подсеть назначения).

Например, есть потоки трафика от разных клиентов и разных приложений, которые идут все на один адрес — все эти потоки принадлежат одному классу — одному FEC — используют один LSP. Если мы возьмём другие потоки от других клиентов и приложений на другой адрес назначения — это будет соответственно другой класс и другой LSP.

Вот тут стоит остановиться и считать в первом приближении FEC аналогом понятия префикса.


LIB — Label Information Base

LIB — Label Information Base — таблица меток. Аналог таблицы маршрутизации (RIB) в IP.

В ней указано для каждой входной метки, что делать с пакетом — поменять метку или снять её и в какой интерфейс отправить.

LFIB — Label Forwarding Information Base

LFIB — Label Forwarding Information Base — по аналогии с FIB — это база меток, к которой обращается сетевой процессор.

При получении нового пакета нет нужды обращаться к CPU и делать lookup в таблицу меток — всё уже под рукой.

Тут нужно понимать что Routing Table содержит все известные маршруты, в том числе и не оптимальные (и соответвенно не активные) а FIB - только те маршруты которые активны. Это же актуально и для LIB/LFIB

Практика

Есть вот такая схема MPLS LAB1.drawio.png
Все маршрутизаторы в примере - FRR

Linux

Icon-caution.gif

Рекомендую убедиться что все настройки сделаны верно и перезагрузить роутер что бы убедиться что ничего не забыли вписать в конфиг (не повторяйте мою ошибку)

Для того что бы включить поддержку требуется сделать следующее (некоторые шаги не обязательны)

Отключить ipv6

/etc/default/grub.d/50-cloudimg-settings.cfg 

GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 ipv6.disable=1"

Загрузка модулей

/etc/modules-load.d/mpls.conf 

mpls_router
mpls_iptunnel
mpls_gso

Форвардинг и включение поддержки MPLSна интерфейсах

/etc/sysctl.d/11-network.conf 

net.ipv4.ip_forward = 1

net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.all.disable_ipv6 = 1


net.mpls.conf.ens3.input = 1
net.mpls.conf.ens4.input = 1
net.mpls.conf.ens6.input = 1
net.mpls.conf.loopback0.input = 1
net.mpls.platform_labels = 1048575
  • net.mpls.conf.ens3.input = 1 - тут имя инерфейса ens3 ДО переименования netplan, далее этот же интерфейс уже фигурирует с именем set-name: "br-p1-p2"
network:
    version: 2
    dummy-devices:
        loopback0:
            addresses:
                - 192.168.32.11/32
    ethernets:
        ens3:
            dhcp4: false
            dhcp6: false
            set-name: "br-p1-p2"
            match:
                macaddress: "00:99:00:00:10:10"
            addresses: ["192.168.40.5/30"]

Базовая маршрутизация между маршрутизаторами

На всех маршрутизаторах на всех интерфейсах которые подключены к другим маршрутизаторам включить OSPF В файле /etc/frr/daemons 

ospfd=yes

Можно сразу (для будущего использования) 

ldpd=yes
bgpd=yes


Редистрибьюция нужна что бы маршрут/адрес на Loopback0 попал в OSPF но конечно можно сделать проще - network 192.168.32.11/32 area 0, я не знаю какой способ более правильный

Конфиг разделен на логические блоки 

hostname p-frr-1.home

ip prefix-list REDISTRIBUTE-KERNEL-TO-OSPF-LOOPBACK-BLOCK seq 10 permit 192.168.32.0/24 ge 32
ip prefix-list REDISTRIBUTE-STATIC-TO-OSPF-LOOPBACK-BLOCK seq 10 permit 192.168.32.0/24 ge 32
ip prefix-list REDISTRIBUTE-CONNECTED-TO-OSPF-LOOPBACK-BLOCK seq 10 permit 192.168.32.0/24 ge 32
!

!
interface br-p1-p2
 no ip ospf passive
exit
!
interface br-p3-p1
 no ip ospf passive
exit
!
interface frr
 no ip ospf passive
exit
!
<PRE>
router ospf
 ospf router-id 192.168.32.11
 redistribute kernel route-map REDISTRIBUTE-KERNEL-TO-OSPF
 redistribute connected route-map REDISTRIBUTE-CONNECTED-TO-OSPF
 redistribute static route-map REDISTRIBUTE-STATIC-TO-OSPF
 passive-interface default
 network 192.168.40.0/30 area 0
 network 192.168.40.4/30 area 0
 network 192.168.40.8/30 area 0
exit

route-map REDISTRIBUTE-KERNEL-TO-OSPF permit 10
 match ip address prefix-list REDISTRIBUTE-KERNEL-TO-OSPF-LOOPBACK-BLOCK
exit
!
route-map REDISTRIBUTE-STATIC-TO-OSPF permit 10
 match ip address prefix-list REDISTRIBUTE-STATIC-TO-OSPF-LOOPBACK-BLOCK
exit
!
route-map REDISTRIBUTE-CONNECTED-TO-OSPF permit 10
 match ip address prefix-list REDISTRIBUTE-CONNECTED-TO-OSPF-LOOPBACK-BLOCK
exit

После того как OSPF запусттился, обнаружил соседей и законфил процесс схождения, каждый из маршрутизаторов сможет пинговать loopback любого другого, и все адреса в area0

Отличия на других маршрутизаторах

  • network 192.168.40.0/30 area 0 - сети соответвующие маршрутизатору, везде /30
  • ospf router-id 192.168.32.11 - уникальный идентификатор роутера, это адрес loopback интерфейса

MPLS

Ссылки

Источник — https://noname.com.ua/mediawiki/index.php?title=Linux_MPLS&oldid=14518