Процедура диагностики периодической потери пакетов между LAN A ↔ Router1 ↔ WAN ↔ Router2 ↔ LAN B.
1) Общая последовательность действий
- Собрать подтверждённые симптомы: когда, с какой частотой/длительностью, затрагивает ли все потоки или только некоторые приложения/порт/пары хостов.
- Снять базовые метрики end-to-end: потери, RTT, джиттер, retransmits. Затем локализовать сегмент (LAN A, R1, WAN, R2, LAN B).
- Использовать параллельные активные и пассивные методы (ping/mtr/iperf3 + tcpdump/ifCounters/SNMP/NetFlow).
2) Инструменты и команды (примеры)
- Простая проверка: ping, traceroute, mtr:
- На хосте A: `ping -c 100 B` (или `ping -i 0.2 -s 1400` для нагрузки/MTU), `mtr -r -c 100 B`.
- Из маршрутизаторов: `traceroute` по IP следующего хопа и до финальной цели.
- Производительность/нагрузка: `iperf3 -c B -t 60` для TCP/UDP; `iperf3 -u -b 10M` для UDP джиттера.
- Пакетный захват: `tcpdump -i eth0 host B and icmp` или `tcpdump -i eth0 -w capture.pcap` (синхронизировать время через NTP).
- Интерфейсные счётчики / физический уровень: Cisco: `show interfaces `, Juniper: `show interfaces diagnostics optics`, Linux: `ethtool -S eth0`, `ip -s link`.
- QoS/Queue/Buffer: `show queueing interface`, `tc -s qdisc` (Linux).
- Логи и метрики: syslog, SNMP, NetFlow/sFlow, RRD/Prometheus/Grafana.
- TCP/UDP анализ: Wireshark/tshark (фильтры: `tcp.analysis.retransmission`, `tcp.analysis.fast_retransmission`, `icmp`).
- Маршрутизация: `show ip route`, `show bgp summary` (BGP/OSPF flaps).
3) Какие метрики смотреть и пороговые значения (ориентиры)
- Потери: заметна если постоянная потеря > $1\%$; периодическая/пиковая — смотреть пиковые окна: $>5\%$ — критично.
- RTT: базовый RTT и вариация. Большое увеличение RTT (+$\ge 30$ ms) на волне потерь указывает на перегрузку/маршрутизацию.
- Джиттер для UDP: допустимый зависит от приложения; обычно > $30$ ms — проблема.
- Количество retransmits (TCP): резкий рост — сигнал потерь.
- Интерфейсные ошибки: CRC, frame, overruns > $0$ — физпроблема; быстро растущие счётчики указывают источник.
- Загрузка интерфейса: если использование близко к $100\%$ — очередь/дроп.
4) Как локализовать сегмент (пошагово)
- Проверка end-to-end: `mtr` или `ping` по адресам каждого хопа. Если потеря появляется между R1 и R2 — потеря на WAN.
- Послойное разделение:
- Канальный уровень: проверяйте физические ошибки на интерфейсах (CRC, FCS, collisions, late collisions, carrier). Если счётчики растут синхронно с периодами потерь — это L2.
- Сетевой уровень: смотрите маршруты, flapping, ICMP unreachable, MTU/fragmentation (потери при больших пакетах). Если loss зависит от размера пакета — MTU/fragmentation/PMTU.
- Транспортный уровень: анализ TCP (retransmits, dup acks), UDP (jitter, loss per flow). Если только TCP-сессии страдают с retransmits но неизвестно на уровне L2/L3 — возможно перегрузка/очереди (tail drop) или TCP queuing effects.
- Практика:
- На каждом хопе пингуйте следующий и предыдущий хоп (R1 -> R2, R2 -> R1). Совпадение времени потерь с увеличением error counters локализует интерфейс.
- Захват пакетов на входе и выходе интерфейса (R1-facing-WAN и R2-facing-WAN) и сравнение таймингов/seq/icmp id покажет где теряются пакеты.
- При подозрении на QoS: смотреть механизмы shaping/policing — policing может дропать входящие пакеты по превышению.
5) Примеры команд/фильтров для диагностики
- mtr: `mtr -rwzbc 100 B`
- tcpdump: `tcpdump -i eth0 host B and $icmportcpandport80$` (в KaTeX не нужно, но команды рукописно).
- tshark на retransmits: `tshark -r capture.pcap -Y "tcp.analysis.retransmission"`
- ethtool: `ethtool -S eth0` — смотреть rx_errors, tx_errors, rx_crc_err.
6) Как отличить L2 vs L3 vs L4 проблемы (кратко)
- L2: физические ошибки/CRC, линейные ошибки на интерфейсах, link flaps, duplex mismatch. Видно в интерфейсных счётчиках; потеря не зависит от IP/port.
- L3: маршрутные flaps, ACL/blackholing, MTU/ICMP fragmentation issues, asymmetry. Traceroute/mtr укажут хоп где исчезают ответы; изменение таблицы маршрутизации/OSPF/BGP будет видно в логах.
- L4: только TCP/UDP конкретных портов страдают; наблюдаются повышенные retransmits без интерфейсных ошибок; возможно из-за Active Queue Management (AQM), QoS policing, firewall state/timeouts. NetFlow/conntrack покажут сессии.
7) Временные (быстрые) и маршрутизируемые решения
- Временные / быстрые:
- Переключить traffic на резервный маршрут (if possible) — временный static route или PBR.
- Уменьшить MTU / включить TCP MSS clamping на маршрутизаторах если проблема с фрагментацией.
- Отключить/упростить QoS policing, временно увеличить буфер очереди или включить RED/CoDel (если дроп вызван policing).
- Перезапустить проблемный физический интерфейс/сбросить counters (только при плановом окне).
- Включить логирование и временно увеличить аудита для фиксации событий.
- Постоянные/маршрутизируемые:
- Настроить резервный канал / линк-агрегацию (LACP) или туннель по другому провайдеру.
- Изменить BGP: изменить local-preference/AS-path или добавить backup route; настроить BFD + fast convergence.
- Политическое маршрутизирование (PBR) для критичных потоков через стабильный путь.
- Исправить MTU/fragmentation на всех промежуточных устройствах и включить PMTU discovery безопасно.
- Настроить QoS корректно: приоритет для delay-sensitive трафика, правильное shaping вместо policing.
- Физическое исправление: заменить кабель/оптику SFP, прошивка/аппаратный ремонт.
- Для WAN: договориться с провайдером на SLAs, мониторинг и анализ (pcap/OTDR for fiber).
8) План действий с временными рамками (пример)
- 0–15 мин: собрать симптомы, запустить mtr/ping, включить мониторинг на ключевых интерфейсах.
- 15–60 мин: сделать захват tcpdump на обоих концах WAN и интерфейсах, проверить интерфейсные счётчики, iperf.
- 1–4 ч: анализ pcap и логов, тесты с изменением MTU/MSS, временное переключение трафика на резервный путь.
- >4 ч: постоянные исправления (замена физики, пересмотр QoS, изменение маршрутизации, SLA с провайдером).
9) Что фиксировать в отчёте
- Временные окна потерь (timestamp), тесты (команды и параметры), интерфейсные счётчики до/после, pcap-файлы с метками, рекомендованные изменения и риск-оценка.
Суммарно: используйте комбинацию активных тестов (ping/mtr/iperf), пассивного захвата (tcpdump/Wireshark) и системных/интерфейсных счётчиков (ethtool/show interfaces/SNMP). Локализуйте сегмент по появлению ошибок на интерфейсах, по traceroute/hop, и по характеру (все порты vs отдельные приложения). Временные меры — переключение маршрута, MSS clamp, увеличение очередей; постоянные — линк-резервирование, правки MTU/QoS, аппаратное обслуживание и изменение маршрутизации (BGP/PBR).