Подход разбить на этапы: сбор данных → локализация границы проблемы → воспроизведение/измерение → анализ контрольной/пользовательской плоскостей → корректирующие изменения → валидация. Ниже — методично и по пунктам.
1) Сбор информации (инструменты)
- Активные: ping (с опцией размера/DF), traceroute, mtr (показывает потери/RTT по хопам), iperf/iperf3 (нагрузочные тесты TCP/UDP).
- Пассивные: tcpdump/wireshark (предварительно на CE/PE/edge), NetFlow/sFlow/IPFIX (анализ потоков), SNMP (Graphite/Prometheus/Grafana для графиков интерфейсов, CPU, память), провайдерские метрики MPLS (LSP ping/traceroute).
- CLI‑команды: интерфейсные счётчики (ifInErrors/ifOutErrors/ifInDiscards/ifOutDiscards), BGP (show bgp summary/neighbor/received-routes), OSPF (show ip ospf neighbor, LSDB), MPLS/LDP/RSPV 状態 (show mpls ldp neighbors, show mpls forwarding-table, ping mpls lsp).
- Контроль плоскости: syslog, process CPU, BGP/OSPF flap logs.
- Утилиты для проверки MTU/MSS (ping -M do -s, tcpdump для MSS в SYN).
2) Какие метрики собирать и на что смотреть
- Потери пакетов: вычислять как $\text{loss\%}=\frac{\text{sent}-\text{received}}{\text{sent}}\times 100\%$. Порог тревоги обычно > $1\%$ для TCP‑приложений; критично > $5\%$.
- RTT и джиттер: средний/95‑процентиль/максимум; тревожные значения RTT > $100$ ms, джиттер > $30$ ms.
- CPU/Memory на CE/PE/PE‑router: spikes совпадающие с потерями.
- Интерфейсные ошибки: CRC, frame, collisions, carrier — признак проблемы физического уровня/дуплекса.
- Дропы очередей: ifOutDiscards, tail drops, WRED drops; конвертировать в пакеты/с.
- Политики QoS: policer drops (policed‑out), shaping queue drops, buffer usage, queue depth and max.
- BGP/OSPF стабильность: количество флапов, частота SPF, BGP RIB churn, BGP prefix churn.
- MPLS LSP состояние и traffic engineering: LSP transient failures, LDP bindings.
- TCP‑повторные передачи (wireshark) и ECN/DSCP поведения.
3) Как локализовать (пошагово)
- Определить «границу» появления потерь: запустить mtr изнутри к хостам дальше в сторону провайдера и обратно; посмотреть где начинается loss/рост RTT.
- Если потеря на одном интерфейсе — проверить интерфейс и физический уровень (дуплекс, errors). Если на границе CE↔PE — сравнить counters на обеих сторонах.
- Проверить MTU: отправить ping с DF и увеличивающимся размером, и смотреть где начинаются ICMP Fragmentation Needed; или смотреть TCP MSS/трейс в tcpdump.
- Проверить совпадение QoS‑настроек и DSCP→EXP маппинга на CE и на стороне провайдера — возможна агрессивная полисинга провайдером.
- Проверить, не происходит ли полисинг дважды (на вашей стороне и у провайдера) → microbursts будут обрубаться.
- Искать корреляцию: падения BGP/OSPF соседств во времени утрат; spikes CPU; пиковые значения на интерфейсе.
- Если подозрение на MPLS TE — LSP ping/traceroute и проверка RSVP/LDP логов.
- Использовать iperf UDP с фиксированным rate чтобы поймать порог, при котором происходят потери — полезно при потере при «burst».
4) Типичные причины и как их проверить
- MTU/MSS mismatch → проверка ping DF, tcpdump (SYN MSS), установить MSS‑clamp на CE.
- Полисинг у провайдера при превышении профиля → проверить NetFlow, провайдерские counters, DSCP/EXP mapping.
- Bursty traffic + недостаточное шейпирование на CE → измерить microburst через ifInOctets/ifOutOctets/short‑interval graphs; применить shaper.
- QoS mismatch (DSCP→EXP) → проверить и согласовать классы.
- Интерфейсные ошибки / duplex mismatch → show interface counters.
- Маршрутизационные флапы (BGP/OSPF) → show bgp neighbors, show ip ospf database; включить BFD для быстрого обнаружения.
- CPU‑overload (control/data plane) → процесс‑пики и drops на control plane.
5) Набор практических изменений (конфигурация и QoS)
- Немедленно:
- Включить и собрать детальные счётчики и логирование (NetFlow, SNMP с коротким polling, tcpdump по триггеру).
- Включить BFD для BGP/OSPF соседей (ускоренная детекция и стабильность маршрутов).
- На CE сделать MSS‑clamp для VPN/edge интерфейсов (примерно $\text{MSS}=1400$ или подогнать под вашу MTU).
- QoS и shaping:
- Внедрить иерархическую модель QoS: классы (real‑time, interactive, bulk), priority queue для control/real‑time, гарантированные классы для interactive.
- На границе перед отправкой провайдеру — применять shaper (token bucket) вместо агрессивного policer, чтобы сгладить microbursts.
- Согласовать DSCP→EXP и EXP→PHB с провайдером; если провайдер приводит к полисингу, уменьшить DSCP тонкие маркеры или дать «safe» DSCP.
- Включить WRED (или настроить thresholds) вместо жесткого tail‑drop для избежания synchronized drops.
- Настроить QoS‑политику для защиты control‑plane (control‑plane policing / priority queues).
- Маршрутизация:
- Убедиться, что BGP/OSPF redistrib/metrics корректны — убрать флапирующие маршруты, уменьшить churn (опции: route dampening осторожно).
- При необходимости изменить local‑pref/MED/OSPF cost чтобы перераспределить трафик на менее загруженные линк.
- Включить BGP TTL/EBGP multihop только если нужно, но главное — включить BFD.
- MPLS/Provider‑side:
- Провести сверку с провайдером: profile SLA, policing rates, MTU, DSCP mapping, EXP‑remarking.
- Проверить LSP/TE path и, если применимо, запланировать TE‑перенаправление (reserve bandwidth).
- Физика/линки:
- Если обнаружены CRC/frame errors — заменить кабели/порт/перегруппировать порт, проверить SFP.
- Проверить/устранить дуплекс‑mismatch.
6) Валидировать изменения
- После каждой правки: повторный mtr/iperf тест, проверка NetFlow и интерфейсных графиков, сравнить метрики за те же часы нагрузки.
- Ожидаемые целевые значения: loss ≈ $0\%-0.5\%$ для важного трафика, RTT стабильно ниже целевого SLA (например \< $100$ ms), jitter \< $30$ ms.
- Держать ретроспективу 24–72 часа для подтверждения стабильности.
7) Контрольная проверка для типичной кейс‑ситуации «потери на границе BGP/OSPF»
- Запустить mtr к следующему‑хопу BGP/PE и дальше — локализация.
- Смотреть ifOutDiscards/Policer drops на CE и PE; если дропы у провайдера — согласовать изменение полиса или применить shaper у себя (чтобы не «втыкаться» в policed‑burst).
- Включить BFD для быстрого восстановления соседей; проверить MPLS LSP ping.
- Если MTU — включить MSS clamp и согласовать MTU на PE.
Короткий свод действий (порядок при инциденте)
1. Собрать mtr/iperf/tcpdump в момент события.
2. Проверить интерфейсные ошибки и дуплекс.
3. Проверить BGP/OSPF логи и BFD статус.
4. Проверить MTU/MSS.
5. Проверить QoS/policer drops и DSCP mapping.
6. Применить shaper/adjust MSS/BFD, затем валидация.
Если нужно — могу прислать конкретные CLI‑команды для вашей платформы (Cisco IOS/XE, Junos, Arista) и пример QoS‑политики и MSS‑clamp.