Как выявить флуд в туннеле nhrp?

[Anton84]

Здравствуйте, есть несколько офисов объединенных vpn-облаком на основе nhrp, один hub и несколько spoke'ов.  С недавнего времени сеть за одним из споков да и сам этот роутер начал дико тормозить со тороны других офисов. Интернет ресурсы с этого спока достигаются без проблем. А с других офисов на него идут потери до 30%.

Настройка hub:

interface Tunnel1
 ip address 192.168.35.1 255.255.255.240
 no ip redirects
 ip nhrp authentication 123
 ip nhrp network-id 123
 ip ospf network broadcast
 ip ospf hello-interval 60
 ip ospf priority 10
 ip ospf mtu-ignore
 cdp enable
 tunnel source GigabitEthernet0/1
 tunnel mode gre multipoint
 tunnel key 123

Настройка проблемного spoke:

  bind control source-interface GigabitEthernet0/1
interface Tunnel1
 ip address 192.168.35.5 255.255.255.240
 no ip redirects
 ip mtu 1400
 ip nhrp authentication 123
 ip nhrp map multicast X.X.88.114
 ip nhrp map 192.168.35.1 X.X.88.114
 ip nhrp network-id 123
 ip nhrp holdtime 60
 ip nhrp nhs 192.168.35.1
 ip nhrp registration timeout 60
 ip tcp adjust-mss 1360
 ip ospf network broadcast
 ip ospf hello-interval 30
 ip ospf priority 0
 cdp enable
 tunnel source Dialer0
 tunnel mode gre multipoint
 tunnel key 123

Как бы мне отдебажить весь трафик в момент потерь, они возникали и прекращались всегда примерно в одно время. Может конечно

 ip tcp adjust-mss 1360

 ip mtu 1400

поможет

[Sergei Vasilenko]

Добрый день,

Возможные варианты :

- Netflow cache;

- span

и посмотреть данные в момент всплесков.

Сергей

[Anton84]

Выявил место проблемы по графикам observium: на внутреннем интерфейсе роутера начинают копиться input errors прямо пропорционально трафику через него, если начинают качать/отдавать под 60Мбит/с, то на внутреннем интерфейсе, идущего к пользователям лавинообразно растут input errors, делал debug ip error detail, не вижу ошибок на консоли. Если трафик 60-80Мбит/с, то применять SPAN тяжело, будет куча мусора. Может еще какие-то дебаги помогут?

В сети обычно говорят, что input errors чаще всего связаны с физическими проблемами в проводе, порту eth. Но я думаю это не тот случай.

[Sergei Vasilenko]

Добрый день, Антон,

Надо смотреть кикие именно input errors.

Если overruns, flush и input queue size не 0, то это возможно 

результат и следствие возрошего трафика в этот момент и

просто упираемся в производитедльность платформы.

Нужно смотреть show proc cpu в это время и какой процесс

наиболее занят (ip input лопустим) или же загрузка за счет уровня прерываний.

Если вручную поймать помент проблемы сложно - то можно настроить

небольшой EEM скрипт, который бы при превышении

загрузки interface собирал бы нужны набор команд в файл.

В него же добавит вывод по netflow (show ip flow cache).

С точки зрения полки производительности - Что за платформа? Какой IOS?

Сергей

[Anton84]

Здравствуйте, в момент возрастания трафика ( невсегда) возникают как раз ошибки типа overrun, которые по описанию означают, что пришло слишком много пакетов на сетевой интерфейс и они все не влезли в буфер. Платформа cisco 2951. Интерфейс Gi. Ошибки возникают при трафике в 50-60 Мбит/с, т.е. роутер должен осилить. Вот и странно, почему они копятся, попробую в момент возникноверия посмотреть sh process cpu.

[Anton84]

IOS Version 15.7(3)M1

[Anton84]

И еще доп. информация, к этому интерфейсу роутера подключен внешний интерфейс ASA5506, на ASA ошибок нет.

[Sergei Vasilenko · Accepted solution]

Добрый день,

Если брать производительность с2951, то при условии, что никакие функции не настроены
- максимум для железки 580K pps / 297Mbps.
Но нужно учеть, что это суммарная велична по всем rx+tx на всех интрефейсах.

По добавлению функций (qos,nat,acl и т.д. будет проседание)

Т.е. то что есть overruns в момент повышенного трафика может означать
- много process switched трафика (а не CEF switched);
- приближение к максимальной производительности по трафику для данной платформы,
с учетом настренных фитч;

Т.е. это скорее следствие повышенного трафика, а не причина его появления.

В момент проялвения для начла посмотреть
- show process cpu | exc 0.00
- show interfaces summary
- show int switching (скрытая опция)
- show ip cef switch statis

Нужно понять какая загрузка ЦПУ в момент проявления и чем (процесс vs interrupt).

Если будет поднятие ЦПУ - то другие шаги и пример EEM можно посмотреть
например здесь:
https://www.cisco.com/c/en/us/support/docs/routers/7500-series-routers/41120-highcpu-interrupts.html

Для подтверждение того, что за трафик начинает приходить
в это время - netflow cache (коллектор не нужен) или же захват.
Есть также опция с Embedded Packet Capture,
но нужно смотреть поддерживается ли на плтформе/версии ios:
https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ios-embedded-packet-capture/datasheet_c78-502727.html?dtid=osscdc000283

Спасибо,
Сергей