Почему 10G линк работает на 1G и как это поймать

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

Смотрим на какой скорости реально работает интерфейс:

ethtool eth0 | grep -E "Speed|Duplex|Auto"
ip -s link show eth0

Если Speed: 1000Mb/s на 10G интерфейсе, autonegotiation не договорился или принудительно выставлена неверная скорость.

Проверяем ошибки на интерфейсе:

ethtool -S eth0 | grep -E "error|drop|miss|fail"

Много ошибок на физическом уровне говорят о проблеме с кабелем или SFP.

Смотрим что видит интерфейс с другой стороны через LLDP:

lldpctl eth0

Покажет что анонсирует сосед: скорость, duplex, модель устройства.

Принудительно выставляем скорость если autonegotiation не работает:

ethtool -s eth0 speed 10000 duplex full autoneg off

Проверяем SFP модуль: температуру, мощность сигнала, vendor:

ethtool -m eth0

Если rx_power или tx_power сильно ниже нормы для данного типа модуля, проблема в оптике или трансивере.

⚡️ DAC-кабели (прямое медное подключение) иногда не работают с чужими SFP-модулями даже если физически подходят. Вендор-лок на уровне прошивки коммутатора: Cisco по умолчанию не принимает non-Cisco трансиверы без service unsupported-transceiver.

N.A.

Многоуровневая фильтрация трафика с iptables и nftables

iptables и nftables — два подхода к фильтрации трафика в Linux.

⏺iptables — классика, знакомая большинству системных администраторов, работает через цепочки INPUT, OUTPUT, FORWARD.

⏺nftables — современный инструмент, который объединяет IPv4, IPv6 и L2 фильтрацию в единой структуре, с более компактным синтаксисом и улучшенной производительностью.

С помощью них можно: ограничивать доступ по IP, блокировать конкретные порты, фильтровать трафик между VLAN, логировать подозрительные соединения и создавать сложные правила с условием источника, назначения и интерфейса.

Создадим простое ограничение трафика через nftables:

sudo nft add table inet filter
sudo nft add chain inet filter input { type filter hook input priority 0; }
sudo nft add rule inet filter input ip saddr 192.168.1.0/24 accept
sudo nft add rule inet filter input tcp dport 22 accept
sudo nft add rule inet filter input drop

Логирование SSH попыток:

sudo nft add rule inet filter input tcp dport 22 log prefix "SSH DROP: " counter drop

Проверка правил:

sudo nft list ruleset

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.

Почему сессия рвётся ровно через N минут

Если сессия рвётся не случайно а по таймеру, где-то на пути есть устройство которое принудительно закрывает idle или долгие соединения. Регулярность это ключ к диагностике.

Первым делом замеряем точное время разрыва в нескольких сессиях. Если цифра одинаковая или кратная, это таймаут а не флуктуация сети.

⏺Где живут таймауты

NAT на роутере или файерволе закрывает записи в таблице трансляций после периода бездействия. Типичные значения: 30 минут на Cisco ASA, 5 минут для UDP на Linux conntrack. TCP-сессия без трафика выглядит для NAT как мёртвая.

Load balancer держит сессии в таблице и закрывает их по таймауту. nginx по умолчанию 60 секунд, AWS ALB 60 секунд, HAProxy 50 секунд. Бэкенд считает сессию живой, балансировщик уже нет.

Файервол с stateful инспекцией делает то же самое что NAT, только без трансляции адресов.

⏺Смотрим conntrack таймауты на Linux:

sysctl net.netfilter.nf_conntrack_tcp_timeout_established
sysctl net.netfilter.nf_conntrack_udp_timeout
cat /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_close_wait

Смотрим таймауты nginx:

grep -E "timeout|keepalive" /etc/nginx/nginx.conf /etc/nginx/conf.d/*.conf

⏺Как локализовать где именно рвётся

Запускаем tcpdump на обоих концах одновременно и смотрим кто отправляет FIN или RST:

tcpdump -i eth0 -w /tmp/capture.pcap host <IP> and port <PORT>

Если RST приходит не от собеседника а от промежуточного узла, в поле TTL будет другое значение чем у остального трафика от этого хоста.

⏺Быстрый тест

Держим соединение живым искусственным трафиком и смотрим изменилось ли время разрыва:

ssh -o ServerAliveInterval=30 user@host

Если с keepalive сессия живёт дольше, таймаут на idle трафик подтверждён.

N.A

Почему 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

ICMP типы, которые нельзя блокировать

Блокировать весь ICMP это распространённая ошибка которую делают из соображений безопасности.

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

⏺Type 3: Destination Unreachable

Самый важный. Код 4 (Fragmentation Needed) используется в Path MTU Discovery: промежуточный узел сообщает отправителю что пакет слишком большой и нужно уменьшить размер. Без него крупные пакеты молча дропаются, мелкие проходят. Симптом: SSH работает, scp зависает, большие страницы не грузятся.

iptables -A INPUT -p icmp --icmp-type 3 -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type 3 -j ACCEPT

⏺Type 11: Time Exceeded

TTL закончился, пакет дропнут. Без этого типа traceroute не работает совсем: не получает ответов от промежуточных хопов и не строит путь. Не критично для трафика, критично для диагностики.

⏺Type 12: Parameter Problem

Сообщает об ошибке в заголовке IP-пакета. Без него отправитель не узнает что пакет был отброшен из-за некорректного заголовка.

⏺Что можно блокировать без последствий

Type 8 (Echo Request) и Type 0 (Echo Reply) это ping. Блокировка ломает только ping, на реальный трафик не влияет. Type 9 и 10 (Router Advertisement/Solicitation) в большинстве сетей не нужны.

Минимальный набор который должен проходить:

iptables -A INPUT -p icmp --icmp-type 3 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 11 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 12 -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type 3 -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type 11 -j ACCEPT

N.A

Скрипт массовой проверки SSL-сертификатов на пуле серверов

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

Проверка одного сертификата вручную:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate



-servername важен если на сервере несколько сертификатов через SNI, без него можешь получить не тот сертификат.

⏺Скрипт для пула серверов

#!/bin/bash
THRESHOLD_DAYS=14
BOT_TOKEN="ваш_токен"
CHAT_ID="ваш_chat_id"

while read -r host port; do
  expiry=$(echo | timeout 5 openssl s_client -connect "${host}:${port}" -servername "$host" 2>/dev/null \
    | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)

  if [ -z "$expiry" ]; then
    echo "$host:$port -> не удалось получить сертификат"
    continue
  fi

  expiry_epoch=$(date -d "$expiry" +%s)
  now_epoch=$(date +%s)
  days_left=$(( (expiry_epoch - now_epoch) / 86400 ))

  echo "$host:$port -> $days_left дней до истечения"

  if [ "$days_left" -lt "$THRESHOLD_DAYS" ]; then
    curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
      -d chat_id="${CHAT_ID}" \
      -d text="⚠️ SSL на ${host}:${port} истекает через ${days_left} дней"
  fi
done < hosts.txt



hosts.txt построчно:

example.com 443
api.example.com 443
mail.example.com 465



В cron раз в сутки:

0 9 * * * /usr/local/bin/check_ssl_pool.sh >> /var/log/ssl_check.log



⚡️timeout 5 в команде критичен. Если хост недоступен или порт фильтруется, openssl s_client может висеть бесконечно и весь скрипт встанет на первом проблемном сервере, не дойдя до остальных.

N.A

Как ECMP-хеш ломает диагностику, если не учитывать его

Запускаешь traceroute, видишь путь через линк А. Через минуту повторяешь, путь идёт через линк Б. Сеть не менялась, маршрутизация стабильная, просто ECMP распределяет пакеты по нескольким равностоимым путям, и хеш для каждого пакета может оказаться разным.

Хеш считается из набора полей: обычно src/dst IP, иногда плюс src/dst порт и протокол. Если поля совпадают, все пакеты одного потока стабильно идут одним путём. Если поля меняются, путь скачет.

Почему diagnostика ломается именно здесь

traceroute на каждом хопе увеличивает TTL и шлёт новый пакет. Каждый такой пакет, в зависимости от реализации, может менять src-порт.

Хеш каждый раз получается другой, и каждый “хоп” в выводе мог физически прийти с разного пути. Результат: рисуется путь который никогда не существовал как единый маршрут.

Проверяем влияет ли порт на хеш, фиксируя его явно:

traceroute -p 33434 host.com
traceroute -p 33434 host.com



Если оба запуска с одним и тем же src-портом дают одинаковый путь, а с разными портами разный, ECMP-хеш по портам подтверждён.

mtr ведёт себя стабильнее в рамках одного запуска, потому что использует фиксированный набор полей все время:

mtr --report -P icmp host.com



Как диагностировать честно при наличии ECMP

Используем dublin-traceroute или paris-traceroute, которые специально держат хеш-поля константными чтобы видеть один реальный путь, а не случайную выборку из нескольких:

paris-traceroute host.com



Запускаем несколько traceroute с разными зафиксированными портами, чтобы явно увидеть все альтернативные пути, а не один случайный:

for port in 33434 33450 33470; do
  traceroute -p $port host.com
done



⚡️ Если в выводе обычного traceroute путь выглядит нелогично или хопы “скачут”, не спеши искать проблему в сети. Сначала проверь не ECMP ли это просто рисует разные срезы параллельных путей как один маршрут.

N.A

Аудит мёртвых VLAN, которые никто не использует, но они висят в конфиге

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

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

Смотрим что вообще создано

show vlan brief



Список всех VLAN с именами и портами которые к ним привязаны.

Ищем VLAN без активных портов

Если у VLAN нет ни одного порта в статусе up, скорее всего он мёртвый:

show interfaces status | include connected
show vlan brief | exclude Gi



Вторая команда покажет VLAN у которых вообще нет привязанных интерфейсов.

Проверяем реальный трафик, не только наличие порта

Порт может быть подключён физически, но трафика годами нет:

show interfaces Gi0/5 | include packets



Если счётчики не растут при повторных проверках с интервалом, порт не используется активно.

Смотрим MAC-таблицу по VLAN

Если в VLAN не учится ни один MAC за продолжительное время, там никого нет:

show mac address-table vlan 50



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

Сверяем с тем что реально проходит на trunk-портах

show interfaces trunk



Покажет какие VLAN разрешены на транке и какие из них активны (Vlans allowed and active in management domain). Если VLAN разрешён, но не активен, на этом сегменте трафика нет.

Перед удалением

Переводим в shutdown а не удаляем сразу, чтобы был путь назад если что-то всплывёт:

interface vlan 50
 shutdown



Через несколько недель без жалоб удаляем окончательно:

no vlan 50



⚡️Удалять VLAN из running-config без снятия его с интерфейсов сначала может привести к тому что порты останутся привязаны к несуществующему VLAN и перестанут передавать трафик вообще. Сначала убираем из интерфейсов, потом удаляем сам VLAN.

N.A

Proxy Protocol в проде: почему он ломает часть legacy цепочек

Proxy Protocol часто включают “для удобства” - чтобы backend видел реальный IP клиента за балансером.

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

Проверяем, что реально приходит на backend:

tcpdump -A -s 0 port 443



И вместо TLS ClientHello или HTTP запроса можно увидеть:

PROXY TCP4 10.0.0.1 10.0.0.2 52344 443



Для современного стека это “метаданные”. Для старого TLS/HTTP парсера - это просто мусор в начале потока.
Смотрим где включён Proxy Protocol в балансировщиках:

nginx -T | grep proxy_protocol
cat /etc/haproxy/haproxy.cfg | grep send-proxy

Классическая ошибка в проде - несогласованность цепочки:

• LB1 добавляет PROXY header
• LB2 не настроен на его чтение
• backend ожидает чистый TLS/HTTP поток

В итоге соединение выглядит как random reset или silent drop без логики.
Проверяем TLS отдельно, чтобы исключить “ложную сеть”:

openssl s_client -connect backend:443



Если handshake не начинается или обрывается на старте - почти всегда причина не в TLS, а в лишних байтах перед ClientHello.

⚡️В реальности ломается не TCP и не TLS. Ломается предположение, что первый байт соединения принадлежит приложению.
Proxy Protocol добавляет слой “вне протокола”, и старые системы просто не умеют его игнорировать.

N.A

Почему “сеть живая”, но TLS handshake нестабилен

MTU + congestion + firewall inspection

TLS handshake часто выглядит как проблема сети, хотя линк и ICMP полностью стабильны.

Пинги идут, маршруты есть, TCP соединения иногда устанавливаются, но HTTPS периодически зависает на этапе ClientHello или ServerHello.

Сначала важно понять, что TLS чувствителен к размеру первых пакетов и времени доставки.

Handshake не про throughput, а про стабильную доставку небольших, но критичных пакетов в строгом порядке.

Проверяем базовую доступность TCP:

ss -ant dst :443



Если соединения есть, но handshake “плавает” - смотрим дальше.

Проверяем MTU путь, потому что TLS handshake часто выходит за MSS после добавления заголовков:

ping -M do -s 1472 1.1.1.1



Если требуется сильно уменьшать payload до стабильного ответа - есть фрагментация или blackhole MTU в пути (часто GRE/IPsec/VPN).
Смотрим реальный MSS на соединении:

ss -ti | grep -i mss



Если MSS выше реального MTU пути - TCP начинает дробить handshake, и любые потери превращаются в задержки вместо явных ошибок.
Далее фактор congestion и очередей. Если сеть не теряет пакеты, но перегружена по очередям:

cat /proc/net/softnet_stat



Рост dropped или time_squeeze означает, что handshake пакеты могут задерживаться внутри kernel, не доходя до NIC вовремя.
Отдельный слой - firewall inspection (stateful или DPI). Он может:

⏺задерживать первый SYN/SYN-ACK
⏺буферизовать TLS ClientHello
⏺делать reassembly потоков

Проверяем netfilter counters:

nft list ruleset
iptables -L -v -n

⚡️В реальности нестабильный TLS почти никогда не про “сломанный TLS”.
Это комбинация трёх эффектов:

• MTU ломает целостность handshake пакетов
• congestion вызывает задержки внутри kernel
• firewall inspection добавляет непредсказуемую буферизацию

И на уровне симптомов это выглядит как случайные зависания HTTPS при полностью “живой сети”.

N.A

Сегментация L2-сети с Private VLAN

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

Как работает Private VLAN

Private VLAN (PVLAN) — это расширение обычного VLAN, которое позволяет разделять трафик на уровне канального слоя:

⏺Promiscuous port — порт, который может общаться со всеми. Обычно это шлюз или маршрутизатор.
⏺Isolated port — порт, который может общаться только с promiscuous портом, но не с другими isolated портами.
⏺Community port — порты внутри одной группы могут общаться друг с другом и с promiscuous портом, но не с портами другой community.

Так можно изолировать клиентов, оставляя при этом доступ к общим ресурсам.

Практикуемся на Linux с bridge и VLAN

Создадим bridge с PVLAN-подобной логикой:

# Создаём главный bridge
ip link add name br0 type bridge
ip link set br0 up

# Создаём VLAN-подсети
ip link add link br0 name br0.10 type vlan id 10
ip link add link br0 name br0.20 type vlan id 20
ip link set br0.10 up
ip link set br0.20 up

# Настраиваем iptables, чтобы isolated VLAN не видел друг друга
iptables -I FORWARD -i br0.10 -o br0.10 -j DROP
iptables -I FORWARD -i br0.20 -o br0.20 -j DROP

# Разрешаем доступ к шлюзу (eth0)
iptables -A FORWARD -i br0.10 -o eth0 -j ACCEPT
iptables -A FORWARD -i br0.20 -o eth0 -j ACCEPT

Теперь устройства внутри VLAN 10 и VLAN 20 изолированы друг от друга, но могут использовать интернет через общий шлюз.

N.A

📂Как правильно документировать сеть, чтобы не потерять конфиги

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

1️⃣Сбор данных
Фиксируем все устройства, IP, VLAN, интерфейсы и протоколы маршрутизации.
Команды:

ip addr show          # список интерфейсов
ip route show         # таблица маршрутов
vtysh -c "show running-config"  # конфиги роутеров
show vlan brief       # VLAN на коммутаторах

2️⃣Структурирование: Систематизируем данные: топология, IP-план, протоколы, ACL/Firewall.
Пример таблицы IP:

Устройство | Интерфейс | IP           | VLAN | Примечание
-----------|-----------|--------------|------|------------
r1         | eth0      | 10.0.1.1/24  | 10   | WAN
sw1        | vlan10    | 10.0.1.2/24  | 10   | серверная зона
sw2        | vlan20    | 10.0.2.1/24  | 20   | офисная зона
server1    | eth1      | 10.0.1.10/24 | 10   | база данных
server2    | eth1      | 10.0.1.11/24 | 10   | веб-сервер

3️⃣Version control: Сохраняем конфиги в Git. Каждый коммит с комментарием: что и зачем изменилось.

git init
git add configs/
git commit -m "Добавлен новый VLAN 20 на sw2"

4️⃣Визуализация топологии: Diagram-as-code (Mermaid/Graphviz) или инструменты типа NetBox/Draw.io.
Пример Mermaid:

graph TD
    R1 --> SW1
    SW1 --> Server1
    SW1 --> Server2

5️⃣Автоматизация и backup: Скрипты для снятия конфигов и их сохранения в репозиторий или на NAS. Проверка актуальности backup. ✅

Полезные команды для контроля

git log --oneline --graph   # история изменений
diff old_config new_config  # что изменилось
ping 10.0.1.2              # проверить доступность после изменений

N.A.

Почему UDP checksum опционален в IPv4, но обязателен в IPv6

В IPv4 у UDP-заголовка есть поле checksum, но стандарт позволяет выставить его в ноль, что означает “checksum не вычислен”.

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

В IPv6 от этого отказались. Checksum в UDP обязателен, нулевое значение считается ошибкой и пакет дропается.

⏺Причина: IPv6 убрал checksum из собственного заголовка (в IPv4 он был), значит если UDP тоже не считает контрольную сумму, целостность данных вообще никем не проверяется на сетевом уровне.

Проверяем, как это выглядит в трафике:

tcpdump -i eth0 -v udp



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

Смотрим включён ли UDP checksum offload на интерфейсе:

ethtool -k eth0 | grep checksum



Где это реально создаёт проблемы

Туннели. VXLAN и некоторые GRE-реализации инкапсулируют пакеты с нулевым UDP checksum внутри IPv4. При переходе в IPv6-транспорт это невалидно и требует пересчёта или явного включения checksum на туннельном интерфейсе:

ip link set vxlan0 type vxlan udpcsum



N.A.

Как найти петлю в L2 без доступа к коммутаторам

Петля в L2 без STP это широковещательный шторм: broadcast-фреймы начинают множиться, загружают все порты, сеть деградирует до полной недоступности за секунды.

Диагностировать нужно быстро, и часто без доступа к коммутаторам.
Первый признак: резкий рост broadcast-трафика на интерфейсе.

Смотрим счётчики прямо сейчас:

watch -n 1 'ip -s link show eth0 | grep -A2 RX'



Если счётчик пакетов растёт на тысячи в секунду при минимальной нагрузке, петля активна.
Ловим broadcast-шторм живым трафиком:

tcpdump -i eth0 -n broadcast



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

Смотрим источник шторма по MAC:

tcpdump -i eth0 -n -e broadcast | awk '{print $2}' | sort | uniq -c | sort -rn | head -10



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

tcpdump -i eth0 -w /tmp/capture.pcap
tcpdump -r /tmp/capture.pcap -n | awk '{print $NF}' | sort | uniq -c | sort -rn | head



Локализация физически

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

watch -n 1 'ip -s link show eth0 | grep -A1 RX'



⚡️Если STP включён но петля всё равно есть, скорее всего где-то BPDU Guard сработал и порт ушёл в err-disabled, но петля успела образоваться через другой путь. Проверяй err-disabled порты если есть хоть какой-то доступ к одному коммутатору: show interfaces status err-disabled.

N.A.

Коммутатор начал флапать порты: где искать

Флап это когда порт циклически уходит в down и возвращается в up. Для STP каждый флап это topology change, пересчёт, временная потеря связности.

На загруженной сети даже один флапающий порт создаёт заметные проблемы.

Смотрим счётчики переходов состояния на всех портах:

show interfaces | include line protocol|changes
show interfaces counters errors



Порт с аномально высоким Link-state change count это он.

На Linux если коммутатор не Cisco:

ip monitor link
journalctl -k | grep "NIC Link"



ip monitor link показывает события в реальном времени, journalctl покажет историю флапов с таймстампами.

Физические причины

Самые частые: плохой кабель, разболтанный коннектор, неисправный SFP. Проверяем уровень сигнала на оптике:

show interfaces Gi0/1 transceiver
ethtool -m eth0



Смотрим на rx_power, если значение плавает или ниже допустимого порога для данного типа модуля, проблема в оптике или трансивере.

Программные причины

Если физика чистая, смотрим на STP и BPDU:

show spanning-tree detail | include changes
debug spanning-tree events



Частые topology change от конкретного порта могут быть вызваны устройством которое периодически уходит в сон, например IP-телефон или ноутбук.
Проверяем autonegotiation, несогласованный duplex тоже вызывает флапы:

show interfaces Gi0/1 | include duplex,speed



⚡️Если флап идёт строго по расписанию, например каждые несколько часов, смотри на spanning-tree hello timer и max-age. Иногда это не физика, а STP решает что сосед умер из-за потери BPDU на перегруженном канале.

N.A.