Добрый день, у нас на сабжевом коммутаторе выская загрузка CPU. Если выполнить комманду :
sw-l0-8#sh cpu
CPU utilization in five seconds: 49%
CPU utilization in one minute : 65%
CPU utilization in five minutes: 64%
NO 5Sec 1Min 5Min Process
0 4% 4% 4% LISR INT
1 1% 1% 1% HISR INT
2 0% 0% 0% ktimer
....
35 11% 11% 11% tnet
36 26% 35% 39% Tarptime
...

Интересует, что такие за процессы tnet,Tarptime и почему они так сильно нагружают свитч. Спасибо за ответ.

А сколько абонентов на свиче?
Я бы не сказал, что это высокая загрузка.

около 2-х тыс и постепенно растет Пока правда все работает, но консоль уже ужасно тормозит. Поэтому и страшно - не начнутся ли какие-нибудь потери трафика от нагрузки ?

Процесс Tarptime - как я понимаю связан с arp запросами клиентов, но почему он столько процессорного времени съедает или же для 2к пользователей это нормальная нагрузка ?

Загрузка вполне нормальная.
Если я всё правильно помню, у вас схема с SuperVLAN?

Да, у нас сеть собрана на использовании SuperVLAN. Как выяснилось очень сильно снизило нагрузку изменение параметров arp retry times и arp retry interval

=======================================
CPU Using Rate Information
CPU utilization in five seconds: 14%
CPU utilization in one minute : 25%
CPU utilization in five minutes: 17%
....

Давно уже воюю с 3610 и его сабвиланами. Сегодня где то около 500 сабвиланов из них около сотни в одном супервилане и остальные в другом. Использую Прокси Арп. После того как добавил последних 400 сабвиланов (перевел на такую схему сегмент) замечаю очень много траблов разного рода и не могу их побороть окончательно. Первое - это то что без всяких видимых причин длинка зависала наглухо, не управлялась не роутила, пропускала только трафик L2. Продолжалось это от пяти до 10 минут. Пытался победить это при помощи CPU protect arp, ограничения ставил самые разные кол-во пакетов и т.д. - нулевой результат. Победили все теми же изменение параметров arp retry times и arp retry interval. Но как была так и осталась проблема временного отваливания консоли. Причем доступ пропадает из маршрутизируемых сетей, из вилана управления в одной подсети не пропадает... Консоль тормозит у него в принципе - уже вроде и привыкли, как будто сидим на диалапе с гнилыми линиями, настолько это часто происходит.
Но не это самое страшное, самое страшное это то, что после решения проблемы с зависаниями связь у всех кто работает на этом девайсе стала нестабильной (может проблема была и раньше просто я не замечал), теряются пакеты, что хорошо видно по пингам, страшно то что теряются пакеты именно до шлюза (3610), что ну очень хорошо видно при использовании mtr. Стоит заметить что на субвиланах так и до сих пор не реализовали АСL которые бы работали, и имеет место красивейший PBR. Интересно когда это поправят?

Внимание вопрос: ))) потери - это косяк с железом? С софтом? Или с моими руками?

Понимаю, что использование прокси арп накладывает ограничения, но почему так глючит связь при загрузке железки не выше 20% (как правило около 10%). И непонятно почему такие проблемы как у тех кто в сабвиланах и у других. Очень сильно теряются пакеты у тех кто бегает с 3610 не по шлюзу а по Route-map.

Прошу откликнуться тех у кого были или не было подобных проблем, может кто то победил этот девайс?

1 Какая прошивка ?
2 зачем proxy arp если пользуете Super-Vlan ?

DGS-3610#sh ver
System description : DGS-3610-26G Gigabit Ethernet Switch
System start time : 2009-12-16 19:15:17
System uptime : 46:12:33:47
System hardware version : A1.0
System software version : v10.3(5), Release(67526)
System BOOT version : 10.3.67526
System CTRL version : 10.3.67526
Device information:
Device-1
Hardware version : A1.0
Software version : v10.3(5), Release(67526)


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

2gda А вы получиали мои письма, где я просил снять информацию с устройства?

Ту проблему о которой мы переписывались мы решили, 3610 перестал зависать, теперь у меня теряются пакеты и зачастую до шлюза. Какую информацию собственно снимать. Когда была проблема описанная чуть выше инфу мы снимали, вы её получили. Меня беспокоит нынче стабильность маршрутизации. И ещё очень пугает что те кто бегают через Route-map, стабильно имеют потери после шлюза (на идеальном и не загруженном участке сети). Загрузка железки ничтожна. То что внутренние сети на длинке отваливаются - однозначно, только сегодня видел. И не понятно почему так жутко тормозит консоль.

Ну так давайте решать проблему, если она есть.
В последний раз я просил:
show ip route
show arp
show ip ref route
show ip ref adjacency
во время проявления проблемы, но её так и не поступало

Хорошо, а как быть с тем что из скажет сотни пакетов стабильно теряется 5, или mtr показывает что на шлюзе 7-8 процентов потерь у кого либо одного. Присылать запрошенное? Проблема в том что это происходит постоянно у кого либо из сети, быстро проходит и начинается снова (((.

Для этого нужно описание, конфиг и те же дебаг команды, которые Вы снимали @@