5 команд для поиска проблем с ARP после замены сервера

Заменили сервер, оставили тот же IP, интерфейс поднялся, gateway пингуется - но часть устройств всё ещё пытается отправлять трафик на старый MAC.
Проверяем по порядку.

1️⃣Смотрим текущий neighbor state

ip neigh show

Например:

10.0.0.1 dev eth0 lladdr aa:bb:cc:dd:ee:ff STALE

Важно не только наличие MAC, но и состояние записи: REACHABLE, STALE, DELAY, PROBE, FAILED.

2️⃣Проверяем ARP непосредственно до gateway

arping -I eth0 10.0.0.1

Если ответы приходят с неожиданного MAC, проблема уже не в маршрутизации.

3️⃣Смотрим ARP на интерфейсе

tcpdump -ni eth0 arp

Можно увидеть, кто спрашивает:

Who-has 10.0.0.10?

и кто отвечает:

10.0.0.10 is-at 11:22:33:44:55:66

Если разные устройства получают разные MAC для одного IP - это уже серьёзный признак конфликта или некорректного failover.

4️⃣Наблюдаем изменения neighbor table в реальном времени

ip monitor neigh

Полезно, когда проблема появляется не постоянно: можно увидеть, как запись меняется между состояниями или удаляется.

5️⃣Проверяем доступность после обновления ARP

ping -c 5 10.0.0.1

Но ping здесь - только финальная проверка. Успешный ICMP сам по себе не говорит, что ARP работает корректно.

Типичный сценарий после замены:

старый сервер
10.0.0.10 → AA:AA:AA:AA:AA:AA

        ↓ замена

новый сервер
10.0.0.10 → BB:BB:BB:BB:BB:BB

Если где-то ещё осталась старая ARP-запись, трафик может продолжать уходить на AA:AA:AA:AA:AA:AA.

Поэтому после замены сервера полезно проверять не только:

ip addr
ip route

но и связку:

IP → ARP/neighbor → MAC → реальный интерфейс

Именно она часто объясняет ситуацию, когда сервер уже заменили, а сеть ещё живёт по старой записи.

N.A.

Читать полностью…

Как локальный трафик может вообще не попадать на физический интерфейс

Если приложение обращается к IP, который Linux считает своим локальным адресом, пакет не отправляется на физический интерфейс.

Например, на сервере:

eth0 → 10.0.0.10/24

Приложение выполняет:

curl http://10.0.0.10:8080

Интуитивно кажется, что будет:

application
    ↓
eth0
    ↓
switch
    ↓
eth0
    ↓
server

Но Linux сначала проверяет destination и видит, что 10.0.0.10 принадлежит самому хосту.

Маршрут будет иметь тип local:

ip route get 10.0.0.10

Например:

local 10.0.0.10 dev lo src 10.0.0.10

Поэтому физический eth0 в этом обмене вообще не участвует:

application
    ↓
local routing
    ↓
lo
    ↓
local socket

Это важно при диагностике.


Можно поставить:

tcpdump -ni eth0 port 8080

и не увидеть вообще ничего, хотя curl успешно устанавливает соединение.

А вот:

tcpdump -ni lo port 8080

покажет этот трафик.

Причём это не означает, что lo - какой-то физический интерфейс. Это отдельный путь local delivery внутри сетевого стека Linux.

Поэтому проверка «пакет дошёл до сервера через его сетевую карту?» иногда вообще поставлена неправильно: если источник и destination находятся на одном хосте, пакет мог никогда не попасть на wire.

N.A.

Читать полностью…

Большой RX ring не всегда делает сеть быстрее

У сетевой карты есть очереди, куда складываются входящие пакеты, пока драйвер не успел их обработать.

При burst-трафике большой ring действительно может помочь пережить кратковременный всплеск:

NIC → RX ring → driver → kernel

Но бесконечной очереди не бывает.

Если CPU стабильно обрабатывает, например, 500 тыс. пакетов/с, а приходит 700 тыс.:

500k → 700k → 900k → ...

ring постепенно заполняется, после чего начинаются drops.

Увеличение ring позволяет накопить больше пакетов:

ethtool -g eth0
ethtool -G eth0 rx 4096

Но если скорость обработки не изменилась, это только отодвинет момент переполнения.
Более того, слишком глубокая очередь может увеличить latency: пакет уже не теряется, но дольше ждёт своей очереди на обработку.

Поэтому при проблемах с сетью важно различать:

packet loss
и
packet queueing

Первое означает, что пакет исчез. Второе, что пакет всё ещё жив, но уже слишком долго ждёт обработки.

N.A.

Читать полностью…

📂 Linux bridge учит MAC-адреса почти как обычный коммутатор

Когда Linux работает как bridge, он не просто механически пересылает Ethernet-кадры между интерфейсами.

У него есть собственная forwarding database - FDB.

Когда кадр приходит на bridge, ядро смотрит на его source MAC и запоминает, откуда он пришёл:

