Почему jumbo frames включили, а производительность не выросла

Jumbo frames это MTU 9000 вместо стандартных 1500. Меньше заголовков на байт данных, меньше прерываний CPU. В теории быстрее, на практике часто никакого эффекта.

⏺Самая частая причина: один интерфейс или коммутатор на пути со стандартным MTU.

Пакеты фрагментируются или дропаются, выигрыша нет. Jumbo frames работают только если все устройства end-to-end настроены одинаково.

Проверяем что путь реально поддерживает 9000:

ping -M do -s 8972 <IP>

8972 это 9000 минус 28 байт заголовков. Если пакет прошёл, путь чистый.

⏺Вторая причина: приложение шлёт маленькими чанками. Jumbo frames помогают только когда есть что класть в большой пакет. Мелкие запросы останутся мелкими пакетами независимо от MTU.

⏺Третья: узкое место вообще не в сетевом стеке. Jumbo frames снижают CPU overhead от обработки пакетов, но если bottleneck в диске или логике приложения, результата не будет.

mpstat -I ALL 1
ethtool -S eth0 | grep rx_packets

⚡️Реально помогает в узких сценариях: iSCSI, NFS, HPC, высоконагруженные линки между серверами в одном датацентре. В смешанном трафике через разные устройства эффект минимальный.

N.A

BGP Zombie Routes: маршруты, которые не хотят исчезать

BGP withdrawal сообщает соседям, что маршрут больше недоступен. Но это не значит, что он сразу исчезнет из всех таблиц маршрутизации.

Cloudflare исследовала случаи, когда отозванные маршруты продолжали существовать в других сетях. Их называют BGP Zombies.

⏺Допустим, префикс 203.0.113.0/24 доступен через провайдера A. Провайдер отзывает маршрут, но часть AS ещё использует старую информацию.

Начинается path hunting. Маршрутизаторы перебирают альтернативные BGP-пути, некоторые из которых тоже уже недоступны. Из-за этого сходимость затягивается, а трафик может уходить в blackhole или петлю.

Проверяем маршруты на своём роутере:

show bgp ipv4 unicast 203.0.113.0/24
show ip route 203.0.113.0

Первая команда показывает известные BGP-пути, вторая - какой маршрут установлен в RIB. Но локальной таблицы мало. Через RIPE RIS или RouteViews можно посмотреть, продолжают ли другие AS видеть старый путь.

При плановой смене провайдера лучше сначала анонсировать префикс через нового, дождаться распространения маршрута и только потом отзывать старый.

Withdrawal означает, что маршрут отозван. Но не гарантирует, что весь интернет уже перестал его использовать.

N.A

ARP Flux: почему Linux отвечает не с того интерфейса

На сервере два интерфейса в одной подсети. У каждого свой IP, но при ARP-запросе к 192.168.1.10 сосед неожиданно получает MAC второго интерфейса.

Это ARP Flux. Linux по умолчанию рассматривает IP-адреса как принадлежащие всему хосту, а не строго конкретному интерфейсу.

⏺Как это происходит

Допустим, eth0 имеет адрес 192.168.1.10, а eth1 - 192.168.1.20.

Сосед спрашивает, кому принадлежит 192.168.1.10. Запрос приходит на eth1, и Linux может ответить MAC-адресом eth1, хотя нужный IP назначен на eth0.

В результате ARP-таблица соседа может неожиданно меняться, а трафик начинает приходить не на тот интерфейс.

⏺Проверяем настройки

sysctl net.ipv4.conf.all.arp_ignore
sysctl net.ipv4.conf.all.arp_announce

При arp_ignore=0 Linux может отвечать на ARP-запросы за локальные IP независимо от интерфейса, на который пришёл запрос.

⏺Ограничиваем ARP-ответы

sysctl -w net.ipv4.conf.all.arp_ignore=1
sysctl -w net.ipv4.conf.all.arp_announce=2

arp_ignore=1 разрешает отвечать только за адреса, назначенные входящему интерфейсу.
arp_announce=2 помогает избежать объявления неподходящего исходного IP в исходящих ARP-запросах.

N.A

Один VLAN не совпал, и DHCP перестал выдавать адреса

Клиент подключается к сети, линк поднят, но IP-адрес не получает. DHCP-сервер работает, свободные адреса есть, а Discover до него не доходит.

Проблема может быть в одном неверном PVID или настройке tagged/untagged на порту коммутатора.

⏺Где теряется DHCP Discover

Клиент отправляет DHCP Discover широковещательно, обычно без VLAN-тега.
Коммутатор принимает кадр и относит его к VLAN, заданному через PVID. Если вместо VLAN 20 на порту стоит VLAN 10, Discover попадёт не в тот широковещательный домен.

DHCP-сервер в VLAN 20 его просто не увидит.

⏺Проверяем VLAN на порту

На Linux bridge с включённой VLAN-фильтрацией:

bridge vlan show

Например:

eth1  10 PVID Egress Untagged
eth2  20

Здесь нетегированные кадры с eth1 попадут в VLAN 10, а не в VLAN 20.
Если клиент должен находиться в VLAN 20, проверяем и исправляем конфигурацию порта.

⏺Ищем Discover

tcpdump -eni eth1 'udp port 67 or 68'

Ключ -e показывает Ethernet-заголовок. На trunk-порту можно дополнительно проверить, с каким VLAN-тегом проходит DHCP-трафик.
Если Discover виден на клиентском порту, но отсутствует в нужном VLAN на uplink, проблема может быть в PVID, VLAN membership или правилах тегирования.

⚡️DHCP Discover не знает, в какой VLAN ему нужно попасть. Для нетегированного кадра это решает коммутатор. Один неверный PVID может отправить весь DHCP-трафик в чужую сеть.

N.A

RSS vs RPS vs RFS: кто распределяет сетевой трафик между CPU

На сервере 32 ядра, но при высокой сетевой нагрузке несколько ядер забиты под 100%, а остальные почти простаивают.

Проблема может быть в том, как входящие пакеты распределяются между CPU. В Linux для этого есть три механизма: RSS, RPS и RFS.

⏺RSS - распределение на уровне сетевой карты

NIC вычисляет хеш по заголовкам пакета и выбирает RX-очередь. Каждая очередь обычно обслуживается своим CPU через IRQ/NAPI.

Проверяем количество очередей:

ethtool -l eth0

Если у карты одна RX-очередь, аппаратное распределение трафика ограничено.

⏺RPS - распределение средствами ядра

Receive Packet Steering позволяет перенаправлять обработку пакетов на другие CPU уже после приёма через RX-очередь.
Смотрим маску разрешённых CPU:

cat /sys/class/net/eth0/queues/rx-0/rps_cpus

RPS полезен, когда аппаратных RX-очередей мало, но добавляет межъядерную обработку.

⏺RFS - распределение с учётом приложения

Receive Flow Steering идёт дальше. Он старается обрабатывать пакеты потока на том CPU, где выполняется приложение, которое их читает.

Это помогает уменьшить потери производительности из-за миграции данных между CPU-кешами.

Проверяем настройку:

cat /sys/class/net/eth0/queues/rx-0/rps_flow_cnt

⚡️RSS выбирает аппаратную RX-очередь, RPS распределяет обработку по CPU, а RFS учитывает расположение приложения.

Но больше распределения не всегда означает выше производительность. На многоканальных NIC дополнительный RPS может только увеличить overhead.

N.A

PBR vs VRF: два способа управлять маршрутизацией

Обе технологии позволяют отправлять трафик не по обычной таблице маршрутизации. Но решают разные задачи.

⏺PBR (Policy-Based Routing) выбирает маршрут по заданным условиям. Например, весь трафик из подсети 192.168.10.0/24 должен идти через второго провайдера, даже если default route указывает на первого.

На Linux это можно сделать через ip rule:

ip rule add from 192.168.10.0/24 table 100
ip route add default via 10.0.0.1 dev eth1 table 100

Теперь пакеты из этой подсети используют таблицу 100. Остальной трафик продолжает маршрутизироваться по обычным правилам.

⏺VRF (Virtual Routing and Forwarding) создаёт отдельный routing domain со своей таблицей маршрутизации.

Например, на одном сервере работают две изолированные сети. У каждой свой default gateway, а адресные пространства могут даже пересекаться.

Создаём VRF:

ip link add vrf-blue type vrf table 100
ip link set vrf-blue up
ip link set eth1 master vrf-blue

Теперь eth1 принадлежит VRF, а маршруты подключённых к нему сетей находятся в таблице 100. Для отдельного default route его нужно настроить дополнительно.

Посмотреть маршруты:

ip route show vrf vrf-blue

Главная разница в том, что PBR выбирает таблицу или маршрут по условиям, а VRF привязывает интерфейсы и трафик к отдельному домену маршрутизации.

N.A

Один IP, два MAC: как ARP-конфликт ломает сеть

Два устройства случайно получили одинаковый IP-адрес. Оба доступны на L2, оба отвечают на ARP-запросы, но MAC-адреса у них разные.

Для соседних хостов начинается путаница. Один ARP-ответ связывает 192.168.1.50 с первым MAC, следующий может заменить запись на MAC второго устройства.

В результате соединения периодически обрываются, SSH зависает, а ping то проходит, то нет.

⏺Смотрим neighbor table

ip neigh show 192.168.1.50

Запись может меняться между двумя MAC-адресами. Но это не обязательно происходит после каждого ARP-ответа: Linux учитывает состояние записи и правила её обновления.

⏺Ловим конфликт

tcpdump -eni eth0 arp

Если два устройства отвечают за один IP, в захвате можно увидеть ARP Reply с одинаковым sender IP, но разными sender MAC.

