Network Admin

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.

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.

Один 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.

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.

Как поймать внезапный 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.

Разбор странных 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.

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.

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.

Классика 🤵‍♂️ 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.

Основные причины ошибки «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 › IT-юмор

С днём системного администратора! 🏆 Пусть серверы не падают, бэкапы восстанавливаются, мониторинг молчит, а пользователи хотя бы иногда пробуют перезагрузить компьютер до обращения в поддержку. Желаю стабильного аптайма, спокойных дежурств, крепких нервов и достойной зарплаты. За localhost! 🍻🍷 N.A.

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.

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.

Диагностика соседей: 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.

Скрипт мониторинга TCP retransmit rate через /proc/net/snmp Ретрансмиты это первый признак проблем на канале: потери, перегрузка, несогласованный duplex. /proc/net/snmp даёт реальную картину по TCP без внешних инструментов. Смотрим нужные счётчики: awk '/^Tcp:/ {nr++; if(nr==1) print; if(nr==2) print}' /proc/net/snmp Первая строка заголовки, вторая значения. Нас интересуют RetransSegs и OutSegs. Скрипт с дельтой и алертом: #!/bin/bash THRESHOLD=1 LOG="/var/log/tcp_retransmit.log" BOT_TOKEN="ваш_токен" CHAT_ID="ваш_chat_id" get_stats() { awk '/^Tcp:/ {nr++; if(nr==2) print $13, $11}' /proc/net/snmp } read -r r1 o1 <<< "$(get_stats)" sleep 60 read -r r2 o2 <<< "$(get_stats)" dr=$(( r2 - r1 )) do_=$(( o2 - o1 )) [ "$do_" -eq 0 ] && exit 0 rate=$(awk "BEGIN {printf \"%.2f\", $dr/$do_*100}") echo "$(date '+%Y-%m-%d %H:%M:%S') ${rate}% (${dr}/${do_})" >> "$LOG" awk -v r="$rate" -v t="$THRESHOLD" 'BEGIN { if (r+0 > t+0) exit 0; exit 1 }' && curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \ -d chat_id="${CHAT_ID}" \ -d text="⚠️ TCP retransmit ${rate}% на $(hostname)" Если rate высокий, смотрим какие соединения виноваты: ss -tin | grep -v "retrans:0" | grep retrans В cron каждые 5 минут: */5 * * * * /usr/local/bin/tcp_retransmit.sh ⚡️ Позиции $13 и $11 могут отличаться между версиями ядра. Проверяй на своей системе: первая строка /proc/net/snmp с Tcp: это заголовки, считай колонки до RetransSegs и OutSegs вручную. N.A.

Аудит активных multicast-групп через /proc/net/igmp Кто и на какие multicast-группы подписан в системе, обычно выясняют через внешние утилиты. Но всё это есть прямо в ядре без ничего лишнего. Смотрим что есть в /proc/net/igmp: cat /proc/net/igmp Вывод не самый читаемый: адреса групп в hex little-endian. Парсим в человеческий вид: awk 'NR>1 && $1 !~ /^[0-9]/ {iface=$1} NR>1 && $1 ~ /^[0-9]/ { hex=$2 printf "%s: %d.%d.%d.%d\n", iface, strtonum("0x"substr(hex,7,2)), strtonum("0x"substr(hex,5,2)), strtonum("0x"substr(hex,3,2)), strtonum("0x"substr(hex,1,2)) }' /proc/net/igmp Показывает интерфейс и группу в читаемом виде. Скрипт мониторинга с алертом на новые группы #!/bin/bash SNAPSHOT="/var/lib/igmp_check/groups.snap" LOG="/var/log/igmp_changes.log" BOT_TOKEN="ваш_токен" CHAT_ID="ваш_chat_id" mkdir -p "$(dirname "$SNAPSHOT")" parse_igmp() { awk 'NR>1 && $1 !~ /^[0-9]/ {iface=$1} NR>1 && $1 ~ /^[0-9]/ { hex=$2 printf "%s %d.%d.%d.%d\n", iface, strtonum("0x"substr(hex,7,2)), strtonum("0x"substr(hex,5,2)), strtonum("0x"substr(hex,3,2)), strtonum("0x"substr(hex,1,2)) }' /proc/net/igmp | sort } CURRENT=$(parse_igmp) if [ ! -f "$SNAPSHOT" ]; then echo "$CURRENT" > "$SNAPSHOT" echo "Baseline saved" exit 0 fi PREVIOUS=$(cat "$SNAPSHOT") NEW=$(comm -13 <(echo "$PREVIOUS") <(echo "$CURRENT")) GONE=$(comm -23 <(echo "$PREVIOUS") <(echo "$CURRENT")) if [ -n "$NEW" ] || [ -n "$GONE" ]; then msg="⚠️ IGMP изменения на $(hostname)" [ -n "$NEW" ] && msg="$msg\nНовые группы: $NEW" [ -n "$GONE" ] && msg="$msg\nУшли группы: $GONE" echo "$(date) $msg" >> "$LOG" curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \ -d chat_id="${CHAT_ID}" \ -d text="$msg" &>/dev/null echo "$CURRENT" > "$SNAPSHOT" fi В cron каждые 5 минут: */5 * * * * /usr/local/bin/igmp_monitor.sh N.A.