aa:bb:cc:dd:ee:01 → eth0
aa:bb:cc:dd:ee:02 → eth1

Посмотреть таблицу можно:

bridge fdb show

После этого кадр для aa:bb:cc:dd:ee:02 уже не нужно отправлять на все порты - bridge знает, что destination находится за eth1.

Если destination MAC неизвестен, кадр будет flood’иться по подходящим портам. После получения ответа bridge снова обновит FDB.

У записей есть timeout, поэтому старый MAC постепенно исчезает:

bridge fdb show br br0

Особенно интересно это проявляется при миграции VM.

Было:

VM → eth0

После миграции:

VM → eth1

MAC тот же, но source frames начинают приходить с другого интерфейса. Bridge переучивает запись:

old MAC → eth0
        ↓
new MAC → eth1

Если MAC начинает постоянно перемещаться между портами, можно получить MAC flapping - и тогда проблема уже не в IP-маршрутизации.
Linux bridge в таком режиме фактически выполняет ту же базовую функцию, что и физический L2-коммутатор: строит таблицу MAC → порт на основании уже увиденного трафика.

N.A.

Читать полностью…

Почему ss показывает тысячи соединений, а netstat - другую картину

На одном сервере можно запустить:

ss -ant

и получить тысячи TCP-соединений, а затем:
netstat -ant
и увидеть совсем другое количество.

Это не обязательно означает, что один из инструментов врёт.
ss работает через современный интерфейс ядра Linux - NETLINK_INET_DIAG.

Ядро отдаёт ему информацию о сокетах напрямую, поэтому ss может получать состояние соединений без перебора /proc и без старого механизма netstat.

netstat из пакета net-tools - устаревший инструмент. Его возможности и способ получения данных отличаются, а часть информации может отображаться иначе.

Особенно заметна разница на серверах с большим количеством ephemeral connections и быстро меняющимся состоянием TCP.

Для диагностики лучше смотреть не просто количество строк:

ss -s

а разбивку состояний:

ss -ant | awk 'NR>1 {print $1}' | sort | uniq -c

Например:

ESTAB      18420
TIME-WAIT   7312
SYN-RECV    428

И отдельно проверить конкретный listener:
ss -lntp

Важный момент: TIME-WAIT, SYN-RECV, ESTAB и listening sockets - это разные состояния kernel socket state. Поэтому простое сравнение «сколько строк показывает утилита» может давать совершенно разные выводы.

ss сегодня является основным инструментом для анализа TCP/UDP-сокетов в Linux, а netstat в новых системах обычно оставляют только ради совместимости со старыми привычками и скриптами.

N.A.

Читать полностью…

Ping 1 мс не всегда означает, что сеть работает быстро (но почему?)

Можно получить RTT в 1–2 мс и при этом иметь очень плохую передачу данных.
ping проверяет только время прохождения ICMP-пакета туда и обратно.

Он почти ничего не говорит о том, сколько пакетов реально теряется, насколько забит канал и что происходит с TCP при передаче.

Например, при потере даже небольшого процента TCP-пакетов скорость может резко просесть.

Потерянный сегмент приходится передавать заново, а TCP дополнительно уменьшает congestion window.

В итоге:

RTT = 2 ms
packet loss = 1%

может оказаться намного хуже для TCP, чем:

RTT = 50 ms
packet loss = 0%

Проверять нужно не только задержку:

ping -c 100 <server-ip>

но и реальные потери при передаче:

iperf3 -c <server-ip> -t 30

А на Linux посмотреть retransmissions:

ss -ti

Если в выводе растёт retrans, проблема уже не в том, что «ping маленький».

Низкий RTT показывает, насколько быстро пакет возвращается. Он не показывает, насколько хорошо сеть передаёт поток данных.

N.A.

Читать полностью…

📂 Почему Linux иногда отбрасывает корректный пакет из-за rp_filter

Ситуация выглядит странно: маршрут до сервера есть, интерфейс поднят, tcpdump показывает входящие пакеты, но соединение не устанавливается.

Одна из причин - Reverse Path Filtering.

1️⃣Что происходит

Linux получает пакет от 10.20.30.50 на eth1 и проверяет, через какой интерфейс он сам отправил бы трафик обратно к 10.20.30.50.

Если маршрут указывает на eth0, а пакет пришёл через eth1, ядро может решить, что источник подозрительный, и отбросить пакет.

Проверить настройку:

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.eth1.rp_filter

2️⃣Почему это часто ломается

Особенно заметно при:

• нескольких uplink
• ECMP
• Policy-Based Routing
• VRF
• асимметричной маршрутизации
• балансировщиках и firewall-кластерах

Например:

Internet → eth1 → server
server → eth0 → Internet

Маршрутизация работает, но обратный путь отличается от входящего.

3️⃣Как увидеть проблему

Сначала смотрим, куда ядро отправит ответ:

