S300G высокая загрузка CPU

[lacost]

Поставили очередной S300 (взамен старого - без 10Г портов коммутатора другого вендора, старый вроде как работал, да уже портов в транк на аплинк перестало хватать).

Начались проблемы на районе. У клиентов пропадает arp-запись о шлюзе. Не у всех, но постоянно где-то у кого-то. Помогает перезагрузка клиента. Говорят, у клиента не подмена arp-записи, а просто нет arp шлюза и все.

На самом S300 - загрузка 60-65%, тогда как с аналогичной конфигурацией, +/- таким же объемом трафика  на примерно таком же районе - загрузка 30%. Да и у больших районов загрузка cpu в районе 30%

Первый раз с таким сталкиваемся. Обычно S300 поставил и забыл. А тут 2й день бьемся и не поймем в чем дело.

Проверили уже все, что могли придумать. Мультикаст - есть. Отключение глобально PIM никак не влияет на ситуацию.

Какие есть команды по мониторингу состояния коммутатора? Как понять чем занят процессор?

 

[vurd]

conf

local-arp enable
cpu-rx prorocol arp 600

end

wr

 

Это вам или мерзкий встроенный неотключаеммый CoPP порезал или обработка транзитных arp.

Перед вводом комманд выше снимите show cpu-rx prorocol all

[lacost]

Было:

_SNR_S300G# show cpu-rx protocol all
--------------------------Slot : 1----------------------
Type                Rate-limit    TotPkts        DropPkts
ALL_ARP             200           0              0
ARP                 400           4665553        67768
BFD                 400           0              0
BFD6                400           0              0
BGP                 200           0              0
BGP4+               200           0              0
BPDU_TUNNEL         100           0              0
CFMOAM_CCM          300           0              0
CFMOAM_OTHER        200           0              0
CLUSTER-DP          300           0              0
CLUSTER-DR          300           0              0
DAI-ARP             200           0              0
DHCP                200           0              0
DHCP-SNOOPING       200           0              0
DHCP_SUPPRESS       200           0              0
DHCPv6              200           0              0
DHCPv6-SNOOPING     200           0              0
DMAC-CPU            300           0              0
DNS                 100           3637           0
DOT1x               100           0              0
EAPOU               100           0              0
ECP                 400           0              0
ERPS                60            0              0
ERSPAN              50            0              0
FTP                 500           0              0
FTP6                500           0              0
GVRP                20            0              0
HSRP                100           0              0
HTTP                200           0              0
HTTP6               200           0              0
HTTPS/SSL           200           0              0
HTTPS6/SSL6         200           0              0
ICMP-REDIRECT       50            0              0
IGMP                200           156722         0
IPV6-HOPLIMIT       100           0              0
IPv6-NTP            50            0              0
ISIS                100           0              0
ISIS_TRILL          1000          0              0
L3-STATION-MOVE     100           0              0
LACP                40            0              0
LDP                 200           0              0
LLDP                20            0              0
LOCAL-IPUC          500           97558          0
LOCAL-IPV6UC        200           0              0
LOOPBACK            20            0              0
MLD                 200           0              0
MRPP                20            0              0
MULTICAST           20            8951           442
MULTICAST6          20            0              0
NDP-SNOOPING        400           0              0
NS-NA               200           6254           0
NTP                 50            0              0
OFP-CONTROL         400           0              0
OFP-NOTMATCH        200           0              0
OSPF                100           264213         432
OSPF6               100           0              0
OTHER-IPUC          200           328901         12721
OTHER-IPV6UC        200           0              0
PIM                 200           69965          0
PIM6                200           0              0
PPPoE               200           0              0
PROTECT-ARP         50            0              0
PROTECT-ICMP        60            0              0
RA-SNOOPING         100           0              0
RADIUS              100           0              0
RADIUS6             100           0              0
RIP                 100           0              0
RIP6                100           0              0
RS-RA               100           76849          0
SFLOW               50            0              0
SNMP                500           67046          0
SNMP6               500           0              0
SRCMAC-LEARN-LIMIT  10            0              0
SSH                 100           0              0
SSH6                100           0              0
STP                 80            0              0
TACACS              100           0              0
TACACS6             100           0              0
TELNET              100           4249           0
TELNET6             100           0              0
TFTP                500           0              0
TFTP6               500           0              0
TRILL               100           0              0
TUNNEL-MTU-ERR      10            0              0
TYPE-TTL0           100           12947          11962
ULDP                20            0              0
ULPP                300           0              0
UNKNOW-SMAC         100           0              0
VRRP                100           0              0
VRRP6               100           0              0
mac-in-mac          200           0              0
TOTAL-LIMIT         1200

 