Почему OSPF соседство не поднимается Интерфейсы в состоянии up/up, IP-адреса корректные, но соседи в OSPF не переходят в Full. Чаще всего причина в несовпадении параметров: area ID, network type, hello/dead timers, MTU или authentication. Иногда интерфейс попадает под passive-interface, либо multicast 224.0.0.5 блокируется ACL’ом. Также соседство не установится, если Router ID дублируется в домене или если одна сторона работает в stub/NSSA, а другая - нет. 🤖Что проверить на Cisco show ip ospf neighbor show ip ospf interface Gi0/1 show ip ospf interface Gi0/1 | include MTU show ip protocols show running-config | section router ospf show ip ospf database show access-lists N.A.

Проверяем, что все next-hop в таблице маршрутизации живые Маршрут в таблице есть, интерфейс поднят, но next-hop давно не отвечает. Такое бывает после замены оборудования, при проблемах с upstream или когда шлюз провайдера ушёл без уведомления. Маршрутизатор продолжает слать трафик в никуда. Собираем все уникальные next-hop из таблицы маршрутизации: ip route show | awk '/via/ {print $3}' | sort -u Скрипт массового ARP-опроса next-hop #!/bin/bash LOG="/var/log/nexthop_check.log" BOT_TOKEN="ваш_токен" CHAT_ID="ваш_chat_id" echo "=== Next-hop check $(date) ===" >> "$LOG" ip route show | awk '/via/ {print $3, $5}' | sort -u \ | while read -r nexthop iface; do [ -z "$iface" ] && iface=$(ip route get "$nexthop" 2>/dev/null | awk '{print $3}' | head -1) [ -z "$iface" ] && continue result=$(arping -c 2 -W 1 -I "$iface" "$nexthop" 2>/dev/null \ | grep -c "bytes from") if [ "$result" -eq 0 ]; then msg="⚠️ Next-hop $nexthop ($iface) не отвечает на ARP на $(hostname)" echo "$(date '+%Y-%m-%d %H:%M:%S') FAIL: $nexthop via $iface" >> "$LOG" curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \ -d chat_id="${CHAT_ID}" \ -d text="$msg" &>/dev/null else echo "$(date '+%Y-%m-%d %H:%M:%S') OK: $nexthop via $iface" >> "$LOG" fi done Для IPv6 next-hop отдельно через ndisc6: ip -6 route show | awk '/via/ {print $3, $5}' | sort -u \ | while read -r nexthop iface; do result=$(ndisc6 -q -r 2 "$nexthop" "$iface" 2>/dev/null | grep -c "from") [ "$result" -eq 0 ] && echo "FAIL IPv6: $nexthop via $iface" done В cron каждые 5 минут: */5 * * * * /usr/local/bin/check_nexthop.sh Смотрим историю недоступных next-hop: grep "FAIL" /var/log/nexthop_check.log | tail -20 N.A.