ip route get 10.20.30.50

Затем проверяем фактический входящий трафик:

tcpdump -ni eth1 host 10.20.30.50

Если пакет виден на интерфейсе, но приложение его не получает, стоит проверить фильтрацию на уровне ядра.

4️⃣Какие значения бывают

rp_filter=0 — проверка отключена

rp_filter=1 — strict mode, обратный маршрут должен совпадать с входящим интерфейсом

rp_filter=2 — loose mode, достаточно существования маршрута до источника

Для сложной маршрутизации strict mode часто становится источником трудноуловимых проблем.

5️⃣Что важно проверить перед изменением

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter
sysctl net.ipv4.conf.eth0.rp_filter
sysctl net.ipv4.conf.eth1.rp_filter

И обязательно смотреть не только all, но и параметры конкретного интерфейса - итоговое поведение зависит от них.

N.A.

Читать полностью…

Cross-zone traffic и неожиданный latency

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

Особенно часто это всплывает после масштабирования: backend поднялся в другой зоне, а клиент продолжил ходить к нему через балансировщик или другой региональный компонент.

Посмотреть, куда реально уходит соединение:

ss -tnp

Если адреса backend’ов принадлежат разным зонам, следующий вопрос - действительно ли трафик идёт напрямую между ними.

traceroute -T -p 443 <backend-ip>

Но одного маршрута мало.

Интереснее сравнить latency до backend’ов в разных зонах:

mtr -T -P 443 <backend-ip>

Иногда разница небольшая на одном запросе, но начинает сильно влиять на p95/p99, когда сервис делает несколько последовательных обращений к другим компонентам.

Ещё неприятнее, когда frontend находится в одной зоне, application - в другой, а database - снова в первой. Один пользовательский запрос превращается в несколько cross-zone переходов.

⚡️В итоге проблема может выглядеть как “медленный backend”, хотя приложение просто постоянно гоняет данные между зонами. При масштабировании такие вещи легко пропустить, если смотреть только на CPU, RPS и средний latency.

N.A.

Читать полностью…

Один backend получает почти весь трафик

На графике LB всё выглядит подозрительно: три backend’а работают, healthcheck зелёный, но один получает 80–90% запросов.

Проверять сам алгоритм балансировки недостаточно. В L4 балансировке решение часто принимается для соединения, а не для каждого запроса.

Для начала можно посмотреть распределение TCP-сессий на backend’ах:

ss -Htn state established '( sport = :443 )' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr

Если перекос уже здесь, проблема появилась до уровня HTTP.

Дальше интересно посмотреть, как LB выбирает backend для разных потоков. При ECMP или L4 hashing одинаковые параметры потока могут постоянно попадать в один и тот же bucket.

ipvsadm -Ln --stats

Для IPVS здесь хорошо видны реальные counters по backend’ам, а не только состояние healthcheck.

Ещё одна ловушка - connection reuse.

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

ss -Htn state established | awk '{print $4}' | sort | uniq -c | sort -nr | head

Поэтому RPS между backend’ами может отличаться в разы даже при идеально работающем алгоритме распределения соединений.

Если используется persistence, sticky sessions или hash по source IP, перекос становится ещё сильнее: несколько крупных клиентов фактически могут “забрать” один backend целиком.

И тогда проблема выглядит как сломанный балансировщик, хотя LB честно выполняет выбранную ему стратегию.

N.A.

Читать полностью…

Как поймать внезапный ARP-resolve timeout

Когда «всё работает… но периодически что-то замирает», очень часто виноват ARP.

Хост просто не может быстро получить MAC адрес - и весь трафик встаёт на паузу. Особенно больно это бьёт по VoIP, SSH и интерактивным сервисам.

Обычно такие таймауты не видны в обычных логах, поэтому отлавливать их нужно вручную.

1️⃣Проверяем, как часто хост делает ARP-запросы

Если сосед «теряется», хост начнёт усиленно спрашивать его MAC.

Linux:

tcpdump -ni eth0 arp

Если видишь 2–3 повторяющихся ARP Requests подряд → проблема.

Cisco:

debug arp

или

show arp

Если запись в ARP-таблице часто «флапает», это ненормально.

2️⃣Смотрим, что происходит в момент задержки

Отслеживаем, пропадают ли ответы:

tcpdump -ni eth0 "arp or icmp"

Если ping висит, а в дампе есть ARP Requests без ARP Reply → таймаут найден.

3️⃣Проверяем ARP-таблицу на переполнения и expiry

Если ARP-таблица забилась или записи слишком быстро удаляются → будут постоянные timeouts.

Linux:

ip -s neigh

Подозрительные признаки:
• состояние FAILED
• резкий рост timeouts
• записи часто переходят FAILED → REACHABLE → FAILED

4️⃣Проверяем ARP кэш на коммутаторе

Иногда виноват L2 — коммутатор забывает MAC или шлёт фреймы не туда.

