Распределение HTTP-запросов по версиям протокола
(данные по России за последние 6 месяцев, источник: radar.cloudflare.com)

🟢HTTP/1: 32% (▼4%)
🟢HTTP/2: 45% (▲4%)
🟢HTTP/3: 23% (без изменений)

Рост доли HTTP/2 свидетельствует о постепенном отказе от HTTP/1. Однако HTTP/3 пока не показывает динамики, несмотря на его казалось бы «очевидные» преимущества.

Порассуждаем, почему в РФ не растет доля HTTP/3:

1️⃣ Ограниченная поддержка клиентов: не все старые устройства и браузеры поддерживают HTTP/3.

2️⃣ Инфраструктурные сложности: требуется обновление серверного ПО (например, модуль HTTP/3 для Nginx/Apache), необходима настройка TLS 1.3 и проверка корректной работы UDP-трафика. Некоторые провайдеры блокируют UDP на порту 443 (включая домашние сети и даже публичный Wi-Fi, например, в «Сапсане»).

3️⃣ Вопрос целесообразности: затраты на внедрение могут не окупаться, особенно если текущие решения (HTTP/2) работают стабильно

4️⃣ Блокировки РКН

Мое мнение: кто хотел уже внедрили, остальные не сильно торопятся по причинам выше.

P.S. Только начинаю погружаться в HTTP/3, буду рад услышать про ваш опыт.

В блоге HAProxy рассказывают, как их балансировщик нагрузки впервые обработал более 2 миллионов HTTP-запросов в секунду на одном сервере!

Что использовали для теста:
🟢AWS инстанс c6gn.16xlarge (64 ядра, 100 Gb/s сеть)
🟢HAProxy версии 2.4
🟢Процессор ARM (Graviton2)

Ключевые результаты:
🟢 2,08 млн запросов/сек без шифрования
🟢 2,01 млн запросов/сек с TLSv3-шифрованием
🟢 Добавочная задержка от Haproxy — менее 0,4 мс

Отдельно отмечу про привязку сетевых прерываний (IRQ) к отдельным ядрам, чтобы они не мешали обработке запросов самим HAProxy. Мы к этому тоже пришли в свое время на кэш-серверах CDN, когда пытались разогнать производительность на максимум.

В марте 2026 года Cisco запускает новый трек экзаменов в области беспроводных технологий - Wireless (CCNP + CCIE).

В рамках нового трека будут проверяться знания по Wi-Fi 6/7, Meraki и др., а из CCNP Enterprise уберут все, что связано с Wi-Fi.

Если кто-то этого ждал, возможно, это хорошие новости, но я таких не знаю 🤷

Лично я никогда не любил ни экзамены Cisco, ни Wi-Fi, хотя пару контроллеров и десяток точек доступа настроил (домашний не в счет) - этой участи редко удается избежать сетевику.

P.S. Актуально для кого? 😅

https://www.networkworld.com/article/4046928/cisco-launches-dedicated-wireless-certification-track.html

Отчет curator: DDoS, боты и BGP-инциденты во 2 квартале 2025 года

Основные моменты:

🟢Максимальный битрейт атаки UDP flood - 965 Гбит/с, SYN flood - 229 Гбит/с, IP flood - 214 Гбит/с и TCP flood - 169 Гбит/с.
🟢Самая продолжительная DDoS-атака длилась 65.5 часов
🟢Установлен рекорд по размеру DDoS-ботнета - 4.6 млн устройств
🟢Самая популярная L7-атака - Request Rate Patterns
🟢Инциденты BGP: 4 hijack, 10 route leaks
🟢Лидеры среди источников атак: Россия, США, Бразилия

На одном из наших проектов используется VMware NSX-T, но с нашей стороны есть доступ только к Cloud Director, т.е. все «кишки» недоступны. Тем не менее, чтобы общаться с поддержкой на одном языке, нам пришлось разобраться в архитектуре: что такое DR, SR, T0/T1 и т.д.

Ниже приведены ссылки, где можно ознакомиться с основами NSX-T. Для общего понимания его работы этого будет достаточно:

🟢Что такое NSX-T
🟢NSX-T Component Overview
🟢NSX-T Series Part 1-16

В Junos существуют различные типы Next-hop:

🟢broadcast (bcst)—Broadcast.
🟢deny—Deny.
🟢discard (dscd) —Discard.
🟢hold—Next hop is waiting to be resolved into a unicast or multicast type.
🟢indexed (idxd)—Indexed next hop.
🟢indirect (indr)—Indirect next hop.
🟢local (locl)—Local address on an interface.
🟢routed multicast (mcrt)—Regular multicast next hop.
🟢multicast (mcst)—Wire multicast next hop (limited to the LAN).
🟢multicast discard (mdsc)—Multicast discard.
🟢multicast group (mgrp)—Multicast group member.
🟢receive (recv)—Receive.
🟢reject (rjct)—Discard. An ICMP unreachable message was sent.
🟢resolve (rslv)—Resolving the next hop.
🟢unicast (ucst)—Unicast.
🟢unilist (ulst)—List of unicast next hops. A packet sent to this next hop goes to any next hop in the list.
🟢VxLAN Local—EVPN Type 5 route in kernel.

Также можно встретить тип dead.

Пример вывода команды:

show route forwarding-table vpn internet destination 42.119.54.0/24 extensive 
Routing table: internet.inet [Index 17] 
Internet:
    
Destination:  42.119.54.0/24
  Route type: user                  
  Route reference: 0                   Route interface-index: 0   
  Multicast RPF nh index: 0             
  P2mpidx: 0              
  Flags: sent to PFE, rt nh decoupled  
  Next-hop type: dead                  Index: 1102     Reference: 21

▎Инструкция чтобы увидеть dead своими глазами:

1. Необходим маршрутизатор Juniper MX.
2. Должен быть установлен софт 20.4R2.7. Да, он довольно старый.
3. Необходимо изменить MTU глобально на irb-интерфейсе: set interfaces irb mtu 9000.

Это приведет к флапу BGP-сессий и, как следствие, к неверно запрограммированным маршрутам на PFE с Next-hop "dead". Проблема воспроизводится 100%.

▎Что с этим делать:

1. Обновиться до более свежей версии, например, до 23.4R2-S3.9 - в этой версии проблема точно устранена.
2. Перед глобальным изменением MTU на irb-интерфейсе явно задать IP MTU для BGP-пиров, тогда также будет все в порядке.

В интернете можно найти примеры похожих багов, но точного совпадения найти не удалось.

Задача: на виртульной машине с Ubuntu 24 изолировать два сетевых интерфейса между собой.

Мы боролись с ассиметрией в виртуальной среде 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%. Попробую разобраться как он работает.

#Задача

Поразбирался с 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: 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] - это индексы, при этом в зависимости от направления они могут быть:

🟢 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: 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?
Нашел еще доклад + презу

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

Сегодня стартовала оффлайн часть ключевой отраслевой конференции по технологиям видео VideoTech 2025

СПб, 7-8 октября.

Отличная возможность обменяться опытом, рад буду пообщаться.

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