Linux MPLS: различия между версиями
Sirmax (обсуждение | вклад) |
Sirmax (обсуждение | вклад) (→Ссылки) |
||
| (не показаны 33 промежуточные версии этого же участника) | |||
| Строка 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> |
||
| Строка 25: | Строка 31: | ||
==<code>Label Stack</code>== |
==<code>Label Stack</code>== |
||
| − | Label Stack — стек меток. |
+ | <code>Label Stack</code> — стек меток. Стек в значении что они добавляются одна над одной |
<BR> |
<BR> |
||
Каждый пакет может нести одну, две, три, да хоть 10 меток — одну над другой. <BR> |
Каждый пакет может нести одну, две, три, да хоть 10 меток — одну над другой. <BR> |
||
| Строка 37: | Строка 43: | ||
Прямой вывод - более чем 2 метки используются редко |
Прямой вывод - более чем 2 метки используются редко |
||
| − | ==Push Label== |
+ | ==<code>Push Label</code>== |
| − | Push Label — операция добавления метки к пакету данных — совершается в самом начале — на первом маршрутизаторе в сети MPLS |
+ | <code>Push Label</code> — операция добавления метки к пакету данных — совершается в самом начале — на первом маршрутизаторе в сети MPLS |
| + | |||
| − | ==Swap Label== |
||
| + | ==<code>Swap Label</code>== |
||
| − | Swap Label — операция замены метки — происходит на промежуточных маршрутизаторах в сети MPLS — узел получает пакет с одной меткой, меняет её и отправляет с другой (R2, R5). |
||
| + | <code>Swap Label</code> — операция замены метки — происходит на промежуточных маршрутизаторах в сети MPLS — узел получает пакет с одной меткой, меняет её и отправляет с другой |
||
| − | ==Pop Label== |
||
| + | |||
| − | Pop Label — операция удаления метки — выполняется последним маршрутизатором — узел получает пакет MPLS и убирает верхнюю метку перед передачей его дальше (R6). |
||
| + | ==<code>Pop Label</code>== |
||
| + | <code>Pop Label</code> — операция удаления метки — выполняется последним маршрутизатором — узел получает пакет MPLS и убирает верхнюю метку перед передачей его дальше. |
||
| + | <BR> |
||
На самом деле метка может добавляться и удаляться где угодно внутри сети MPLS. |
На самом деле метка может добавляться и удаляться где угодно внутри сети MPLS. |
||
| − | Всё зависит от конкретных сервисов. |
+ | Всё зависит от конкретных сервисов. |
| + | <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). |
||
| − | + | <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 на самом деле однонаправленный. Это означает, что, во-первых, трафик по нему передаётся только в одном направлении, во-вторых, если существует «туда», не обязательно существует «обратно», в-третьих, «обратно» не обязательно идёт по тому же пути, что «туда». |
+ | Важно понимать, что 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. |
+ | А вот что, несомненно, важно и полезно — так это, что безразличие 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 LabelIngress LSR— «входной», первый маршрутизатор MPLS — он выполняет операцию Push LabelEgress 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
Практика
Есть вот такая схема
Все маршрутизаторы в примере - FRR
Linux
|
Рекомендую убедиться что все настройки сделаны верно и перезагрузить роутер что бы убедиться что ничего не забыли вписать в конфиг (не повторяйте мою ошибку) |
Для того что бы включить поддержку требуется сделать следующее (некоторые шаги не обязательны)
Отключить 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- сети соответвующие маршрутизатору, везде /30ospf router-id 192.168.32.11- уникальный идентификатор роутера, это адрес loopback интерфейса
MPLS
Ссылки
- https://habr.com/ru/articles/884824/
- https://linkmeup.ru/blog/1207/#GLOSSARY (да и вообще все что есть там про MPLS)