Cisco:

show mac address-table dynamic | include <MAC>

Если MAC постоянно пропадает → проблема на сегменте.

N.A.

Читать полностью…

Firewall rule ordering: почему одно правило ломает всё ниже

Добавили всего одно правило в firewall - и часть сервисов перестала работать.

При этом сами правила выглядят правильными, а нужные allow вообще присутствуют в конфигурации.

Во многих firewall обработка идёт сверху вниз, и первое совпавшее правило завершает проверку. Всё, что находится ниже, уже не участвует.

iptables -L INPUT --line-numbers -n -v

Сразу видно порядок правил и счётчики срабатываний. Нередко оказывается, что трафик вообще не доходит до нужного ACCEPT.

Если используется nftables, полезнее смотреть итоговый ruleset, а не отдельные таблицы.

nft list ruleset

Так проще заметить цепочки, jump’ы и правила, которые перехватывают трафик раньше ожидаемого.

Когда причина всё ещё неочевидна, помогает трассировка обработки пакета.

nft monitor trace

Она показывает, через какие цепочки проходит пакет и на каком именно правиле обработка заканчивается.

Ещё один полезный приём - посмотреть, какое правило действительно набирает счётчики.

iptables -L -v -n

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

В больших конфигурациях порядок правил зачастую важнее их содержания. Одно слишком общее DROP, REJECT или широкое условие в начале цепочки способно незаметно перечеркнуть десятки корректных правил ниже.

N.A.

Читать полностью…

Классика 🤵‍♂️

N.A.

Читать полностью…

Основные причины ошибки «SSH Connection Refused»

Ошибка «SSH Connection Refused» возникает, когда удаленный сервер отклоняет запрос на соединение.

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

1️⃣SSH-клиент не установлен

Если на локальной машине отсутствует SSH-клиент, подключение к серверу невозможно. Проверьте, установлен ли SSH-клиент, командой:

ssh

Если команда не найдена, установите SSH-клиент:
Для Ubuntu/Debian:

sudo apt install openssh-client

Для CentOS/RHEL:

sudo yum install openssh-client

2️⃣ SSH-сервер не установлен на удаленном хосте

Чтобы принимать соединения, на сервере должен быть установлен SSH-демон. Проверьте это, выполнив команду:

ssh localhost

Если появляется сообщение «Connection refused», установите сервер OpenSSH:
Для Ubuntu/Debian:

sudo apt install openssh-server

Для CentOS/RHEL:

sudo yum install openssh-server

3️⃣ Неверные учетные данные или IP-адрес

Часто ошибка вызвана неправильным вводом имени пользователя, пароля или IP-адреса. Убедитесь, что данные верны, и проверьте, какой порт используется сервером:

grep Port /etc/ssh/sshd_config

4️⃣ Служба SSH не работает

Если служба SSH не запущена, сервер не сможет принимать соединения. Проверьте её статус:

sudo service ssh status

Если служба не активна, запустите её:

sudo systemctl start sshd
sudo systemctl enable sshd

N.A.

Читать полностью…

С днём системного администратора! 🏆

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

Желаю стабильного аптайма, спокойных дежурств, крепких нервов и достойной зарплаты. За localhost! 🍻🍷

N.A.

Читать полностью…

RouterOS: как работает /tool torch и чем лучше обычного tcpdump

tcpdump показывает сырые пакеты, ты сам разбираешь, что происходит.

torch работает на уровне flow: группирует трафик по src/dst IP, протоколу и порту, показывает скорость каждого потока в реальном времени. Не дамп, а живая таблица активных соединений с полосой.

Запускаем через CLI:

/tool torch interface=ether1

По умолчанию показывает все потоки. Фильтруем по протоколу:

/tool torch interface=ether1 ip-protocol=tcp
/tool torch interface=ether1 ip-protocol=udp port=53

Смотрим только трафик конкретного хоста:

/tool torch interface=ether1 src-address=192.168.1.100
/tool torch interface=ether1 dst-address=8.8.8.8

Комбинируем фильтры:

/tool torch interface=ether1 src-address=192.168.1.0/24 ip-protocol=tcp port=443

Покажет все HTTPS-потоки из внутренней подсети с live-скоростью каждого.

Где torch выигрывает у tcpdump

На загруженном интерфейсе tcpdump генерирует огромный поток данных который сложно читать на лету. torch агрегирует: вместо тысяч строк видишь десяток потоков отсортированных по полосе.

Сразу понятно, кто жрёт канал.

torch работает в winbox через меню Tools, там же можно сортировать колонки мышкой. Для быстрой диагностики перегруза удобнее чем любой CLI.

Где tcpdump нужен, а torch нет

Когда нужен payload: содержимое пакетов, флаги TCP, конкретные заголовки. torch видит только flow-статистику, внутрь пакета не смотрит. На Микротик для этого есть packet sniffer:

