lacost Опубликовано 5 апреля, 2020 · Жалоба Поставили очередной S300 (взамен старого - без 10Г портов коммутатора другого вендора, старый вроде как работал, да уже портов в транк на аплинк перестало хватать). Начались проблемы на районе. У клиентов пропадает arp-запись о шлюзе. Не у всех, но постоянно где-то у кого-то. Помогает перезагрузка клиента. Говорят, у клиента не подмена arp-записи, а просто нет arp шлюза и все. На самом S300 - загрузка 60-65%, тогда как с аналогичной конфигурацией, +/- таким же объемом трафика на примерно таком же районе - загрузка 30%. Да и у больших районов загрузка cpu в районе 30% Первый раз с таким сталкиваемся. Обычно S300 поставил и забыл. А тут 2й день бьемся и не поймем в чем дело. Проверили уже все, что могли придумать. Мультикаст - есть. Отключение глобально PIM никак не влияет на ситуацию. Какие есть команды по мониторингу состояния коммутатора? Как понять чем занят процессор? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 5 апреля, 2020 · Жалоба conf local-arp enable cpu-rx prorocol arp 600 end wr Это вам или мерзкий встроенный неотключаеммый CoPP порезал или обработка транзитных arp. Перед вводом комманд выше снимите show cpu-rx prorocol all Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lacost Опубликовано 5 апреля, 2020 · Жалоба Было: _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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 5 апреля, 2020 · Жалоба Почистите счетчики, увеличьте оспф и мультикаст, если он используется. После наблюдайте и корректируйте. Настоятельно рекомендую осмотреть остальные с300 на этот предмет, жалобы до вас просто не доходили. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 5 апреля, 2020 · Жалоба Если вас CPU беспокоит, то снимите дамп или по счетчикам того же коппа гляньте, что там лишнего летит и порежьте mac acl на портах. Я, например, отрезал всё кроме ipv4, arp и mpls. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aleksey Sonkin Опубликовано 6 апреля, 2020 · Жалоба @lacostДобрый день! Выше в принципе верно написали, но желательно приложить 'sh ver' и 'sh run'. Предлагаю данной обращение решить в рамках support.nag.ru, а тут отписаться по результату, так будет удобнее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lacost Опубликовано 8 апреля, 2020 · Жалоба В сапорт написали. Но, экспериментировать на живых людях в карантин не решились. В итоге убрали новое - вернули старое. Со старым все работает. Алексей, вы отписались в традиционном стиле: меняйте прошивку на новую - разбираться с вашим старьем 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 и все? Для вас этого оказалось достаточно? Если я везде не прав, то дайте наводку - куда смотреть, что мониторить на коммутаторе, где наблюдается проблема по загрузке? Есть там не документированные команды по поиску/профилированию состояния коммутатора? За эти пару дней, что сражались с проблемой - документация была изучена, и там ничего подобного найдено не было. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aleksey Sonkin Опубликовано 8 апреля, 2020 · Жалоба @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, а здесь можно отписаться по итогу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lacost Опубликовано 10 апреля, 2020 · Жалоба Алексей, сразу спасибо за помощь. Ни в коем случае не хочу в чем бы то ни было вас обвинять. Опять же полностью понимаю ваш ответ по поводу старой прошивки. На данный момент у меня рабочим вариантом - идея поставить параллельно S300 и ночами, пытаться перекидывать интерфейсы на него и смотреть по загрузке. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aleksey Sonkin Опубликовано 6 мая, 2020 · Жалоба UPD. Проблема решена обновлением ПО, дефолтной настройкой CPU-RX и добавлением в конфигурацию 'local-arp enable'. Утилизация в порядке, проблем нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
