Диагностика трафика на Huawei без простоев: снимаем дамп через CLI и импортируем в Wireshark — АйТи Фреш
Сетевая диагностика · 10 мин чтения

Снимаем дамп на Huawei за минуту: диагностика трафика без остановки продакшена

Снимаем дамп на Huawei за минуту: диагностика трафика без остановки продакшена

Привет! Я Евгений Семёнов, директор ITFresh. Знаете, есть такая ситуация, которая у меня повторяется практически каждый месяц. Обычно звонок в пятницу вечером: клиент сообщает, что в одном из филиалов внезапно перестала работать 1С. А вот в головном офисе, по их словам, «всё отлично». Мы начинаем разбираться, диагностировать. И что обнаруживаем? Пакеты-то доходят до маршрутизатора Huawei NE40, что стоит на границе провайдера, но вот обратно почему-то не возвращаются. Без дампа трафика прямо с оборудования тут просто не обойтись! Но кто же даст поставить SPAN-порт или городить Linux-сервер рядом до понедельника? Конечно, никто. Не проблема! Я сейчас покажу вам, как снять pcap прямо с вашего Huawei через SSH всего за пять минут, а потом легко открыть его в Wireshark на своём ноутбуке. Способ, честно говоря, до смешного простой, но почему-то далеко не каждый сетевой администратор о нём знает.

Почему обычный tcpdump не подходит

Классический сценарий диагностики: настраиваете SPAN (в терминах Cisco) или mirror-port (в терминах Huawei), подключаете к зеркальному порту Linux-сервер с tcpdump, снимаете дамп, открываете в Wireshark. Работает отлично — но требует:

Встроенная команда capture-packet на Huawei решает все три проблемы: дамп снимается самим маршрутизатором, результат выводится в hex прямо в терминал SSH. На ноутбуке у вас копия пакетов за 30 секунд — разбирайте спокойно.

VRP5 и VRP8: разница есть

Обычно мы сталкиваемся с Huawei VRP (Versatile Routing Platform) в двух основных версиях:

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

VRP8: минимальный рабочий пример

Что ж, первым делом подключаемся к роутеру по SSH. И оттуда уже заходим в system-view:

<NE40-BRANCH> system-view
[NE40-BRANCH] capture-packet forwarding interface GigabitEthernet1/0/1.300 \
  packet-num 30 packet-len 64 \
  time-out 60 match-condition acl 3001

Что здесь:

ACL 3001 можно создать заранее:

[NE40-BRANCH] acl number 3001
[NE40-BRANCH-acl-adv-3001] rule 10 permit ip source 10.10.0.50 0 destination 10.99.0.10 0
[NE40-BRANCH-acl-adv-3001] rule 20 permit ip source 10.99.0.10 0 destination 10.10.0.50 0
[NE40-BRANCH-acl-adv-3001] quit

Вывод hex прямо в терминал

Завершили захват? Отлично, теперь смотрим, что получилось:

[NE40-BRANCH] display capture-packet file

Packet 1 at 2026-01-15 18:42:17.123, length=82
  0000  00 24 68 aa bb cc 00 1a  2b cc dd ee 81 00 01 2c
  0010  08 00 45 00 00 50 1f 34  40 00 3f 06 a2 df 0a 0a
  0020  00 32 0a 63 00 0a 0b b8  1f 90 5e 3c 11 22 00 00
  0030  00 00 a0 02 fa f0 8a 9d  00 00 02 04 05 b4 04 02
  0040  08 0a ff ff ff ff 00 00

Packet 2 at 2026-01-15 18:42:17.234, length=82
  0000  00 1a 2b cc dd ee 00 24  68 aa bb cc 81 00 01 2c
  ...

Копируем весь вывод в буфер (прямо из putty/kitty/terminal) и сохраняем в файл capture.hex на ноутбуке.

Импорт в Wireshark: главная хитрость

Кстати, Wireshark просто отлично работает с импортом hex-дампов. Тут главное — не запутаться в настройках и указать их верно. Что делаем? Открываем Wireshark, потом жмём File, а там уже выбираем Import from Hex Dump.

Параметры:

Запомните этот важный момент: если вдруг пакет окажется короче 64 байт – а такое бывает, скажем, с ARP – его обязательно, слышите, обязательно нужно дополнить нулями до нужных 64 байт вручную! Иначе Wireshark просто-напросто распознает его как повреждённый. Чтобы не тратить время на эту рутину, я даже специально написал маленький Python-скрипт. Это дико удобно, поверьте!

#!/usr/bin/env python3
import re, sys
with open(sys.argv[1]) as f:
  txt = f.read()
