Отказы сети редко начинаются с «падения линка» — чаще с деградации на одном из слоёв

Отказы сети редко начинаются с «падения линка» — чаще с деградации на одном из слоёв

Сетевой инцидент обычно выглядит как один симптом, но причина лежит глубже. На практике картина складывается из трёх зон: физика, L2/L3 и контрольные плоскости. Если смотреть только на недоступность сервиса, легко перепутать обрыв кабеля, петлю в коммутаторе и перегрузку маршрутизации.

Анализ показал, что полезно идти по цепочке:
— физический уровень: CRC, flaps, ошибки оптики, нестабильный порт;
— канальный уровень: STP-переконфигурации, MAC-flap, broadcast-storm;
— сетевой уровень: потеря соседства, асимметрия маршрута, переполнение таблиц;
— управляющий слой: CPU на сетевом устройстве, очереди, таймауты протоколов.

Дальше проверяется не «где болит», а «что сломало причинность». Если выросла задержка и одновременно пошли retransmit и packet loss, ищите перегрузку или микропотери. Если сервис недоступен, а линк живой, смотрите ACL, MTU, ECMP и состояние соседних узлов. Если отказ плавающий, важнее корреляция по времени, чем единичный алерт. Рекомендуется обращать внимание на метрику jitter: она часто раньше указывает на проблему, чем полный разрыв.

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