doubtpoint Опубликовано 8 июня, 2009 (изменено) · Жалоба настроили на c3560e-universalk9-mz.122-46.SE ip dhcp snooping ip dhcp relay information option-insert ip verify source port-security Все замечательно работает, пока не стали массово переводить пользователей Возникла такая проблема: первые пользователи нормально работают. Но через некоторое время что-то переполняется, и новые пользователи могут получать/исправлять IP но не могут ни куда передать данные. При этом старые пользователи нормально работают/могут выключить на час-другой ПК и включить и нормально работать. Лечиться перезагрузкой циски - все заработают пока опять таблица не переполниться. Новые пользователи - те кто раньше(до проблем) получат свой IP. Временем(без перезагрузки) проблема не лечиться. Так же проблема не лечиться сама в ночное время, когда нагрузка минимальна. Ощущение, что с каждым binding заполняется какая то таблица и не очищается ни какими средствами.(Пробовал почти все со слов clear) Изменение sdm с routing на access ни какого эффекта не дало. На другие sdm изменить не могу т.к. используем route-map. Как решить эту проблему или это предел данного девайса? PS: Может кто ни будь пришлет более новую прошивку чем c3560e-universalk9-mz.122-46.SE ? ------------------------------------------------------------------------- На данный момент (наблюдается проблема), но нагрузка минимальна(2 часа ночи) #sh ip dhcp snooping binding Total number of bindings: 580 #sh platform tcam utilization asic all CAM Utilization for ASIC# 0 Max Used Unicast mac addresses: 4316/4316 1799/1799 IPv4 IGMP groups + multicast routes: 1120/1120 1/1 IPv4 unicast directly-connected routes: 4096/4096 957/957 IPv4 unicast indirectly-connected routes: 2048/2048 100/100 IPv4 policy based routing aces: 512/512 42/42 IPv4 qos aces: 512/512 11/11 IPv4 security aces: 2048/2048 31/31 CAM Utilization for ASIC# 1 Max Used Unicast mac addresses: 4316/4316 1799/1799 IPv4 IGMP groups + multicast routes: 1120/1120 1/1 IPv4 unicast directly-connected routes: 4096/4096 957/957 IPv4 unicast indirectly-connected routes: 2048/2048 100/100 IPv4 policy based routing aces: 512/512 0/0 IPv4 qos aces: 512/512 11/11 IPv4 security aces: 2048/2048 918/918 #sh mac address-table count Total Mac Address Space Available: 2280 ------------------------------------------------- В худшие времена (20 вечера) #sh ip dhcp snooping binding Total number of bindings: 1500-1700 #sh mac address-table count Total Mac Address Space Available: 700-900 Unicast mac addresses: 3200 IPv4 unicast directly-connected routes: 2000 IPv4 security aces: 1100 ------------------------------------------- Изменено 8 июня, 2009 пользователем doubtpoint Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Konstantin Klimchev Опубликовано 9 июня, 2009 (изменено) · Жалоба настроили на c3560e-universalk9-mz.122-46.SE а думаю опечатались? тема про 3750E в теме про c3560e Изменено 9 июня, 2009 пользователем Konstantin Klimchev Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 9 июня, 2009 · Жалоба ip verify source port-security мне телепатически кажется дело в этом, ip source guard на коммутаторах доступа, а это именно коммутатор доступа(или top of the rack) просто очень продвинутый :), не предназначен для тысяч биндингов. p.s. хотя вот прочитал что E они всё таки считают aggregation Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
doubtpoint Опубликовано 9 июня, 2009 · Жалоба настроили на c3560e-universalk9-mz.122-46.SE а думаю опечатались? тема про 3750E в теме про c3560e Да опечатались- свич c3560e, но думаю проблема была бы на 3750e и 3560e. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Stak Опубликовано 10 июня, 2009 · Жалоба Топикстартеру: Удалось забороть проблему? Очень интересно))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
doubtpoint Опубликовано 11 июня, 2009 · Жалоба Топикстартеру: Удалось забороть проблему? Очень интересно))) К сожалению нет. Даже не поняли какой буфер переполняется и как его смотреть. Сейчас сняли с данной циски несколько сотен пользователей и перезагружаем ее каждую ночь. PS: Приняли решение поставить 65 циску - все равно она планировалась. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Stak Опубликовано 11 июня, 2009 · Жалоба Ощущение, что с каждым binding заполняется какая то таблица и не очищается ни какими средствами.(Пробовал почти все со слов clear) Попробуйте базу привязок на tftp вынести, может поможет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
doubtpoint Опубликовано 13 июня, 2009 (изменено) · Жалоба Ощущение, что с каждым binding заполняется какая то таблица и не очищается ни какими средствами.(Пробовал почти все со слов clear)Попробуйте базу привязок на tftp вынести, может поможет? На след. неделе найдем еще один свич и будем его морочить. Просто пользователи уже воют - в день три раза перезагружать, а грузиться она долго :-( Изменено 13 июня, 2009 пользователем doubtpoint Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