Дополнительно проверяем адрес через arping:

arping -I eth0 -c 5 192.168.1.50

Несколько ответов с разными MAC - сильный признак конфликта.

⏺Что происходит с соединениями

Когда сосед начинает отправлять кадры на другой MAC, пакеты попадают не на тот сервер. Старое TCP-соединение при этом не переносится на новое устройство.

N.A

Миф: Port Security защищает от всех атак на L2

Port Security ограничивает количество MAC-адресов на порту коммутатора. Например, разрешаем один MAC, и если появляется второй, порт блокируется или начинает отбрасывать нарушающий трафик в зависимости от режима.

Кажется, что этого достаточно для защиты от посторонних устройств. Но Port Security контролирует MAC-адреса, а не поведение самого устройства.

⏺Rogue DHCP Server

Атакующий подключает устройство с разрешённым MAC и начинает раздавать клиентам неправильный шлюз или DNS. Port Security не анализирует DHCP-ответы.

Для этого нужен DHCP Snooping, который запрещает ответы DHCP-сервера с недоверенных портов.

⏺ARP Spoofing

Устройство с разрешённым MAC отправляет поддельные ARP-ответы, связывая IP шлюза со своим MAC.
Port Security не проверяет соответствие IP и MAC внутри ARP. Этим занимается Dynamic ARP Inspection, используя доверенные привязки, например из DHCP Snooping.

⏺Подмена разрешённого MAC

Если атакующий узнает допустимый MAC и использует его вместо своего, Port Security не сможет определить личность устройства только по этому адресу.
Для аутентификации применяют 802.1X, хотя и он требует правильной настройки.

На Cisco проверяем состояние защиты:

show port-security interface Gi0/1
show ip dhcp snooping
show ip arp inspection

⚡️Port Security ограничивает MAC-адреса на порту. DHCP Snooping контролирует DHCP-серверы, DAI проверяет ARP, а 802.1X аутентифицирует подключение.
Один механизм не заменяет остальные.

N.A

Как проверить, куда исчезают пакеты в nftables

Порт открыт, маршрут есть, но соединение не устанавливается.

Проверять десятки правил firewall вручную неудобно, особенно когда пакеты проходят через несколько цепочек.

В nftables есть трассировка, которая показывает путь пакета через правила.

⏺Сначала включаем трассировку для нужного трафика. Например, для TCP-подключений к порту 443:

nft add table inet debug
nft 'add chain inet debug trace_in { type filter hook prerouting priority -301; policy accept; }'
nft add rule inet debug trace_in tcp dport 443 meta nftrace set 1

Теперь запускаем мониторинг:

nft monitor trace

Пробуем подключиться к серверу с другого устройства.

⏺В выводе появятся цепочки и правила, через которые проходит пакет. Например:

trace ... rule tcp dport 443 drop
trace ... verdict drop

Так можно увидеть не просто факт блокировки, а конкретное правило, которое приняло решение.
Если пакет вообще не появляется в трассировке, стоит проверить, доходит ли он до выбранного hook и соответствует ли условию трассировки.

⏺После диагностики удаляем временную таблицу:

nft delete table inet debug

⚡️tcpdump показывает, что пакет пришёл на интерфейс. nft monitor trace помогает выяснить, что с ним произошло внутри nftables.

N.A

3 ошибки при настройке BGP prefix-list

Prefix-list кажется простой вещью: указал сеть, разрешил или запретил маршрут. Но одна неточная маска может изменить фильтрацию сразу для сотен префиксов.

⏺Забыли про le и ge

Например, на Cisco:

ip prefix-list FILTER permit 10.0.0.0/8

Это правило разрешает только точный префикс /8. Маршрут 10.10.0.0/16 под него не попадёт.

Чтобы разрешить более специфичные сети:

ip prefix-list FILTER permit 10.0.0.0/8 le 24

Теперь подходят префиксы от /8 до /24 внутри указанной сети.

⏺Случайно разрешили слишком много

ip prefix-list FILTER permit 0.0.0.0/0 le 32

Это не разрешение только default route. Такое правило подходит под любой IPv4-префикс.

Если нужен исключительно маршрут по умолчанию:

ip prefix-list FILTER permit 0.0.0.0/0

⏺Забыли про implicit deny

В конце prefix-list действует неявный запрет. Если маршрут не совпал ни с одним разрешающим правилом, он будет отклонён при применении списка как фильтра.
Проверяем:

show ip prefix-list FILTER
show ip bgp neighbors 192.0.2.1 advertised-routes

Последняя команда помогает увидеть, что реально анонсируется соседу. Синтаксис зависит от платформы.

⚡️В prefix-list важно не только указать сеть, но и правильно задать допустимую длину префикса. Разница между /8 и /8 le 24 может решить, какие маршруты вообще попадут к соседу.

N.A