Linux VRF and Namespaces: различия между версиями
Sirmax (обсуждение | вклад) |
Sirmax (обсуждение | вклад) |
||
| Строка 50: | Строка 50: | ||
Первый, самый старый способ - использовать несколько таблиц маршрутизации |
Первый, самый старый способ - использовать несколько таблиц маршрутизации |
||
<BR> |
<BR> |
||
| − | Насколько я помню он был "всегда" :) |
+ | Насколько я помню он был "всегда" :) (пишут что с 99 года, те раньше чем я познакомился с Linux) |
<BR> |
<BR> |
||
Для этого требуется создать табличку маршрутизации (прописывать в <code>/etc/iproute2/rt_tables</code> ну или зависит от дистрибутива если хочется именования) |
Для этого требуется создать табличку маршрутизации (прописывать в <code>/etc/iproute2/rt_tables</code> ну или зависит от дистрибутива если хочется именования) |
||
| Строка 69: | Строка 69: | ||
</PRE> |
</PRE> |
||
==Недостатки <code>ip rule </code>== |
==Недостатки <code>ip rule </code>== |
||
| + | Это самый неудобный способ, и он не решает следующие проблемы |
||
| + | * Пересечение диапазонов IP адресов. Этой проблемы нет в примере, так как адреса клиентов одинаковые, но при желании делать L3VPN она обязательно возникнет |
||
| + | * Сложность управление и нагромождение ip rule и как следствие линейный поиск по списку с соответвующим падением производительности |
||
| + | * Проблемы с выбором исходящего интерфейса для локального софта |
||
| + | |||
| + | В целом для относительно небольших и не сложных конфигураций это решение можно применять и оно работает. |
||
=Ссылки= |
=Ссылки= |
||
Версия 15:37, 30 апреля 2025
Network Namespaces или VRF
Эта статья задумывается как полуперевод-полукомпиляция и возможно с добавлением собственного опыта
Зачем нужен VRF
VRF это способ "виртуализировать" сеть, и иметь несколько полностью или частично независимых экземпляров сетевого стека.
Пример для банального небольшого провайдера на картинке:
Что тут нарисовано
- Есть 2 группу клиентов
- Беспроводные (картинка с 2 антенами это точка доступа). Им нужно строго ограничивать скорость - гонять через выделенный роутер который делает шейпинг. Если их не шейпить, то один клиент сможет занять всю полосу в эфире, остальные на той же базовой станции работать не смогут.
- Проводные, включены на скорости порта. Гонять их трафик через шейпер не только безсмысленно но и вредно - шейпер плохо работает на скоростях выше 50Мбит
|
|
Вместо шейпера тут может быть например файрволл для гостевой сети, суть от этого не меняется |
- Роутер/L3 свитч куда включены эти клиенты
- Шейпер, пограничный роутер и "интернет" добавлены для наглядности
(тут я не касаюсь L3VPN и вообще VPN ни в каком виде)
Задача описанная выше решается просто на любом более-менее современном L3 коммутаторе
- Для каждой группы клиентов создается свой VRF, своя таблица маршрутизации со своим шлюзом
- Так как шлюзы в разных VRF разные то часть клиентов можно направить через шейпер а другую часть мимо
- На Cisco при желании можно сделать маршрутизацию между VRF - Route Leaking что б клиенты из разных VRF могли общаться друг с другом (в случае интернет-провайдера это сделать можно, в случае с гостевой сетью конечно не желательно)
Это все было банально и все это все и так знают (VRF без MPLS в Cisco называют VRF-Lite)
Вопрос как это все сделать используя Linux
VRF в Linux
Прежде чем говорить о VRF перечислим проблемы которые решает VRF
- Изоляция на уровне L3 - разные VRF имеют независимые таблицы маршрутизации
|
|
C некоторой натяжкой можно считать VRF реализацией Policy Routing |
В Linux есть три способа получить разные таблицы маршрутизации для разных групп source адресов
ip rule
Первый, самый старый способ - использовать несколько таблиц маршрутизации
Насколько я помню он был "всегда" :) (пишут что с 99 года, те раньше чем я познакомился с Linux)
Для этого требуется создать табличку маршрутизации (прописывать в /etc/iproute2/rt_tables ну или зависит от дистрибутива если хочется именования)
echo «123 testtable» >> /etc/iproute2/rt_tables
ip route add default via 192.168.22.254 table testtable
Создаем правило, отправляющее нужные пакеты в нужную таблицу:
ip rule add from 192.168.1.20 table testtable
Или даже вот так
ip rule add iif eth1 table testtable
Недостатки ip rule
Это самый неудобный способ, и он не решает следующие проблемы
- Пересечение диапазонов IP адресов. Этой проблемы нет в примере, так как адреса клиентов одинаковые, но при желании делать L3VPN она обязательно возникнет
- Сложность управление и нагромождение ip rule и как следствие линейный поиск по списку с соответвующим падением производительности
- Проблемы с выбором исходящего интерфейса для локального софта
В целом для относительно небольших и не сложных конфигураций это решение можно применять и оно работает.