/tool sniffer start
/tool sniffer packet print
/tool sniffer stop

Или с записью в pcap для анализа в Wireshark:

/tool sniffer set filter-interface=ether1 file-name=capture.pcap
/tool sniffer start

N.A.

Читать полностью…

Почему BGP может выбрать более длинный путь

В BGP легко представить выбор маршрута как простое правило: меньше AS в пути - лучше.

Но AS-path length - только один из атрибутов, которые участвуют в best-path selection.

Например, маршрутизатор получил:

10.10.10.0/24

peer A:  AS_PATH 64501 64502
peer B:  AS_PATH 64503 64504 64505

На первый взгляд BGP должен выбрать A.
Но если у маршрута от B выше LOCAL_PREF, он может стать предпочтительным ещё до того, как длина AS_PATH вообще сыграет роль.

Условно:

A → LOCAL_PREF 100 → AS_PATH 2

B → LOCAL_PREF 200 → AS_PATH 3
BGP выберет B.

Это важный момент: BGP ищет не «самый короткий маршрут», а лучший маршрут по последовательности атрибутов.

На выбор могут влиять:

LOCAL_PREF
      ↓
AS_PATH
      ↓
ORIGIN
      ↓
MED
      ↓
eBGP / iBGP
      ↓
IGP metric
      ↓
router ID / другие tie-breaker

Поэтому добавление ещё одного AS в путь не обязательно заставит трафик пойти через другого провайдера.

Посмотреть, почему конкретный маршрут победил:

show bgp ipv4 unicast 10.10.10.0/24

А в FRRouting удобно смотреть ещё и выбранный best path:

vtysh -c "show bgp ipv4 unicast 10.10.10.0/24"

Именно поэтому при разборе BGP-проблемы вопрос «у какого peer меньше AS_PATH?» часто оказывается слишком ранним.

Сначала нужно понять, какой атрибут сделал маршрут предпочтительнее.

N.A.

Читать полностью…

📂Gratuitous ARP меняет ARP-кэш без единого ARP-запроса

Обычно ARP работает так:

Host A → Who has 10.0.0.10?
Host B → 10.0.0.10 is aa:bb:cc:dd:ee:ff

Но устройство может само отправить ARP-пакет, не дожидаясь никакого запроса.

Это и есть Gratuitous ARP.
Например, виртуальный IP переезжает:

до:

10.0.0.10 → aa:aa:aa:aa:aa:aa

после:

10.0.0.10 → bb:bb:bb:bb:bb:bb

Новое устройство отправляет объявление:

10.0.0.10 is-at bb:bb:bb:bb:bb:bb

Соседи получают его и обновляют ARP-кэш.

В результате трафик начинает идти на новый MAC практически сразу - без того, чтобы каждый клиент самостоятельно выполнял ARP lookup.

Посмотреть такие объявления:

tcpdump -ni eth0 arp

А текущую таблицу соседей:

ip neigh show

Это особенно важно при:

⏺failover виртуального IP ⏺миграции виртуальной машины ⏺переключении кластера на резервный узел

Поэтому после переноса сервиса между хостами может измениться не DNS, не маршрут и не IP-адрес - меняется только MAC, связанный с уже известным IP, и сеть быстро узнаёт об этом через gratuitous ARP.

N.A.

Читать полностью…

Сетевой пакет может потеряться ещё внутри NIC

В tcpdump нет пакета - легко сделать вывод, что он не пришёл на сервер.
Но между физическим портом и tcpdump находится сама сетевой карта.

У NIC есть собственные RX ring buffers. Драйвер забирает из них дескрипторы и передаёт полученные данные ядру.

При перегрузке очередь может не успеть обработать входящие пакеты:

NIC
 ↓
RX ring
 ↓
driver
 ↓
kernel
 ↓
tcpdump

Если проблема возникает на уровне NIC/driver, пакет может исчезнуть до того, как станет виден обычному packet capture.

Поэтому при странных потерях полезно смотреть не только:

ip -s link show eth0

но и аппаратную статистику:

ethtool -S eth0

А размеры RX/TX ring:

ethtool -g eth0

Можно увидеть отдельные counters вроде rx_missed_errors, rx_no_buffer или специфичные для конкретного драйвера drops.

Это важный момент при диагностике: если пакет не попал в tcpdump, это ещё не доказывает, что его не получила сетевая карта.

N.A.

Читать полностью…

Пакет можно отбросить до создания skb

Обычно сетевой пакет проходит довольно длинный путь внутри Linux:

NIC → driver → skb → network stack → socket → application

Но skb создаётся не в самом начале.

XDP может выполнить программу прямо на раннем этапе обработки пакета, когда драйвер уже получил его из NIC, но обычный sk_buff ещё не создан.

Поэтому решение можно принять буквально на входе:

NIC
 ↓
driver
 ↓
XDP
 ├── DROP
 ├── PASS → обычный network stack
 ├── TX
 └── REDIRECT