после ввода local-arp enable и cpu-rx prorocol arp 600

 

show cpu utilization

Last  5 second CPU USAGE:  60%
Last 30 second CPU USAGE:  61%
Last  5 minute CPU USAGE:  65%
From  running  CPU USAGE:  61%

 

и 

 

#show cpu-rx protocol arp
--------------------------Slot : 1----------------------
Type                Rate-limit    TotPkts        DropPkts
ARP                 600           4709584        67768
TOTAL-LIMIT         1200
 

[vurd]

Почистите счетчики, увеличьте оспф и мультикаст, если он используется. После наблюдайте и корректируйте.

Настоятельно рекомендую осмотреть остальные с300 на этот предмет, жалобы до вас просто не доходили.

[vurd]

Если вас CPU беспокоит, то снимите дамп или по счетчикам того же коппа гляньте, что там лишнего летит и порежьте mac acl на портах. Я, например, отрезал всё кроме ipv4, arp и mpls.

[Aleksey Sonkin]

@lacostДобрый день!
Выше в принципе верно написали, но желательно приложить 'sh ver' и 'sh run'. Предлагаю данной обращение решить в рамках support.nag.ru, а тут отписаться по результату, так будет удобнее.

[lacost]

В сапорт написали. Но, экспериментировать на живых людях в карантин не решились. В итоге убрали новое - вернули старое. Со старым все работает.

Алексей, вы отписались в традиционном стиле: меняйте прошивку на новую - разбираться с вашим старьем 4-х летней давности нет смысла, и в принципе, я вас как технарь - понимаю.

Но, с другой стороны, у нас есть несколько таких же коммутаторов, с точно такими же прошивками (080) которые точно такой-же трафик от точно таких же абонентов переваривают нормально.

Вот теперь сидим и думаем: проблема с коммутатором была, и осталась не решена. Точно такая же проблема может случиться на работающих коммутаторах - а там решать ее не чем. На тех районах, где уже стоит S300 старый вариант с Длинками 3627 и 3620 уже не справлялся.

 

Опять останавливать сеть на районе, менять там коммутатор на S300 и "ждать решения" - это точно не вариант.

 

Все же хочу вернуться к вопросу проблемы, хоть и постфактум.

Симптомы: высокая загрузка самого коммутатора (хрен бы с ним), нет arp записи шлюза у клинета. Перезагрузка клиента - помогает.

 

Поправьте меня, если я ошибаюсь, но мне кажется что моя основная проблема (клиент не работал) была обусловлена следующим:

 

show cpu-rx protocol all

 

Type                Rate-limit    TotPkts        DropPkts
ALL_ARP             200           0              0
ARP                 400           4665553        67768

Значит, что arp-запросов очень много для данного Rate-limit, и часть этих пакетов сбрасывается.

У клиента, по истечении таймаута, начинает протухать arp-запись шлюза. Клиент делает запрос на who-has gw_ip

Данный запрос, из-за перегруза по rate-limit сбрасывается на коммутаторе.

Клиент после нескольких не успешных попыток прекращает работу.

 

Если это все так, то какой rate-limit считается нормальным для 3-4К arp-записей?

 

В 05.04.2020 в 19:19, vurd сказал:

