Задача: на виртульной машине с Ubuntu 24 изолировать два сетевых интерфейса между собой.
Мы боролись с ассиметрией в виртуальной среде NSX-T, где distributed firewall к ней совсем нетерпим, необходимо было разнести маршруты 0/0 и 10/8 по разным интерфейсам, при это было важно, чтобы они не были в одной таблице маршрутизации.
И когда сетевик слышит, что нужно что-то «изолировать» - он идет натягивать VRF. По официальной документации netplan поддерживает VRF - то, что надо, берем.
Адаптируем под себя:
Интерфейсы разнесены по VRF, всё выглядит корректно:
Проверяем доступ извне до IP-адреса внутри VRF - ping работает! А для сетевика полученный ICMP-ответ - это как документ с печатью, подтверждающий наличие доступа. Проверяем SSH, получаем «connection refused», перезагружаем VM(на всякий), доступа нет, интересно. Отключаем iptables(в любой непонятной ситуации), но и это не помогает. Любые дальнейшие эксперименты показывают, что и другие сервисы, привязанные к IP-адресу eth0 (который внутри VRF) также недоступны 🤷
Я не знал, что все сервисы работают в контексте VRF по умолчанию, т.е. процессы используют таблицу маршрутизации по умолчанию и имеют доступ к прослушиваемым IP-адресам только в этом дефолтном VRF, если не указано иное.
Если для ping внутри VRF мы можем использовать опцию -I, которая указывает src-интерфейс внутри VRF и ping начинает работать, то сервису SSH необходимо явно указать - используй контекст vrf-mgmt! Это будет касаться и других сервисов, которые должны работать с IP-адресами внутри VRF.
Решение для SSH: в systemd для юнита sshd изменить ExecStart с указанием использования VRF. Пока идет отладка изменим сразу /lib/systemd/system/ssh.service. (Напрямую лучше не изменять системные файлы, потому что любое обновление перезатрет изменения, нужно использовать override)
Команда ip vrf exec запускает процесс sshd в контексте vrf-mgmt.
После изменения файла службы нужно перезагрузить конфигурацию systemd и службу SSH, чтобы изменения вступили в силу:
Проверяем SSH извне на IP внутри VRF - доступ есть!
Если цель вынести только управление VM в отдельный VRF, то в принципе, на этом можно остановиться. Но в нашем случае были и другие сервисы, которым нужен доступ к VRF.
Идем дальше.
Есть решение, в котором все сервисы будут работать со всеми VRF в системе - L3 Master Device, известный как l3mdev:
Проверим наличие модуля CONFIG_NET_L3_MASTER_DEV в конфигурационном файле ядра:
Если видим CONFIG_NET_L3_MASTER_DEV=y, значит модуль встроен в ядро.
Включаем для tcp/udp:
Проверяем, убеждаемся что все сервисы начинают работать внутри VRF. Успех😮💨
По документации, l3mdev ухудшает производительность на 2-3%. Попробую разобраться как он работает.
#Задача
Мы боролись с ассиметрией в виртуальной среде NSX-T, где distributed firewall к ней совсем нетерпим, необходимо было разнести маршруты 0/0 и 10/8 по разным интерфейсам, при это было важно, чтобы они не были в одной таблице маршрутизации.
И когда сетевик слышит, что нужно что-то «изолировать» - он идет натягивать VRF. По официальной документации netplan поддерживает VRF - то, что надо, берем.
Адаптируем под себя:
network:
version: 2
renderer: networkd
ethernets:
eth0: # -> vrf-mgmt
addresses:
- 10.10.8.101/23
routes:
- to: 10.0.0.0/8
via: 10.10.8.1
routing-policy:
- from: 10.10.8.101/23
eth1: # -> main
addresses:
- 10.11.8.3/29
gateway4: 10.11.8.1
vrfs:
vrf-mgmt:
table: 101
interfaces: [eth0]
Интерфейсы разнесены по VRF, всё выглядит корректно:
# ip route
default via 10.11.8.1 dev eth1 proto static
10.11.8.0/29 dev eth1 proto kernel scope link src 10.11.8.3
# ip route show vrf vrf-mgmt
10.0.0.0/8 via 10.10.8.1 dev eth0 proto static
10.10.8.0/23 dev eth0 proto kernel scope link src 10.10.8.101
Проверяем доступ извне до IP-адреса внутри VRF - ping работает! А для сетевика полученный ICMP-ответ - это как документ с печатью, подтверждающий наличие доступа. Проверяем SSH, получаем «connection refused», перезагружаем VM(на всякий), доступа нет, интересно. Отключаем iptables(в любой непонятной ситуации), но и это не помогает. Любые дальнейшие эксперименты показывают, что и другие сервисы, привязанные к IP-адресу eth0 (который внутри VRF) также недоступны 🤷
Я не знал, что все сервисы работают в контексте VRF по умолчанию, т.е. процессы используют таблицу маршрутизации по умолчанию и имеют доступ к прослушиваемым IP-адресам только в этом дефолтном VRF, если не указано иное.
Если для ping внутри VRF мы можем использовать опцию -I, которая указывает src-интерфейс внутри VRF и ping начинает работать, то сервису SSH необходимо явно указать - используй контекст vrf-mgmt! Это будет касаться и других сервисов, которые должны работать с IP-адресами внутри VRF.
Решение для SSH: в systemd для юнита sshd изменить ExecStart с указанием использования VRF. Пока идет отладка изменим сразу /lib/systemd/system/ssh.service. (Напрямую лучше не изменять системные файлы, потому что любое обновление перезатрет изменения, нужно использовать override)
Было
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
Стало
ExecStart=/bin/ip vrf exec vrf-mgmt /usr/sbin/sshd -D $SSHD_OPTS
Команда ip vrf exec запускает процесс sshd в контексте vrf-mgmt.
После изменения файла службы нужно перезагрузить конфигурацию systemd и службу SSH, чтобы изменения вступили в силу:
systemctl daemon-reload
systemctl restart ssh
Проверяем SSH извне на IP внутри VRF - доступ есть!
Если цель вынести только управление VM в отдельный VRF, то в принципе, на этом можно остановиться. Но в нашем случае были и другие сервисы, которым нужен доступ к VRF.
Идем дальше.
Есть решение, в котором все сервисы будут работать со всеми VRF в системе - L3 Master Device, известный как l3mdev:
Official reference
Enables child sockets to inherit the L3 master device index. Enabling this option allows a “global” listen socket to work across L3 master domains (e.g.,VRFs) with connected sockets derived from the listen socket to be bound to the L3 domain in which the packets originated. Only valid when the kernel was compiled with CONFIG_NET_L3_MASTER_DEV
Проверим наличие модуля CONFIG_NET_L3_MASTER_DEV в конфигурационном файле ядра:
grep CONFIG_NET_L3_MASTER_DEV /boot/config-$(uname -r)
Если видим CONFIG_NET_L3_MASTER_DEV=y, значит модуль встроен в ядро.
Включаем для tcp/udp:
sysctl -w net.ipv4.tcp_l3mdev_accept=1
sysctl -w net.ipv4.udp_l3mdev_accept=1
Проверяем, убеждаемся что все сервисы начинают работать внутри VRF. Успех
По документации, l3mdev ухудшает производительность на 2-3%. Попробую разобраться как он работает.
#Задача
Please open Telegram to view this post
VIEW IN TELEGRAM
👍27🔥12❤3🫡2✍1
Forwarded from Патчкорд
Стоит напомнить, спасибо за подсказку нашему подписчику, что когда сетевик слышит про сетевую изоляцию он думает про
VRF, а когда линуксоид про неё слышит, то он думает про NETNS. Имейте ввиду эту опцию то же, там изоляция поизолированней.👍9🔥3
Поразбирался с l3mdev.
Продолжение предыдущего поста
L3mdev (Layer 3 Master Device) - это механизм в ядре Linux, который обеспечивает поддержку VRF, т.е. основное назначение l3mdev - это изоляция таблиц маршрутизации.
В контексте l3mdev есть два вида устройств(devices):
1️⃣ Master - это собственно и есть VRF. Пример: создаем VRF ip link add dev vrf-mgmt type vrf table 101, где vrf-mgmt и будет мастер устройством.
2️⃣ Slave - устройство, которое «подчинено» мастеру, т.е. сетевой интерфейс, привязанный к VRF. Пример: ip link set dev eth0 master vrf-mgmt, где eth0 - slave
У каждого сетевого интерфейса есть индекс, который можно посмотреть с помощью команды ip link show.
Вывод сокращен:
[1-4] - это индексы, при этом в зависимости от направления они могут быть:
🟢 iif - Input Interface Index, индекс сетевого устройства, на которое пришел пакет
🟢 oif - Output Interface Index, индекс сетевого устройства, через которое пакет будет отправлен
Задача l3mdev сводится к тому, чтобы перенаправить сетевые интерфейсы на L3 мастер-устройство для маршрутизации через правильную таблицу. То есть он меняет oif или iif со slave-устройства на master-устройство.
На примере нашего конфига netplan это работает так:
Пакет -> eth0(slave) -> 3lmdev делает update iif -> vrf-mgmt(master) -> table 101
Чтобы l3mdev мог заменять iif/oif на master (VRF), используется специальная таблица, которая создается автоматически при создании VRF - [l3mdev-table].
Команда для просмотра правил маршрутизации: ip rule show
Вывод:
Числа слева - это приоритеты, возможный диапазон от 0 до 32767. Чем меньше число, тем выше приоритет. Задача l3mdev-table - динамически указывать на правильную таблицу VRF на основе сетевого интерфейса (iif или oif).
Как это работает:
И посмотрим, где l3mdev находится в сетевом стеке(упрощенно):
1️⃣ Пакет из сети попадает на сетевую карточку, далее в драйвер сетевой карты
2️⃣ Ядро создает skb (socket buffer), проверяет пакет на валидность, заголовки и тд.
3️⃣ Любой входящий трафик запускает хук Netfiler - NF_IP_PRE_ROUTING (обрабатывается до принятия решения о том, куда отправлять пакет). Про Netfilter и хуки можно почитать тут. Происходит первый поиск в RIB - проверяется принадлежит ли dst IP локальному интерфейсу.
4️⃣ Хук l3mdev_l3_rcv меняет skb->dev(eth0) на vrf-mgmt
5️⃣ На основе нового skb->dev происходит повторный поиск в RIB в VRF
6️⃣ И если пакет предназначен локальному хосту, вызывается хук NF_INET_LOCAL_IN и передается приложению.
Обработка исходящих пакетов по своей сути похожа, но будут вызываться разные хуки Netfiler и l3mdev.
Стоит отметить, что l3mdev никак не влияет на L2-трафик.
Из необычного, статистика по интерфейсу vrf-mgmt будет выглядеть так:
Счетчик TX на интерфейсе vrf-mgmt всегда равен 0.
Свою версию, почему так происходит, я напишу в следующем посте. Если у вас есть свои идеи или вы считаете, что в моих рассуждениях выше есть неточности, то можем обсудить в комментах.
——————————————
Документ с описанием: What is an L3 Master Device?
Нашел еще доклад + презу
🎤 Будни сетевика 😊
Продолжение предыдущего поста
L3mdev (Layer 3 Master Device) - это механизм в ядре Linux, который обеспечивает поддержку VRF, т.е. основное назначение l3mdev - это изоляция таблиц маршрутизации.
В контексте l3mdev есть два вида устройств(devices):
1️⃣ Master - это собственно и есть VRF. Пример: создаем VRF ip link add dev vrf-mgmt type vrf table 101, где vrf-mgmt и будет мастер устройством.
2️⃣ Slave - устройство, которое «подчинено» мастеру, т.е. сетевой интерфейс, привязанный к VRF. Пример: ip link set dev eth0 master vrf-mgmt, где eth0 - slave
У каждого сетевого интерфейса есть индекс, который можно посмотреть с помощью команды ip link show.
Вывод сокращен:
1: lo: <LOOPBACK,UP,LOWER_UP>
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> master vrf-mgmt state UP
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> state UP
4: vrf-mgmt: <NOARP,MASTER,UP,LOWER_UP> state UP
[1-4] - это индексы, при этом в зависимости от направления они могут быть:
Задача l3mdev сводится к тому, чтобы перенаправить сетевые интерфейсы на L3 мастер-устройство для маршрутизации через правильную таблицу. То есть он меняет oif или iif со slave-устройства на master-устройство.
На примере нашего конфига netplan это работает так:
Пакет -> eth0(slave) -> 3lmdev делает update iif -> vrf-mgmt(master) -> table 101
Чтобы l3mdev мог заменять iif/oif на master (VRF), используется специальная таблица, которая создается автоматически при создании VRF - [l3mdev-table].
Команда для просмотра правил маршрутизации: ip rule show
Вывод:
0: from all lookup local
1000: from all lookup [l3mdev-table] <— вот она
32765: from 10.10.8.101/23 lookup main proto static
32766: from all lookup main
32767: from all lookup default
Числа слева - это приоритеты, возможный диапазон от 0 до 32767. Чем меньше число, тем выше приоритет. Задача l3mdev-table - динамически указывать на правильную таблицу VRF на основе сетевого интерфейса (iif или oif).
Как это работает:
Приходит пакет
↓
Приоритет 0: lookup local
↓
Приоритет 1000: lookup [l3mdev-table]
Вот тут начинает работать l3mdev
1. Определяет интерфейс (iif/oif) исходя из флоу трафика
2. Проверяет принадлежит ли интерфейс VRF
3. Определяет ID таблицы VRF и перенаправляет в нее
↓
Приоритет 32765: from 10.10.8.101/23 lookup main
↓
Приоритет 32766: lookup main
↓
Приоритет 32767: lookup default
И посмотрим, где l3mdev находится в сетевом стеке(упрощенно):
1️⃣ Пакет из сети попадает на сетевую карточку, далее в драйвер сетевой карты
2️⃣ Ядро создает skb (socket buffer), проверяет пакет на валидность, заголовки и тд.
3️⃣ Любой входящий трафик запускает хук Netfiler - NF_IP_PRE_ROUTING (обрабатывается до принятия решения о том, куда отправлять пакет). Про Netfilter и хуки можно почитать тут. Происходит первый поиск в RIB - проверяется принадлежит ли dst IP локальному интерфейсу.
4️⃣ Хук l3mdev_l3_rcv меняет skb->dev(eth0) на vrf-mgmt
5️⃣ На основе нового skb->dev происходит повторный поиск в RIB в VRF
6️⃣ И если пакет предназначен локальному хосту, вызывается хук NF_INET_LOCAL_IN и передается приложению.
Обработка исходящих пакетов по своей сути похожа, но будут вызываться разные хуки Netfiler и l3mdev.
Стоит отметить, что l3mdev никак не влияет на L2-трафик.
Из необычного, статистика по интерфейсу vrf-mgmt будет выглядеть так:
vrf-mgmt: flags=1217<UP,RUNNING,NOARP,MASTER> mtu 65575
ether 22:20:a7:a8:7f:f8 txqueuelen 1000 (Ethernet)
RX packets 36707747 bytes 26433447694 (26.4 GB)
TX packets 0 bytes 0 (0.0 B)
Счетчик TX на интерфейсе vrf-mgmt всегда равен 0.
Свою версию, почему так происходит, я напишу в следующем посте. Если у вас есть свои идеи или вы считаете, что в моих рассуждениях выше есть неточности, то можем обсудить в комментах.
——————————————
Документ с описанием: What is an L3 Master Device?
Нашел еще доклад + презу
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16🔥8❤1
Forwarded from linkmeup
Думаю не ошибусь, если скажу что на минувшем линкмитапе это был самый срачеобразующий доклад. Прям начиная с темы и так до упора.
Собственно, Дмитрий Ипатов и его рассказ о том как подготовиться к масштабной трансляции, насобирать разного, попробовать удивительного и выйти из ситуации победителем, на примере организации трансляции Евро24.
https://youtu.be/WJHBkAXhyW4
Собственно, Дмитрий Ипатов и его рассказ о том как подготовиться к масштабной трансляции, насобирать разного, попробовать удивительного и выйти из ситуации победителем, на примере организации трансляции Евро24.
https://youtu.be/WJHBkAXhyW4
YouTube
Как мы в Окко готовились транслировать Евро24. Дмитрий Ипатов
В прошлом году Okko транслировал Евро24. Подготовка и проведение события такого масштаба — это настоящий вызов как для инфраструктуры, так и для команды.
В своем докладе я расскажу о сложностях, с которыми мы столкнулись на разных этапах, о том, как адаптировались…
В своем докладе я расскажу о сложностях, с которыми мы столкнулись на разных этапах, о том, как адаптировались…
🔥21👏6
Сегодня стартовала оффлайн часть ключевой отраслевой конференции по технологиям видео VideoTech 2025
СПб, 7-8 октября.
Отличная возможность обменяться опытом, рад буду пообщаться.
🎤 Будни сетевика 😊
СПб, 7-8 октября.
Отличная возможность обменяться опытом, рад буду пообщаться.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15
VideoTech 2025.pdf
4.5 MB
Время у меня было ограничено, и мне удалось послушать только четыре доклада:
1. Кирилл Медведев «DPDK в медиасерверах: снижение задержек и повышение пропускной способности».
Доклад был посвящён тому, почему традиционный сетевой стек Linux становится узким местом и как DPDK может помочь решить эту проблему. Кирилл рассказал об архитектуре DPDK, о недостатках классического стека Linux и о том, как DPDK их преодолевает. В целом, обсуждение свелось к интеграции DPDK и Nginx, разработанной в Selectel и в настоящее время доступной только в составе SelectelOS - Fginx. Отдельное спасибо за ссылку на статью "The Path of a Packet Through the Linux Kernel", которая описывает путь пакета в стеке Linux. Думаю, позже сделаю краткий обзор этой статьи.
2. Иван Бурцев «Скоростной и дешевый HW-транскодинг из подручных материалов».
Это история о том, как инженеры собрали железный транскодер себестоимостью 120 тысяч рублей в свободное от работы время. Иван немного рассказал о теории кодеров и декодеров, а также о производителях (Nvidia, Intel и др.) и причинах высокой стоимости готовых решений. В основе доклада была история как они выбирали все компоненты, где их брали и как собирали. В конце Иван показал их решение вживу, можно было пощупать.
Однако ни один ЦОД не пропустил их с этой железкой - где сертификация? Ждем новую историю.
3. Кирилл Шваков «CDN Кинескоп: к чему мы пришли через 6 лет».
Доклад был о устройстве CDN Kinescope, где обсуждались аппаратные компоненты серверов и программное обеспечение в их CDN. Интересно, что коллеги решили отказаться от стандартного решения на основе Nginx в пользу собственного, написанного на Go. Также они продолжают использовать HDD наряду с SSD для хранения "холодных" файлов, которые давно никто не смотрел. Обсуждали проблемы шардирования I/O на HDD и работу с большими файлами.
P.S. Они умеют раздавать более 100 Гбит/с с одной ноды, но это уже давно никого не удивляет 🙂
4. Александр Алексеев «Глубокое погружение в Forward Error Correction для WebRTC».
Доклад содержал много информации о математических моделях сетевых потерь, способах определения параметров FEC и интеграции с механизмами управления перегрузками (Congestion Control). Я не был целевой аудиторией для этого доклада, поэтому было сложно слушать, но разработчикам это точно будет интересно.
От автора доклада:
Когда стоит применять FEC
▶ В сетях с потерями и высоким RTT.
▶ При потерях, не вызванных перегрузкой канала собственным трафиком.
▶ Для сетевого бустинга.
Доклады - это хорошо, но самое интересное - пообщаться со спикерами после выступлений, где можно задать любые вопросы. Собственно, для этого я и хожу на конференции.
Креплю презы с выступлений.
🎤 Будни сетевика 😊
1. Кирилл Медведев «DPDK в медиасерверах: снижение задержек и повышение пропускной способности».
Доклад был посвящён тому, почему традиционный сетевой стек Linux становится узким местом и как DPDK может помочь решить эту проблему. Кирилл рассказал об архитектуре DPDK, о недостатках классического стека Linux и о том, как DPDK их преодолевает. В целом, обсуждение свелось к интеграции DPDK и Nginx, разработанной в Selectel и в настоящее время доступной только в составе SelectelOS - Fginx. Отдельное спасибо за ссылку на статью "The Path of a Packet Through the Linux Kernel", которая описывает путь пакета в стеке Linux. Думаю, позже сделаю краткий обзор этой статьи.
2. Иван Бурцев «Скоростной и дешевый HW-транскодинг из подручных материалов».
Это история о том, как инженеры собрали железный транскодер себестоимостью 120 тысяч рублей в свободное от работы время. Иван немного рассказал о теории кодеров и декодеров, а также о производителях (Nvidia, Intel и др.) и причинах высокой стоимости готовых решений. В основе доклада была история как они выбирали все компоненты, где их брали и как собирали. В конце Иван показал их решение вживу, можно было пощупать.
Однако ни один ЦОД не пропустил их с этой железкой - где сертификация? Ждем новую историю.
3. Кирилл Шваков «CDN Кинескоп: к чему мы пришли через 6 лет».
Доклад был о устройстве CDN Kinescope, где обсуждались аппаратные компоненты серверов и программное обеспечение в их CDN. Интересно, что коллеги решили отказаться от стандартного решения на основе Nginx в пользу собственного, написанного на Go. Также они продолжают использовать HDD наряду с SSD для хранения "холодных" файлов, которые давно никто не смотрел. Обсуждали проблемы шардирования I/O на HDD и работу с большими файлами.
P.S. Они умеют раздавать более 100 Гбит/с с одной ноды, но это уже давно никого не удивляет 🙂
4. Александр Алексеев «Глубокое погружение в Forward Error Correction для WebRTC».
Доклад содержал много информации о математических моделях сетевых потерь, способах определения параметров FEC и интеграции с механизмами управления перегрузками (Congestion Control). Я не был целевой аудиторией для этого доклада, поэтому было сложно слушать, но разработчикам это точно будет интересно.
От автора доклада:
Когда стоит применять FEC
▶ В сетях с потерями и высоким RTT.
▶ При потерях, не вызванных перегрузкой канала собственным трафиком.
▶ Для сетевого бустинга.
Доклады - это хорошо, но самое интересное - пообщаться со спикерами после выступлений, где можно задать любые вопросы. Собственно, для этого я и хожу на конференции.
Креплю презы с выступлений.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍23❤7🔥4
Продолжаем и заканчиваем историю про VRF в Linux.
Статистика по интерфейсу vrf-mgmt будет выглядеть так:
Необычно здесь то, что счетчик RX увеличивается, а TX - нет.
Сразу отметим, что в отличии от физических интерфейсов (eth0, eth1), интерфейс vrf-mgmt - виртуальный.
Почему так происходит.
▎Входящий трафик (RX)
1️⃣ Пакет приходит на интерфейс eth0, который привязан к VRF
2️⃣ Пакет попадает на интерфейс vrf-mgmt для маршрутизации
3️⃣ Увеличается счетчик RX, потому что пакет проходит через vrf-mgmt
4️⃣ Определяется получать и пакет отправляется приложению или другому хосту
▎Исходящий трафик (TX)
1️⃣ Приложение формирует пакет и отправляет его через VRF
2️⃣ FIB lookup в VRF - пакет должен уйти через eth0, при этом сам пакет VRF не обрабатывает (TX счетчик VRF не изменяется)
3️⃣ Пакет передается напрямую на eth0
4️⃣ И вот уже здесь TX счетчик eth0 увеличивается
Получается такая картина:
🎤 Будни сетевика 😊
Статистика по интерфейсу vrf-mgmt будет выглядеть так:
vrf-mgmt: flags=1217<UP,RUNNING,NOARP,MASTER> mtu 65575
ether 22:20:a7:a8:7f:f8 txqueuelen 1000 (Ethernet)
RX packets 36707747 bytes 26433447694 (26.4 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Необычно здесь то, что счетчик RX увеличивается, а TX - нет.
Сразу отметим, что в отличии от физических интерфейсов (eth0, eth1), интерфейс vrf-mgmt - виртуальный.
Почему так происходит.
▎Входящий трафик (RX)
1️⃣ Пакет приходит на интерфейс eth0, который привязан к VRF
2️⃣ Пакет попадает на интерфейс vrf-mgmt для маршрутизации
3️⃣ Увеличается счетчик RX, потому что пакет проходит через vrf-mgmt
4️⃣ Определяется получать и пакет отправляется приложению или другому хосту
▎Исходящий трафик (TX)
1️⃣ Приложение формирует пакет и отправляет его через VRF
2️⃣ FIB lookup в VRF - пакет должен уйти через eth0, при этом сам пакет VRF не обрабатывает (TX счетчик VRF не изменяется)
3️⃣ Пакет передается напрямую на eth0
4️⃣ И вот уже здесь TX счетчик eth0 увеличивается
Получается такая картина:
### Входящий трафик ###
[Сеть] → [eth0] → [VRF] → [Приложение]
↑
RX счетчик увеличивается здесь
### Исходящий трафик ###
[Приложение] → [VRF] → [eth0] → [Сеть]
↑
TX счетчик увеличивается здесь
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15👍6
bird_without_vrf.rtf
1.9 KB
Не получилось закончить историю с VRF в Linux.
В другом сценарии возникла необходимость поднять BGP с помощью Bird внутри VRF. Почему именно Bird, а не что-то другое? Все просто: он уже использовался на хосте. Скажем, что так исторически сложилось.
Для начала необходимо включить параметр l3mdev, чтобы Bird мог работать с интерфейсом внутри VRF:
Далее нужно адаптировать конфигурацию Bird для работы с VRF. В BGP анонсировались IP-адреса, назначенные на loopback, и эту схему необходимо было сохранить.
Вот изменения, которые были добавлены в конфигурацию Bird при запуске внутри VRF:
У меня никак не получилось заставить Bird увидеть префиксы, назначенные на loopback внутри VRF (я старался). Поэтому я просто перенес их на интерфейс vrf-prod. В этом случае Bird сразу же их увидит через protocol direct.
Прикладываю конфигурации: netplan, Bird без VRF и Bird с VRF.
🎤 Будни сетевика 😊
В другом сценарии возникла необходимость поднять BGP с помощью Bird внутри VRF. Почему именно Bird, а не что-то другое? Все просто: он уже использовался на хосте. Скажем, что так исторически сложилось.
Для начала необходимо включить параметр l3mdev, чтобы Bird мог работать с интерфейсом внутри VRF:
sysctl -w net.ipv4.tcp_l3mdev_accept=1
sysctl -w net.ipv4.udp_l3mdev_accept=1
Далее нужно адаптировать конфигурацию Bird для работы с VRF. В BGP анонсировались IP-адреса, назначенные на loopback, и эту схему необходимо было сохранить.
Вот изменения, которые были добавлены в конфигурацию Bird при запуске внутри VRF:
router id 169.254.69.11;
protocol device {
vrf "vrf-prod"; # <- добавить VRF
scan time 20;
}
protocol bfd {
vrf "vrf-prod"; # <- добавить VRF
interface "*" {
interval 500 ms;
multiplier 3;
};
}
protocol kernel {
vrf "vrf-prod"; # <- добавить VRF
kernel table 101; # <- добавить таблицу
learn;
metric 64;
scan time 20;
import all;
graceful restart;
export filter {
krt_prefsrc = 169.254.69.11;
accept;
};
merge paths yes;
}
protocol direct {
interface "vrf-prod"; # <- добавить VRF вместо лупбека
}
####
filter export_to_peer {
if source = RTS_DEVICE then {
accept;
}
reject;
}
filter import_from_peer {
if source = RTS_BGP then {
accept;
}
reject;
}
####
protocol bgp PEER_1 {
vrf "vrf-prod"; #<- добавить VRF
local as 4240300609;
neighbor 169.254.69.12 as 4240300161;
direct;
bfd;
export filter export_to_peer;
import filter import_from_peer;
}
protocol bgp PEER_2 {
vrf "vrf-prod"; #<- добавить VRF
local as 4240300609;
neighbor 169.254.69.13 as 4240300161;
direct;
bfd;
export filter export_to_peer;
import filter import_from_peer;
}
У меня никак не получилось заставить Bird увидеть префиксы, назначенные на loopback внутри VRF (я старался). Поэтому я просто перенес их на интерфейс vrf-prod. В этом случае Bird сразу же их увидит через protocol direct.
Прикладываю конфигурации: netplan, Bird без VRF и Bird с VRF.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14🔥3😁1
Эмулятор компьютерной сети для образовательных целей на базе ОС Linux.
Наткнулся на интересный проект для изучения основ сети- https://github.com/mimi-net/miminet.
С помощью этого инструмента можно собирать простые топологии, эмулировать поведение сети, запускать команды с сетевых устройств и даже задавать процент потерь в канале между ними, есть возможность скачать pcap с интерфейсов. Выглядит круто, но функционал сильно ограничен. Проект изначально задумывался как образовательная платформа для вузов, и думаю, что со своей изначальной задачей он справляется на отлично.
Чтобы не разворачивать локально, можно поизучать версию в паблике - https://miminet.ru/
Есть свежее описание на Habr’e
P.S. Название получилось запоминающееся 😉
Наткнулся на интересный проект для изучения основ сети- https://github.com/mimi-net/miminet.
С помощью этого инструмента можно собирать простые топологии, эмулировать поведение сети, запускать команды с сетевых устройств и даже задавать процент потерь в канале между ними, есть возможность скачать pcap с интерфейсов. Выглядит круто, но функционал сильно ограничен. Проект изначально задумывался как образовательная платформа для вузов, и думаю, что со своей изначальной задачей он справляется на отлично.
Чтобы не разворачивать локально, можно поизучать версию в паблике - https://miminet.ru/
Есть свежее описание на Habr’e
P.S. Название получилось запоминающееся 😉
GitHub
GitHub - mimi-net/miminet: Cute network emulation web-app for self-education and classes (based on mininet).
Cute network emulation web-app for self-education and classes (based on mininet). - mimi-net/miminet
👍13
Задача: настроить коммутаторы Juniper QFX на отправку syslog over TLS
Такое потребовалось в одном изолированном контуре, где все должно быть максимально БЕЗОПАСНО 🔐
3 шага для настройки
🔑 Шаг 1: Установка сертификата
Тут два варианта.
1. Получить сертификат от вашего CA
Указываем URL для получения сертификата:
Получаем сертификат:
Сертификат будет автоматически сохранён и использован.
2. Скачать уже готовый сертификат на устройство (например, через SCP)
Далее загружаем сертификат:
Проверяем, что сертификат был загружен:
🔑 Шаг 2: Создание ca-группы и ca-профиля
🔑 Шаг 3: Настройка syslog с TLS
10.15.24.37 - Syslog-сервер
Можно проверять логи на Syslog-сервере.
Документация Juniper: Syslog over TLS.
🎤 Будни сетевика 😊 | #Задача
Такое потребовалось в одном изолированном контуре, где все должно быть максимально БЕЗОПАСНО 🔐
3 шага для настройки
🔑 Шаг 1: Установка сертификата
Тут два варианта.
1. Получить сертификат от вашего CA
Указываем URL для получения сертификата:
set security pki ca-profile tls-syslog enrollment url http://your-ca-server/certsrv
Получаем сертификат:
request security pki ca-certificate enroll ca-profile tls-syslog
Сертификат будет автоматически сохранён и использован.
2. Скачать уже готовый сертификат на устройство (например, через SCP)
Далее загружаем сертификат:
request security pki ca-certificate load ca-profile tls-syslog filename /var/tmp/cert_ca.pem
Проверяем, что сертификат был загружен:
show security pki ca-certificate
LSYS: root-logical-system
CA profile: tls-syslog
Certificate identifier: tls-syslog
Issued to: Okko CA Certificate, Issued by: C = RU, ST = Saint-Petersburg, O = Okko, OU = Technical Department, CN = Okko CA Certificate
Validity:
Not before: 09-11-2025 14:32 UTC
Not after: 09- 9-2035 14:32 UTC
Public key algorithm: ecdsaEncryption(384 bits)
Keypair Location: Keypair generated locally
🔑 Шаг 2: Создание ca-группы и ca-профиля
set security pki ca-profile tls-syslog ca-identity tls-syslog
set security pki ca-profile tls-syslog revocation-check disable
set security pki trusted-ca-group tlsdetails ca-profiles tls-syslog
🔑 Шаг 3: Настройка syslog с TLS
10.15.24.37 - Syslog-сервер
set system syslog host 10.15.24.37 any any
set system syslog host 10.15.24.37 interactive-commands any
set system syslog host 10.15.24.37 port 1515
set system syslog host 10.15.24.37 source-address 10.1.25.130
set system syslog host 10.15.24.37 transport tls
set system syslog host 10.15.24.37 tlsdetails trusted-ca-group tls-syslog ca-profiles tls-syslog
set system syslog host 10.15.24.37 structured-data
set system syslog file interactive-commands interactive-commands any
set system syslog file messages any any
set system syslog file messages authorization info
set system syslog source-address 10.15.25.130
Можно проверять логи на Syslog-сервере.
Документация Juniper: Syslog over TLS.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍23🔥3👀3
redhat best practises.pdf
8.7 MB
Уже многие писали, что Иван Пепельняк открыл доступ к своим вебинарам Ansible для сетевых инженеров.
Напишу и я, но дополню докой от RedHat - Ansible Best Practices.
🎤 Будни сетевика 😊
Напишу и я, но дополню докой от RedHat - Ansible Best Practices.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19🔥10
ASR9000 Troubleshooting Architectures.pdf
13.6 MB
ASR9000 Troubleshooting Architectures
До перехода на Juniper в качестве бордеров у нас использовались Cisco ASR 9K. И вот однажды, при изменении ACL, мы столкнулись с такой ошибкой:
При дебаге очень помог этот документ, в котором подробно рассказывается о том:
• Как дебажить ошибки, связанные с TCAM
• Как посмотреть использование TCAM-таблицы
• Как узнать количество занятых записей
• Как оптимизировать ACL для минимизации использования записей
• Как определить, сколько записей использует конкретный ACL
• Как сделать compression ACL
Мы оптимизировали ряд старых ACL, а для самых жирных использовали compression.
При использовании compression нужно учитывать, что есть CVE-2023-20190:
Cisco IOS XR Software Compression ACL Bypass Vulnerability
🎤 Будни сетевика 😊
До перехода на Juniper в качестве бордеров у нас использовались Cisco ASR 9K. И вот однажды, при изменении ACL, мы столкнулись с такой ошибкой:
LC/0/0/CPU0:Oct 5 13:22:41.528 MSK: pfilter_ea[295]: %PKT_INFRA-FEA_DLL-3-TCAM_ERR : TCAM create region error: 'prm_server' detected the 'resource not available' condition 'TCAM resource exhausted.'
При дебаге очень помог этот документ, в котором подробно рассказывается о том:
• Как дебажить ошибки, связанные с TCAM
• Как посмотреть использование TCAM-таблицы
• Как узнать количество занятых записей
• Как оптимизировать ACL для минимизации использования записей
• Как определить, сколько записей использует конкретный ACL
• Как сделать compression ACL
Мы оптимизировали ряд старых ACL, а для самых жирных использовали compression.
При использовании compression нужно учитывать, что есть CVE-2023-20190:
Cisco IOS XR Software Compression ACL Bypass Vulnerability
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18👍8❤5
Интересный проект awesome-sysadmin.
Это репозиторий, который представляет собой отобранный список полезных бесплатных и открытых ресурсов для системных администраторов.
Основная его цель: Собрать в одном месте лучшие open-source инструменты и ресурсы для задач системного администрирования.
Репозиторий структурирован по категориям, охватывающим практически все аспекты работы системного администратора: автоматизация, резервное копирование, CI/CD, мониторинг, виртуализация, контейнеры и даже немножко сети (VPN, firewall и тд)
🎤 Будни сетевика 😊
Это репозиторий, который представляет собой отобранный список полезных бесплатных и открытых ресурсов для системных администраторов.
Основная его цель: Собрать в одном месте лучшие open-source инструменты и ресурсы для задач системного администрирования.
Репозиторий структурирован по категориям, охватывающим практически все аспекты работы системного администратора: автоматизация, резервное копирование, CI/CD, мониторинг, виртуализация, контейнеры и даже немножко сети (VPN, firewall и тд)
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - awesome-foss/awesome-sysadmin: A curated list of amazingly awesome open-source sysadmin resources.
A curated list of amazingly awesome open-source sysadmin resources. - awesome-foss/awesome-sysadmin
🔥16👍8
Обзор сетевых интерфейсов в Linux
Если выполнить команду ip link help на Linux-хосте, то в выводе (будет в самом низу) можно увидеть довольно большой список сетевых интерфейсов:
Есть две статьи, которые подробно описывают большинство из них:
1. Introduction to Linux interfaces for virtual networking
2. An introduction to Linux virtual interfaces: Tunnels
Интерфейсы, которые есть в выводе команды ip link help, но не упоминаются в этих статьях:
P.S. В списке 41 интерфейс, из которых только 10 я видел вживую и/или настраивал. У кого больше? 😅
🎤 Будни сетевика 😊
Если выполнить команду ip link help на Linux-хосте, то в выводе (будет в самом низу) можно увидеть довольно большой список сетевых интерфейсов:
TYPE := { amt | bareudp | bond | bond_slave | bridge | bridge_slave |
dsa | dummy | erspan | geneve | gre | gretap | gtp | ifb |
ip6erspan | ip6gre | ip6gretap | ip6tnl |
ipip | ipoib | ipvlan | ipvtap |
macsec | macvlan | macvtap |
netdevsim | nlmon | rmnet | sit | team | team_slave |
vcan | veth | vlan | vrf | vti | vxcan | vxlan | wwan |
xfrm | virt_wifi }
Есть две статьи, которые подробно описывают большинство из них:
1. Introduction to Linux interfaces for virtual networking
2. An introduction to Linux virtual interfaces: Tunnels
Интерфейсы, которые есть в выводе команды ip link help, но не упоминаются в этих статьях:
• amt - Automatic Multicast Tunneling, используется для мультикаста. Создает туннель между клиентом, находящимся в сети без мультикаста, и шлюзом, который находится в сети с мультикастом.
• bareudp - поддержка Bare UDP L3 инкапсуляции. Используется, например, для транспортировки MPLS поверх UDP, описано здесь.
• dsa - Distributed Switch Architecture. Очень подробно об этом можно прочитать тут.
• rmnet - устройство Qualcomm rmnet. Что это такое, описано здесь.
• wwan - Wireless Wide Area Network. Неплохое объяснение wwan-интерфейса в контексте GSM-модема.
• virt_wifi - виртуальный драйвер, симулирующий Wi-Fi устройство. Часто используется для тестирования сетевого стека без реального hardware.
P.S. В списке 41 интерфейс, из которых только 10 я видел вживую и/или настраивал. У кого больше? 😅
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13🔥7
Интернет на Камчатке
Я уже бывал на Камчатке в июне 2016 года - это была командировка на три недели. Мы тогда запускали систему-112 в Петропавловске-Камчатском, Елизово и Мильково. Приходилось настраивать серверы, MikroTik’и, АТС (потоки E1, SIP-транки) и рабочие места(комп + софт 112) во всех дежурно-диспетчерских службах (ЕДДС, 01, 02, 03).
В тот период все ждали «быстрого» Интернета, а именно подводной волоконно-оптической линии связи (ПВОЛС) Камчатка - Сахалин - Магадан. Пока ее не запустили, использовали спутниковую связь. Связь внутри города, по моим воспоминаниям, была неплохой, но между регионами или в Интернет приходилось работать с каналами через спутник, что означало задержки в 600-800 ms и периодические потери пакетов, которые также зависили еще и от погоды и/или положения спутника. И, как ни странно, системы работали - данные можно было передавать между центром и регионами, даже SIP-телефония функционировала, не идеально конечно, но вызовы проходили.
Что касается мобильного интернета, то я уже не помню подробностей, но по ощущениям его не было, а любые вызовы стоили дорого, в те времена еще был роуминг внутри одного оператора. Сейчас, находясь в селе Паратунка Елизовского района, speedtest на мобильном интернете Мегафон показывает: RX 117 Mb/s, TX 12Mb/s, ping 152 мс - для просмотра в FullHD хватит.
По открытым источникам, официально ПВОЛС был запущен в октябре-декабре 2016 года, но, думаю, был еще какой-то временной лаг, в течение которого «быстрый» интернет дошел до конечных пользователей. Сейчас зашел на сайты местных операторов и вижу предложения подключить интернет до 500 Мбит/с по технологии xPON.
Я нашел просто шикарную статью о строительстве подводной линии связи до Камчатки и данных с экскурсии на судно-кабелеукладчик Cable Innovator. Она не новая, но как-то прошла мимо меня.
P.S. На фото вулкан Корякский, 29 октября 2025г. Высота над уровнем моря 3456м, легко запомнить.
🎤 Будни сетевика 😊
Я уже бывал на Камчатке в июне 2016 года - это была командировка на три недели. Мы тогда запускали систему-112 в Петропавловске-Камчатском, Елизово и Мильково. Приходилось настраивать серверы, MikroTik’и, АТС (потоки E1, SIP-транки) и рабочие места(комп + софт 112) во всех дежурно-диспетчерских службах (ЕДДС, 01, 02, 03).
В тот период все ждали «быстрого» Интернета, а именно подводной волоконно-оптической линии связи (ПВОЛС) Камчатка - Сахалин - Магадан. Пока ее не запустили, использовали спутниковую связь. Связь внутри города, по моим воспоминаниям, была неплохой, но между регионами или в Интернет приходилось работать с каналами через спутник, что означало задержки в 600-800 ms и периодические потери пакетов, которые также зависили еще и от погоды и/или положения спутника. И, как ни странно, системы работали - данные можно было передавать между центром и регионами, даже SIP-телефония функционировала, не идеально конечно, но вызовы проходили.
Что касается мобильного интернета, то я уже не помню подробностей, но по ощущениям его не было, а любые вызовы стоили дорого, в те времена еще был роуминг внутри одного оператора. Сейчас, находясь в селе Паратунка Елизовского района, speedtest на мобильном интернете Мегафон показывает: RX 117 Mb/s, TX 12Mb/s, ping 152 мс - для просмотра в FullHD хватит.
По открытым источникам, официально ПВОЛС был запущен в октябре-декабре 2016 года, но, думаю, был еще какой-то временной лаг, в течение которого «быстрый» интернет дошел до конечных пользователей. Сейчас зашел на сайты местных операторов и вижу предложения подключить интернет до 500 Мбит/с по технологии xPON.
Я нашел просто шикарную статью о строительстве подводной линии связи до Камчатки и данных с экскурсии на судно-кабелеукладчик Cable Innovator. Она не новая, но как-то прошла мимо меня.
P.S. На фото вулкан Корякский, 29 октября 2025г. Высота над уровнем моря 3456м, легко запомнить.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥30👍12❤7