Например, простой XDP-программе достаточно проверить destination IP и сразу отбросить пакет:

SEC("xdp")
int drop_packet(struct xdp_md *ctx)
{
    return XDP_DROP;
}

При XDP_DROP пакет вообще не доходит до обычного kernel networking stack.

Это важно под большой нагрузкой: если отбросить ненужный трафик после создания skb, часть работы ядро уже успело выполнить. XDP позволяет перенести фильтрацию значительно раньше.

Проверить, загружена ли XDP-программа:

ip -details link show dev eth0

И посмотреть статистику:

ip -s link show dev eth0

Поэтому «firewall на сервере» - не всегда означает, что пакет сначала проходит весь сетевой стек, а потом его фильтруют. В Linux точка принятия решения может находиться практически сразу после получения кадра сетевой картой.

N.A.

Читать полностью…

Один VLAN может проходить через несколько коммутаторов без единого L3-интерфейса

VLAN не привязан к конкретному коммутатору.

Если между устройствами настроен trunk, один и тот же broadcast domain может растянуться через несколько физических узлов.

Например:

PC ── SW1 ══ SW2 ══ SW3 ── Server
      VLAN 30   VLAN 30   VLAN 30

На trunk-портах кадр VLAN 30 идёт с тегом 802.1Q.

Проверка на Linux:

ip -d link show eth0.30

На Cisco:

show interfaces trunk
show vlan id 30

При этом шлюз VLAN может находиться вообще на другом устройстве:

PC → SW1 → SW2 → SW3 → Router
                         VLAN 30

Коммутаторы между ними работают только на L2 и не принимают решение о маршрутизации.

Но есть важный нюанс: чем дальше растянут L2-домен, тем больше устройств получают его broadcast и unknown-unicast traffic.

Поэтому проблема иногда выглядит как «сеть внезапно стала шумной», хотя IP-маршрутизация при этом вообще не менялась.

N.A.

Читать полностью…

Почему TCP-порт 443 - это не обязательно один TCP-порт?

Когда говорят «сервер слушает 443 порт», легко представить один socket, который принимает все HTTPS-соединения.

Но TCP идентифицирует соединение не только по порту назначения.

Для него важна комбинация:

src IP + src port + dst IP + dst port

Например, сервер слушает:

10.0.0.10:443

А клиенты создают:

10.0.1.20:49152 → 10.0.0.10:443 10.0.1.21:49153 → 10.0.0.10:443 10.0.1.22:49154 → 10.0.0.10:443

Все три соединения приходят на один :443, но TCP воспринимает их как разные соединения.

И именно поэтому веб-сервер может одновременно обслуживать тысячи клиентов через один порт.

Но есть ещё интереснее.

Один и тот же порт 443 могут одновременно слушать несколько процессов, если используется SO_REUSEPORT.

Например:

ss -lntp | grep :443

несколько worker-процессов могут иметь собственные listening sockets на одном IP:443.

Ядро само распределяет новые соединения между ними.

При этом уже установленное соединение не прыгает между процессами: выбранный socket становится владельцем конкретного TCP-потока.

Поэтому фраза «порт 443 занят веб-сервером» на практике скрывает сразу несколько уровней:

443 - номер порта
IP:443 - endpoint
4-tuple - конкретное TCP-соединение
socket - объект, через который процесс работает с этим соединением

Именно поэтому один:443 способен обслуживать огромное количество независимых TCP-соединений одновременно.

N.A.

Читать полностью…

Default route из нескольких источников

На маршрутизаторе одновременно живут default route из BGP, OSPF и static.

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

Смотреть только show ip route мало. Сначала интересно понять, что именно BGP считает лучшим кандидатом:

show ip bgp 0.0.0.0

А затем сравнить это с тем, что OSPF держит у себя:

show ip ospf rib 0.0.0.0

Здесь уже может выясниться, что оба протокола имеют рабочий default, но в общую RIB попадает только один.

Дальше можно проверить конкретный поток:

show ip cef exact-route <src> <dst>

И увидеть, через какой интерфейс и next-hop он реально будет отправлен.

Самый интересный случай - когда выбранный маршрут не устанавливается в FIB из-за проблем с recursive next-hop, и forwarding продолжает использовать другой доступный путь.

show ip cef 0.0.0.0 internal

👀 Получается несколько независимых решений: BGP выбирает свой best path, OSPF - свой, RIB выбирает источник, а FIB в итоге решает, куда уйдёт пакет.

Именно на стыке этих уровней и появляются самые неприятные сюрпризы.

N.A.

Читать полностью…

netdev_budget и обработка большого потока пакетов

При большом PPS сервер может начать терять пакеты, хотя канал ещё далеко не забит.

Один из интересных параметров здесь - netdev_budget: сколько пакетов kernel может обработать за один проход NAPI.

Посмотреть текущее значение:

sysctl net.core.netdev_budget

