Продолжаем и заканчиваем историю про VRF в Linux.

Статистика по интерфейсу 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 счетчик увеличивается здесь

🎤Будни сетевика 😊

Задача: настроить коммутаторы Juniper QFX на отправку 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.

🎤Будни сетевика 😊 | #Задача

Уже многие писали, что Иван Пепельняк открыл доступ к своим вебинарам Ansible для сетевых инженеров.

Напишу и я, но дополню докой от RedHat - Ansible Best Practices.

🎤 Будни сетевика 😊

ASR9000 Troubleshooting Architectures

До перехода на 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

🎤 Будни сетевика 😊

Интересный проект awesome-sysadmin.

Это репозиторий, который представляет собой отобранный список полезных бесплатных и открытых ресурсов для системных администраторов.

Основная его цель: Собрать в одном месте лучшие open-source инструменты и ресурсы для задач системного администрирования.

Репозиторий структурирован по категориям, охватывающим практически все аспекты работы системного администратора: автоматизация, резервное копирование, CI/CD, мониторинг, виртуализация, контейнеры и даже немножко сети (VPN, firewall и тд)

🎤 Будни сетевика 😊

Обзор сетевых интерфейсов в Linux

Если выполнить команду 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 я видел вживую и/или настраивал. У кого больше? 😅

🎤 Будни сетевика 😊

Интернет на Камчатке

Я уже бывал на Камчатке в июне 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м, легко запомнить.

🎤 Будни сетевика 😊

Рейтинг онлайн-кинотеатров для Камчатки: результаты личного эксперимента

Я провёл небольшое исследование, чтобы выяснить, в каких онлайн-кинотеатрах лучше всего смотреть фильмы на Камчатке. Для этого я оформил бесплатные пробные подписки в основных сервисах и проверил качество их работы. Методика была следующей: я запускал просмотр и в консоли разработчика браузера смотрел, с какого раздающего сервера приходит ссылка. Для каждого из этих серверов с помощью команды ping (с опцией -c 50) проверял RTT и TTFB (time to first byte, то есть время от отправки запроса до получения первого байта от сервера).

Эти метрики показались мне наиболее объективными для сравнения, поскольку тесты на скорость загрузки контента могут отличаться из-за разной длины сегментов. При этом, TTFB я проверял только после того, как убеждался, что сегмент отдаётся из кэша (HIT), чтобы получились максимально чистые результаты. Для TTFB брал от 10 до 15 значений и считал среднее. Все данные сведены в таблицу.

Наблюдения:

• Wink использует CDN Ngenx и, судя по всему, не имеет собственной сети доставки контента

• RuTube и Premier работают через один и тот же CDN

• VK Видео использует CDN «Одноклассников»

• Интересно, что у Premier и RuTube, при использовании одного CDN, показатели TTFB существенно различаются. Я провел тесты несколько раз, ничего не меняется. Вероятно, раздача идёт с серверов разной «мощности».

• Если судить по RTT и TTFB, то наилучшие показатели у Okko, Кинопоиска, IVI и Kion.

• Судя по именам узлов, у Okko и Кинопоиска есть кэш-серверы в Хабаровске, а у Kion во Владивостоке. IVI использует Anycast, поэтому точное географическое положение их узлов определить невозможно, но думаю они также в Хабаровске и/или Владике. У остальных сервисов, скорее всего, все узлы расположены в Москве

Чем меньше RTT и TTFB, тем ниже вероятность буферизации и подвисаний при просмотре. Однако, это технические метрики, отражающие работу инфраструктуры. Многие проблемы для конечного пользователя могут быть скомпенсированы самим видеоплеером, его настройками адаптивного битрейта (ABR) и алгоритмами предзагрузки сегментов. Но у тех сервисов, у которых высокий RTT и TTFB реально ощутимо дольше стартует просмотр и бывают зависания в процессе, но полноценный просмотр уже проверял не у всех.

Выводы: буду доверять техническим метрикам и смотреть Okko 😅

UPD: В комментах подсказали, как определить конкретную ноду у IVI - https://region.dfs.ivi.ru/ (Хабаровск)

🎤 Будни сетевика 😊

Как у вас началась рабочая неделя?

У меня она началась с новости о том, что ровно через неделю, 17 ноября, я буду выступать на Пиринговом форуме 2025.

Секция «Архитектура бесшовного опыта: от кэша до глобальной маршрутизации» обещает быть очень интересной!

Для тех, кто будет на форуме, буду рад обсудить что-нибудь или просто пообщаться.

🎤 Будни сетевика 😊

Обновляли джуны в проде по CVE.

Помимо основных платформ MX и QFX у нас есть совсем немного EX3400, но с ними не все так просто.

The Juniper EX3400 switch series is a decent access switch. But a Product Manager chose to save $0.50 on COGS by choosing a 2GB disk. That’s just not enough space to handle normal Junos upgrades. This has wasted untold engineer hours on busywork. I hope that person (A) got a bonus, and (B) is never allowed to under-spec hardware again.

Проверил, как обстоят дела на других моделях, на скрине вывод команды show system storage.

🎤 Будни сетевика 😊

Ingress NGINX Retirement: What You Need to Know

In March 2026, Ingress NGINX maintenance will be halted, and the project will be retired. After that time, there will be no further releases, no bugfixes, and no updates to resolve any security vulnerabilities that may be discovered. The GitHub repositories will be made read-only and left available for reference.

Existing deployments of Ingress NGINX will not be broken. Existing project artifacts such as Helm charts and container images will remain available.

UPD: В комментах подсказали, что есть два Nginx Ingress:

1. От самого Kubernetes - https://github.com/kubernetes/ingress-nginx/
2. От F5/Nginx - https://github.com/nginx/kubernetes-ingress/

Речь в статье про первый.

🎤 Будни сетевика 😊