out = []
for line in txt.splitlines():
  m = re.match(r'\s*([0-9a-f]{4})\s+(.+)', line, re.I)
  if m:
    hex_part = re.sub(r'[^0-9a-f]', '', m.group(2), flags=re.I)
    # добить нулями до чётности
    hex_part = hex_part + '00' * ((128 - len(hex_part)) // 2) if len(hex_part) < 128 else hex_part
    out.append(f"{m.group(1)} {hex_part}")
  else:
    out.append(line)
print('\n'.join(out))

VRP5: чуть сложнее

А вот на более старых NE40 команда остаётся той же, но есть нюанс: сначала потребуется указать instance-id.

<NE40-V5> display capture-packet-instance
Instance ID: 17

И затем:

[NE40-V5] display capture-packet file instance-id 17

Без instance-id получите пустой вывод или ошибку. На NE80E старого поколения дополнительно нужно быть в режиме hidden-cmd для доступа к forwarding engine — _hidecmd и тогда работает.

MPLS и почему он отдельная боль

Что делать, если роутер в вашем филиале трудится как CE/PE в MPLS-сети провайдера? В таком случае, дамп с интерфейса, конечно же, покажет MPLS-заголовки, а уже под ними будет спрятан ваш IP. Обычно Wireshark вполне успешно разбирает MPLS по умолчанию, но иногда, да, он может слегка запутаться.

Как же с этим быть? Да всё просто! Прямо в Wireshark, на первом MPLS-пакете, правой кнопкой мыши. Выбираем 'Decode As' → 'MPLS' → 'Next protocol'. А дальше уж выбирайте, что вам нужно: IPv4, IPv6 или Ethernet. И вот ещё что: если вдруг это L2-VPN с Control Word, ни в коем случае не забудьте поставить ту самую галочку 'Has Control Word'.

На нашей практике был случай, который я хорошо помню: у одного из клиентов – крупной логистической компании, сорока рабочих мест в филиале в Твери, подключенном через MPLS-провайдера – мы долго ломали голову. Почему MPLS-метка внезапно менялась на одной из десятков связок? Дамп трафика тогда всё прояснил: оказалось, провайдер (ISP) пометил пакет не одной, а сразу двумя лейблами – внешним для transport и внутренним для L3VPN. Без точного указания 'Decode As' Wireshark воспринимал это как IPv6, и, естественно, разобраться было невозможно. Но как только мы расшифровали данные корректно, причина стала очевидна: один из роутеров ISP менял метку! Тогда уже мы смогли предметно выйти на провайдера и решить вопрос.

SIP и VoIP — почему 64 байта иногда мало

Представьте классическую ситуацию с VoIP: «телефоны звонят, но абоненты друг друга не слышат». Знакомый сценарий, правда? Чаще всего причина в RTP, который почему-то упорно идёт не туда, куда должен. А чтобы понять, где именно он теряется, нам, конечно, нужен дамп трафика, и с достаточной длиной. Вот посмотрите: 64 байта – это же как раз IP-заголовок (20 байт) плюс UDP (8 байт) и RTP-header (12 байт). В сумме всего 40 байт. На полезную нагрузку (payload) остаётся лишь 24 байта, и этого, понятное дело, катастрофически мало. Зато, мы увидим хотя бы RTP headers, и это уже будет отправной точкой!

Для SIP-сигнализации, например, нам понадобится уже значительно больше данных – где-то от 256 до 512 байт на пакет. Почему так много? Всё просто: SDP, который обычно встраивается в INVITE-пакет, может быть весьма объёмным. Но не беда, на оборудовании Huawei параметр packet-len можно увеличить очень легко.

[NE40-BRANCH] capture-packet forwarding interface Gi1/0/2 \
  packet-num 50 packet-len 256 \
  match-condition acl 3010
# ACL 3010 ловит SIP (UDP 5060)

Но будьте осторожны! Увеличенный packet-len означает и большую нагрузку на forwarding engine. Поэтому не оставляйте такой захват трафика на длительное время, иначе могут возникнуть проблемы.

Когда capture-packet не работает

Иногда бывает так, что на определённой модели роутера нужной команды просто нет. Что тогда делать? Вот возможные варианты:

Ну что ж, когда совсем прижмёт, придётся раскошелиться на внешний TAP-девайс. Мы используем что-то вроде Profitap P-V80 или Dualcomm, ставим его прямо в разрыв линка. Да, ценник кусается – около 80 тысяч рублей. Но если у вас реально серьёзная, гигабитная проблема, поверьте, без такого устройства вы просто не справитесь.

Кейс: диагностика MPLS-проблемы за 40 минут

Представьте: сидишь ты такой в субботу, никого не трогаешь, а тут звонок. Год был 2026, январь. На той стороне Евгений Сергеевич: «У нас в филиале, в Калуге, полностью отвалилась связь с 1С-сервером в Москве! При этом интернет, как ни странно, работает». Клиент, к слову, крупная строительная компания. У них в Калуге 34 рабочих места, SIP-телефония тоже через Москву, а 1С — через надёжный, казалось бы, MPLS-туннель от провайдера. Ну что, знакомая история, да?

Выезжать на объект? Ну уж нет, это же суббота! Вместо этого я просто подключился к роутеру Huawei AR2200 в калужском филиале прямо из дома, по SSH. И вот что я тогда сделал:

  1. display interface GigabitEthernet0/0/1.100 — интерфейс в MPLS, пакеты уходят, ответы частично приходят.
  2. Настроил ACL с ID 3030. Он отфильтровывал трафик от 1С-клиента (10.10.1.50) к 1С-серверу (10.99.2.20).
  3. capture-packet forwarding interface Gi0/0/1.100 packet-num 50 packet-len 128 match-condition acl 3030 time-out 30.
  4. Затем я просто скопировал весь hex-вывод на свой ноутбук и тут же импортировал его в Wireshark. Готово!
  5. И вот что я обнаружил! Исходящие пакеты от клиента улетали с одной MPLS-меткой, а входящие... возвращались, но уже с МЕТКОЙ НА СОВЕРШЕННО ДРУГОМ VC! Что это значит? Провайдер где-то у себя «сломал» L2VPN-сессию. Проще говоря, pseudowire просто разорван.
  6. Сразу же отправил тикет провайдеру, приложив все конкретные метки и точное время инцидента. Представляете, уже через 20 минут они подтвердили: «Да, у нас MPLS LSP сломалась на одном из сегментов». Ещё 10 минут — и всё снова заработало. Без дампов, конечно, это заняло бы вечность.

Знаете, общее время от звонка клиента до того момента, как связь полностью восстановилась, заняло у меня всего 40 минут. Только представьте! Без захвата пакетов я бы, наверное, целый час гадал, что, чёрт возьми, значит это «связи нет, но интернет работает», и ещё добрый час доказывал бы провайдеру, что проблема точно на их стороне. А вот когда у тебя на руках готовый дамп трафика, разговор с ISP обычно занимает от силы пару минут. Вот это я называю эффективность! Это же просто бесценно.

Общие рекомендации

Разберём вашу сетевую проблему — от 6 500 руб/час

Я лично провожу срочную диагностику сетевых проблем на корпоративной инфраструктуре в Москве и области. Работаю с оборудованием Huawei, Cisco, Eltex, Mikrotik, Juniper. Могу читать дампы, разбираться с MPLS, SIP, BGP, OSPF. При необходимости выезжаю на объект или работаю удалённо через SSH/VPN. Типовой инцидент обычно разбирается за 1-3 часа. А для клиентов, которые у меня на поддержке, есть даже круглосуточный hot-line.

Телефон: +7 903 729-62-41
Telegram: @ITfresh_Boss
Семёнов Евгений Сергеевич, директор АйТи Фреш

FAQ — диагностика на Huawei

Зачем снимать дамп прямо на маршрутизаторе, если есть SPAN-порт?
SPAN нужен свободный порт + сервер с tcpdump в том же сегменте. На удалённых площадках (магазин, производственный цех) обычно ни того, ни другого нет. Встроенный capture-packet снимает трафик прямо на железе и передаёт дамп в hex через SSH-сессию — ничего физически везти не нужно.
Почему ограничение 64 байта на пакет?
Это защита от перехвата полных данных — особенно SIP/RTP, где 64 байта покрывают заголовки, но не аудио. Для диагностики проблем с установлением соединения, маршрутизацией, MPLS-метками этого хватает с запасом. Если нужен полный пакет — нужна отдельная разрешительная логика или внешний tap.
Как разобрать MPLS-трафик на Huawei?
При импорте pcap в Wireshark нужно явно указать Decode As для нужных L2-VPN меток — Ethernet, IP, или Control Word для pseudowire. Также включить расшифровку для Label в SubProtocol. На VRP5 дополнительно нужно знать instance-id, без которого capture не даст правильный VRF.
Можно ли оставить capture включённым надолго?
Нет. capture-packet заметно нагружает forwarding engine на NE40/NE80 и CX-серии. Держите не дольше 30-60 секунд. Для длительного анализа используйте Mirror-сессию на отдельный порт с внешним tcpdump — капле-сервер на Linux в ту же L2-сеть.
Какие альтернативы capture-packet, если он не работает?
На старых VRP3 / младших S-серии capture-packet может отсутствовать. Варианты: traffic-mirror на SPAN-порт с подключенным Linux-tcpdump, info-center + debug ip traffic с разбором в syslog, или внешний tap device в разрыв линка (для критичных расследований). Для Huawei MA-серии (oemvlan) используется display observe.

Похожие статьи

Подпишитесь на рассылку ITfresh

Каждую неделю мы делимся с вами свежими, по-настоящему практическими гайдами. Они идеально подойдут как для руководителя IT, так и для сисадмина. Ждите материалы по безопасности, 1С, миграциям, резервным копиям и кучу лайфхаков, взятых прямиком из наших реальных проектов. Коротко и по делу!

Реквизиты оператора персональных данных

ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.