Если входящий поток постоянно превышает этот лимит, обработка переносится на следующие проходы. В результате растут очереди и latency, а CPU может выглядеть вполне нормально.

Посмотреть, есть ли проблема именно на уровне softnet:

cat /proc/net/softnet_stat

Особенно интересны drops и количество обработанных пакетов. Если счётчики начинают быстро расти, проблема уже ближе к обработке пакетов ядром, а не к приложению.

Ещё один параметр связан со временем, которое kernel готов потратить на один такой проход:

sysctl net.core.netdev_budget_usecs

И вот здесь начинается интересный баланс: слишком маленький budget может оставить пакеты ждать следующего прохода, а слишком большой - позволить сетевой обработке надолго занять CPU и повлиять на остальные задачи.

На загруженном сервере поэтому полезно смотреть не только bandwidth, но и PPS, softirq, softnet drops и NAPI budget.

N.A.

Читать полностью…

RIB vs FIB: маршрут существует, но пакет идёт иначе

Маршрут есть в RIB, но пакет всё равно уходит не туда. Особенно неприятно это становится после изменений BGP, ECMP или policy routing.

В Linux полезно сразу смотреть не только таблицу маршрутов, а конкретное решение forwarding для нужного адреса:

ip route get <ip> from <source-ip>

Здесь уже учитываются source address и выбранная таблица маршрутизации. Результат может отличаться от того, что вы видите обычным ip route.

Для нескольких routing tables:

ip rule

Потому что маршрут в main может быть абсолютно правильным, но пакет до неё вообще не дойдёт.

А дальше начинается интересное: control plane может считать маршрут лучшим, а dataplane уже использовать другую запись.

На сетевом оборудовании это удобно проверять отдельно:

show ip route <prefix>
show ip cef <destination>

Первая команда показывает решение routing process, вторая - что реально установлено в forwarding table.

Если между ними есть расхождение, искать проблему уже нужно не в самом маршруте, а в процессе установки маршрутов в FIB, ECMP, next-hop resolution или policy routing.

Именно поэтому “маршрут есть” ещё не означает, что пакет пойдёт по этому маршруту.

N.A.

Читать полностью…

Разбор странных MTU-проблем через PMTUD

Пинг проходит, TCP-соединение устанавливается, но большие файлы не скачиваются, HTTPS периодически зависает, а часть API-запросов просто уходит в таймаут.

Во многих случаях причина оказывается не в самом MTU, а в том, что Path MTU Discovery (PMTUD) перестал работать где-то по пути.

Проверить, какой максимальный размер пакета реально проходит без фрагментации, можно так:

ping -M do -s 1472 <ip>

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

Полезно посмотреть и сам маршрут пакетов.

tracepath <ip>

В отличие от обычного traceroute, tracepath умеет определять PMTU и показывает, где он изменился.

Если используется TCP, можно проверить MSS, который стороны согласовали при установке соединения.

tcpdump -i <iface> 'tcp[tcpflags] & tcp-syn != 0'

Иногда именно здесь видно, что MSS неожиданно уменьшился или вообще не соответствует ожидаемому MTU.

Ещё один частый сценарий - ICMP Fragmentation Needed где-то фильтруется firewall’ом. В итоге PMTUD перестаёт работать, а соединение начинает “зависать” только на больших пакетах.

🔥Поэтому симптомы могут быть очень разными: открывается главная страница сайта, но не загружаются изображения, работает SSH, но зависает SCP, API отвечает на маленькие запросы и молчит на больших.

Когда проблема проявляется настолько выборочно, проверка PMTUD обычно экономит часы поиска “неисправной сети”.

N.A.

Читать полностью…

PrivateLink / VPC Peering: скрытые ограничения

Две VPC связаны, маршруты настроены, Security Groups выглядят правильно, но часть сервисов всё равно не может обмениваться трафиком.

Похожая картина возникает, когда путают возможности VPC Peering и PrivateLink - внешне они решают похожую задачу, но работают совершенно по-разному.

Если используется Peering, сначала стоит убедиться, что маршрут действительно существует.

ip route

Но даже при корректной маршрутизации может оказаться, что нужная сеть недоступна из-за отсутствия transitive routing.

Через Peering нельзя “пройти транзитом” в третью VPC - каждая связь строится напрямую.
Если используется PrivateLink, полезно проверить, к какому Endpoint вообще подключён сервис.

aws ec2 describe-vpc-endpoints

Здесь часто выясняется, что доступ есть только к опубликованному сервису, а не ко всей сети. PrivateLink вообще не предназначен для полноценного сетевого взаимодействия между VPC.

Ещё один момент - DNS.

dig <service-endpoint>

При отключённом Private DNS часть клиентов продолжает обращаться по публичному имени, даже находясь внутри VPC, и диагностика начинает выглядеть очень запутанной.

