Кейс сетевого инцидента: пакетные потери между двумя дата-центрами выросли до 10% при сохранном канале и аппаратуре; опишите возможные причины на уровнях канального, сетевого и прикладного, методы трассировки и подходы к устранению
Кратко и по делу — причины, как трассировать и как лечить для трёх уровней. Напомню: наблюдается потеря пакетов примерно \(10\%\) (\(10\%\)) между DC при рабочем канале и аппаратуре — надо последовательно исключать уровни. 1) Канальный уровень (L2 / физика) - Возможные причины - Ошибки физического слоя: деградировавшие SFP/кабель, плохие коннекторы, микробенд/загрязнение — проявляется как CRC/align/giant/frame errors. - Неправильная скорость/дуплекс, проблемы автонеготиации. - Ошибки на линке из‑за превышения BER (оптика), деградация мощности Rx/Tx. - Switch ASIC/port buffer overflow при всплесках трафика; аплинки перегружены (drop on tail). - Ошибки в настройках VLAN/port‑security, storm control, BPDU guard. - Трассировка / диагностика - Считать счётчики интерфейса: ethtool/ifconfig/ip/OS‑equivalents, show interfaces counters на коммутаторе; смотреть CRC, frame, tx/rx errors, drops. - ethtool -S / vendor‑show для статистики PHY/SFP; проверка Rx/Tx power (dBm). - Отключить/переустановить SFP, заменить кабель, swap порт для исключения железа. - Захват трафика на L2 (tcpdump/wireshark) с индикацией ошибок, смотреть corrupted frames. - Тест на локальном L2: пробросить контрольный трафик, измерить loss при низкой скорости. - Устранение - Заменить оптику/кабель, настроить правильную скорость/дуплекс, очистить коннекторы. - Увеличить/перенастроить буферирование на коммутаторах (если доступно), настроить QoS, отключить storm control временно для теста. - Если Rx power близко к пределам — согласовать с провайдером/заменить линию. 2) Сетевой уровень (L3) - Возможные причины - Перегрузка линка/маршрутизаторов → очереди и дропы, ECMP/перекосы путей → частичная потеря. - Маршрутизация/маршрутные флапы, асимметрия путей, перепутанные ACL/policer/traffic‑shaping. - MTU/fragmentation/PMTU проблемы → фрагменты теряются/ICMP blocked → видимые потери. - MPLS/L2VPN/QoS misconfiguration, policers (rate‑limit) на границе, ACLs, Netflow‑sampling приводят к drop. - ARP/NDP проблемы (массовые ARP) или ARP table overflow. - Трассировка / диагностика - traceroute / mtr между DC, сравнить пути и потери по hop. (mtr показывает где теряется). - netstat/ss/tcpdump: смотреть TCP retransmits, DUP ACKs, out-of-order; настраивать tcpdump с seq/ack. - Проверить интерфейсные counters на L3 устройствах: queue drops, taildrops, drops due to policer. - Проверка BGP/OSPF: up/down, flaps, как меняются маршруты в момент потерь. - Проверить MTU: ping с DF битом и varying size (через ip/icmp). Формула потерь: \(\text{loss\%}=\dfrac{\text{lost}}{\text{sent}}\times100\%\). - Тестирование пропускной способности: iperf3 (UDP для определения реальной loss), контролируемые стрессы. - Устранение - На этапе теста снизить нагрузку, включить/перенастроить QoS, увеличить очереди или применить RED/ECN. - Убрать/подправить policers и ACL на границах; синхронизировать конфиги на активных устройствах. - Исправить MTU/PMTU (увеличить MTU или разрешить ICMP). - Если ECMP вызывает реордер/потери — временно вынести трафик на один путь, перераспределить хэши. - Скоординироваться с провайдером/peering для проверки их очередей и состояния линка. 3) Прикладной уровень (L4–L7) - Возможные причины - Серверы/приложения перегружены (CPU, NIC driver, interrupt storm), закрывают соединения или не успевают читать сокеты. - TCP‑повторные передачи из‑за малых окон, потеря пакетов на стороне хоста (so_rcvbuff переполнение), offload (GRO/GSO/TSO) и сетевые стеки приводят к искажённой диагностике. - Балансировщики/проксирование/дедупликация на пути (WAN optimizers) режут или буферизуют пакеты, таймауты. - Неправильный keepalive/retry policy — видятся как потери. - Трассировка / диагностика - На хостах: sar/top/vmstat, netstat -s или ss -i для TCP retransmits, /proc/net/dev и ethtool counters. - Захват пакетов на сервере и на противоположном конце, сравнить timestamps и sequence numbers — определить, теряется ли пакет в сети или сбрасывается приложением. - Отключить сетевые оптимизации (offloads) и повторить тест. - Мониторинг приложений и метрик: latency, queue depth, GC pauses, thread pools. - Устранение - Увеличить буферы сокетов, исправить параметры TCP (window scaling), оптимизировать приложение, увеличить ресурсы. - Обновить драйверы NIC, прошивку, отключить проблемные offloads временно. - Поправить настройки LB/прокси, увеличить timeouts и retry‑логику. Практическая последовательность действий (чеклист) 1. Быстрая проверка физики: смотреть интерфейсные ошибки и оптические параметры (ethtool/show interface). 2. Контролируемый тест: запустить iperf3 UDP/TCP между концами, измерить loss; формула: \(\text{loss\%}=\dfrac{\text{lost}}{\text{sent}}\times100\%\). 3. traceroute/mtr для локализации хопа с потерями. 4. Захваты пакетов с timestamp на обеих сторонах (tcpdump -s0) и сравнить seq/ack/retransmits — это покажет, где теряются пакеты. 5. Проверить очереди/полиcеры/QoS и временно снизить нагрузку или направить трафик по другому пути. 6. Если ошибки на PHY — заменить SFP/кабель, проверить power; если на роутинге — исправить policer/QoS/MTU; если на хосте — проверить загрузку, offloads, tcp stack. 7. Координироваться с провайдером/peer для проверки их интерфейсов и очередей при сохранении проблемы. Коротко о приоритетах: сначала физика → counters → контролируемый поток → пакетный захват на концах → исправление конфигураций (QoS/MTU/policer) → замена железа/координация с провайдером.
1) Канальный уровень (L2 / физика)
- Возможные причины
- Ошибки физического слоя: деградировавшие SFP/кабель, плохие коннекторы, микробенд/загрязнение — проявляется как CRC/align/giant/frame errors.
- Неправильная скорость/дуплекс, проблемы автонеготиации.
- Ошибки на линке из‑за превышения BER (оптика), деградация мощности Rx/Tx.
- Switch ASIC/port buffer overflow при всплесках трафика; аплинки перегружены (drop on tail).
- Ошибки в настройках VLAN/port‑security, storm control, BPDU guard.
- Трассировка / диагностика
- Считать счётчики интерфейса: ethtool/ifconfig/ip/OS‑equivalents, show interfaces counters на коммутаторе; смотреть CRC, frame, tx/rx errors, drops.
- ethtool -S / vendor‑show для статистики PHY/SFP; проверка Rx/Tx power (dBm).
- Отключить/переустановить SFP, заменить кабель, swap порт для исключения железа.
- Захват трафика на L2 (tcpdump/wireshark) с индикацией ошибок, смотреть corrupted frames.
- Тест на локальном L2: пробросить контрольный трафик, измерить loss при низкой скорости.
- Устранение
- Заменить оптику/кабель, настроить правильную скорость/дуплекс, очистить коннекторы.
- Увеличить/перенастроить буферирование на коммутаторах (если доступно), настроить QoS, отключить storm control временно для теста.
- Если Rx power близко к пределам — согласовать с провайдером/заменить линию.
2) Сетевой уровень (L3)
- Возможные причины
- Перегрузка линка/маршрутизаторов → очереди и дропы, ECMP/перекосы путей → частичная потеря.
- Маршрутизация/маршрутные флапы, асимметрия путей, перепутанные ACL/policer/traffic‑shaping.
- MTU/fragmentation/PMTU проблемы → фрагменты теряются/ICMP blocked → видимые потери.
- MPLS/L2VPN/QoS misconfiguration, policers (rate‑limit) на границе, ACLs, Netflow‑sampling приводят к drop.
- ARP/NDP проблемы (массовые ARP) или ARP table overflow.
- Трассировка / диагностика
- traceroute / mtr между DC, сравнить пути и потери по hop. (mtr показывает где теряется).
- netstat/ss/tcpdump: смотреть TCP retransmits, DUP ACKs, out-of-order; настраивать tcpdump с seq/ack.
- Проверить интерфейсные counters на L3 устройствах: queue drops, taildrops, drops due to policer.
- Проверка BGP/OSPF: up/down, flaps, как меняются маршруты в момент потерь.
- Проверить MTU: ping с DF битом и varying size (через ip/icmp). Формула потерь: \(\text{loss\%}=\dfrac{\text{lost}}{\text{sent}}\times100\%\).
- Тестирование пропускной способности: iperf3 (UDP для определения реальной loss), контролируемые стрессы.
- Устранение
- На этапе теста снизить нагрузку, включить/перенастроить QoS, увеличить очереди или применить RED/ECN.
- Убрать/подправить policers и ACL на границах; синхронизировать конфиги на активных устройствах.
- Исправить MTU/PMTU (увеличить MTU или разрешить ICMP).
- Если ECMP вызывает реордер/потери — временно вынести трафик на один путь, перераспределить хэши.
- Скоординироваться с провайдером/peering для проверки их очередей и состояния линка.
3) Прикладной уровень (L4–L7)
- Возможные причины
- Серверы/приложения перегружены (CPU, NIC driver, interrupt storm), закрывают соединения или не успевают читать сокеты.
- TCP‑повторные передачи из‑за малых окон, потеря пакетов на стороне хоста (so_rcvbuff переполнение), offload (GRO/GSO/TSO) и сетевые стеки приводят к искажённой диагностике.
- Балансировщики/проксирование/дедупликация на пути (WAN optimizers) режут или буферизуют пакеты, таймауты.
- Неправильный keepalive/retry policy — видятся как потери.
- Трассировка / диагностика
- На хостах: sar/top/vmstat, netstat -s или ss -i для TCP retransmits, /proc/net/dev и ethtool counters.
- Захват пакетов на сервере и на противоположном конце, сравнить timestamps и sequence numbers — определить, теряется ли пакет в сети или сбрасывается приложением.
- Отключить сетевые оптимизации (offloads) и повторить тест.
- Мониторинг приложений и метрик: latency, queue depth, GC pauses, thread pools.
- Устранение
- Увеличить буферы сокетов, исправить параметры TCP (window scaling), оптимизировать приложение, увеличить ресурсы.
- Обновить драйверы NIC, прошивку, отключить проблемные offloads временно.
- Поправить настройки LB/прокси, увеличить timeouts и retry‑логику.
Практическая последовательность действий (чеклист)
1. Быстрая проверка физики: смотреть интерфейсные ошибки и оптические параметры (ethtool/show interface).
2. Контролируемый тест: запустить iperf3 UDP/TCP между концами, измерить loss; формула: \(\text{loss\%}=\dfrac{\text{lost}}{\text{sent}}\times100\%\).
3. traceroute/mtr для локализации хопа с потерями.
4. Захваты пакетов с timestamp на обеих сторонах (tcpdump -s0) и сравнить seq/ack/retransmits — это покажет, где теряются пакеты.
5. Проверить очереди/полиcеры/QoS и временно снизить нагрузку или направить трафик по другому пути.
6. Если ошибки на PHY — заменить SFP/кабель, проверить power; если на роутинге — исправить policer/QoS/MTU; если на хосте — проверить загрузку, offloads, tcp stack.
7. Координироваться с провайдером/peer для проверки их интерфейсов и очередей при сохранении проблемы.
Коротко о приоритетах: сначала физика → counters → контролируемый поток → пакетный захват на концах → исправление конфигураций (QoS/MTU/policer) → замена железа/координация с провайдером.