Я, например, отрезал всё кроме ipv4, arp

Без разбора, просто по EtherType и все? Для вас этого оказалось достаточно?

 

 

Если я везде не прав, то дайте наводку - куда смотреть, что мониторить на коммутаторе, где наблюдается проблема по загрузке? Есть там не документированные команды по поиску/профилированию состояния коммутатора?

За эти пару дней, что сражались с проблемой - документация была изучена, и там ничего подобного найдено не было. 

 

 

[Aleksey Sonkin]

@lacost 
 

Цитата

Алексей, вы отписались в традиционном стиле: меняйте прошивку на новую - разбираться с вашим старьем 4-х летней давности нет смысла, и в принципе, я вас как технарь - понимаю.

Коллеги, давайте рассуждать разумно. Вам были даны рекомендации обновления ПО с той целью, что вы установили на сеть коммутатор с одной из самых старых версий ПО - R0010.0080. На текущий момент версия ПО R0010.00235. За эти четыре года было исправлено большое количество проблем, сделано много доработок, о чем я вам и сообщил в тикете. Более того, в одной из последних версии ПО S300 был увеличен pps лимит пакетов, направляемых в CPU, что косвенно тоже могло бы помочь вам в решении проблемы.

Цитата

Поправьте меня, если я ошибаюсь, но мне кажется что моя основная проблема (клиент не работал) была обусловлена следующим:

show cpu-rx protocol all

Все верно, но только если снимать эти данные единожды, то никакой диагностики не получится - потому что будет не видно динамики, роста тех или иных значений, в нашем случае дропов. Эти дропы могли появиться несколько месяцев назад во время петли, например. То же самое, если снимать диагностику 'sh tech' с рабочего коммутатора на котором нет проблем (то, что вы сделали в тикете). Нельзя диагностировать проблему по диагностическим данным другого коммутатора, на котором проблемы нет, надеюсь вы это понимаете.

Цитата

Если это все так, то какой rate-limit считается нормальным для 3-4К arp-записей?

Нормальным rate-limit считается дефолтный. Если с ним есть проблемы - проводится диагностика и он корректируется. Выше @vurd дал вам правильный совет по поводу local-arp enable. Если в сети не используется proxy-arp, supervlan, то перехватывать транзитные ARP-сообщения ни к чему, и отключение их обработки CPU могло значительно уменьшить нагрузку. Это единственный совет, который можно дать вам при той диагностике, которую вы приложили.
 

Исходя из вышесказанного, считаю рекомендации по обновлению ПО и установке коммутатора на сеть верными. Если вы обновите коммутатор, установите его на сеть, и проблема снова проявится - дайте нам знать. Для оперативной диагностики можете повторно снять 'sh tech' и два вывода 'sh cpu-rx protocol all' с таймаутом в пару минут.

 

Цитата

За эти пару дней, что сражались с проблемой - документация была изучена, и там ничего подобного найдено не было. 

В случае, если бы вы сразу обратились на support.nag.ru, думаю проблема уже была бы решена. Вы написали в тикете, что пытались решить проблему оперативно здесь, на форуме. Но оперативно проблемы необходимо решать как раз на support.nag.ru, при необходимости мы готовы подключиться удаленно, в том числе и подключить R&D.

 

Будем ждать от вас обратной связи для скорейшего решения проблемы. Лучше на support.nag.ru, а здесь можно отписаться по итогу.

 

[lacost]

Алексей, сразу спасибо за помощь. Ни в коем случае не хочу в чем бы то ни было вас обвинять. Опять же полностью понимаю ваш ответ по поводу старой прошивки.

На данный момент у меня рабочим вариантом - идея поставить параллельно S300 и ночами, пытаться перекидывать интерфейсы на него и смотреть по загрузке.

[Aleksey Sonkin]

UPD. Проблема решена обновлением ПО, дефолтной настройкой  CPU-RX и добавлением в конфигурацию 'local-arp enable'. Утилизация в порядке, проблем нет.