В итоге обе технологии соединяют VPC, но с разной логикой: VPC Peering даёт сетевую связность между подсетями без транзитной маршрутизации, а PrivateLink публикует конкретный сервис, вообще не открывая доступ к остальной сети.

Именно из-за этого ограничения чаще всего всплывают уже в проде, а не на этапе настройки.

N.A.

Читать полностью…

Linux bridge против OVS: где какой подход нужен

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

Linux bridge - это простой L2-коммутатор внутри ядра Linux. Его часто хватает для обычных серверов, небольших виртуализаций и контейнерных сетей.

bridge link

Можно посмотреть, какие интерфейсы подключены к bridge и как они себя ведут.

Например, обычная схема с KVM выглядит так: VM подключается через tap-интерфейс, а bridge отправляет её трафик дальше в физическую сеть.

bridge vlan show

Но когда инфраструктура становится сложнее, появляются ограничения: нет удобного управления потоками, сложнее строить динамические политики и автоматизировать изменения.

Тут появляется Open vSwitch.

ovs-vsctl show

OVS работает как программный коммутатор, но уже с ориентацией на большие виртуальные среды: OpenStack, SDN, сложные overlay-сети.

Например, можно управлять потоками напрямую через OpenFlow:

ovs-ofctl dump-flows <bridge>

И видеть не просто подключённые интерфейсы, а правила, по которым реально принимаются решения о пересылке пакетов.

Ещё один важный момент - масштабирование. Linux bridge отлично работает, пока сеть относительно статичная. OVS удобнее там, где нужно постоянно менять топологию, подключать новые сегменты и централизованно управлять политиками.

N.A.

Читать полностью…

С ДНЕМ СИСАДМИНА! 👍

По традиции в этот великий день мы смотрим классику 🎬

😎 localhost › IT-юмор

Читать полностью…

Cisco: как работает CEF и почему это важно для понимания форвардинга

До CEF Cisco форвардила пакеты через process switching: каждый пакет поднимался на CPU, который смотрел в таблицу маршрутизации и принимал решение.

Медленно и дорого по ресурсам. CEF (Cisco Express Forwarding) решает это через предварительно скомпилированные таблицы которые обновляются при изменении топологии, а не при каждом пакете.

Две ключевые структуры:

⏺FIB (Forwarding Information Base) это скомпилированная копия таблицы маршрутизации. Вместо рекурсивного lookup до следующего хопа, CEF хранит уже resolved next-hop для каждого префикса.

⏺Adjacency table хранит L2-информацию для каждого next-hop: MAC-адрес, исходящий интерфейс, заголовок фрейма который нужно подставить. При форвардинге пакета CEF берёт запись из FIB и сразу знает, какой L2-заголовок писать.

Смотрим, что в FIB:

show ip cef
show ip cef 10.0.0.0/24 detail

Смотрим adjacency table:

show adjacency
show adjacency detail
show adjacency GigabitEthernet0/0 detail

В выводе adjacency detail видно реальный L2-заголовок в hex который подставляется в каждый пакет.

Почему это важно для диагностики

Если маршрут есть в RIB (show ip route) но нет в FIB (show ip cef), пакеты не форвардируются несмотря на правильную таблицу маршрутизации. Такое бывает при проблемах с CEF или при явном отключении.

show ip cef summary
show ip cef not-cef-switched

not-cef-switched покажет трафик который всё равно уходит на process switching, это узкое место.

Проверяем включён ли CEF:

show ip interface Gi0/0 | include CEF
ip cef

N.A.

Читать полностью…

Диагностика соседей: CDP/LLDP/neighbors на Cisco, Микротик и Linux

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

Cisco

show cdp neighbors
show cdp neighbors detail
show lldp neighbors
show lldp neighbors detail

cdp neighbors показывает имя соседа, интерфейс, платформу и capability. detail добавляет IP-адрес управления, версию IOS и native VLAN. LLDP на Cisco выключен по умолчанию, включается глобально:

lldp run

Микротик

/ip neighbor print
/ip neighbor print detail

RouterOS видит соседей через CDP и LLDP одновременно без дополнительной настройки. Вывод включает IP, MAC, платформу, версию и интерфейс через который пришло объявление.

Фильтруем по интерфейсу:

/ip neighbor print where interface=ether1

Linux

lldpd не установлен по умолчанию, ставим и запускаем:

apt install lldpd
systemctl start lldpd

Смотрим соседей:

lldpcli show neighbors
lldpcli show neighbors details

Без lldpd можно поймать LLDP-фреймы напрямую через tcpdump:

tcpdump -i eth0 -v ether proto 0x88cc

Не так удобно но работает без демона.

Быстрое сравнение

На Cisco нужно явно включать LLDP, CDP работает из коробки но только с Cisco-устройствами. Микротик видит обоих без настройки. Linux требует lldpd для полноценной работы, зато отдаёт данные в JSON для автоматизации:

lldpcli -f json show neighbors

N.A.

Читать полностью…