Опишу как тестил у себя:
Сеть с 3326GSR в ядре, на нем DHCP, 55 вланов, 55 интерфейсов L3 (в основном по интерфейсу на влан), мультикаста нет, оннлайн 600 - 1800 IP, на 24 порту файлопомойка 5 тер на freebsd 7, em0 подключен к 24 порту медью.

Для теста:
Отключил фтп, написал на форуме что вместо фтп - DC++
Подключил на 3326GSR 10 вланов в тегированом виде на 24 порт, создал на фре 10 интерфейсов вида
ifconfig vlan125 create vlan 125 vlandev em0
ifconfig vlan125 192.168.125.43
(у всех 1 мак, такойже как у em0)
Создал 10 виртальных хостов JAIL с MICRODC2 внутри по 1 на каждом vlanxxx, расшарил по куску файлопомойки через каждый MICRODC2.
Запустил батник писать 120 SNMP параметров.
Все работает, все хорошо но до случайного момента.

За день половина vlanxxx интерфейсов на фре переснали получать арп ответы от свича и эти MICRODC2 отвалились от DC сервера.

Далее названия параметров и их приращения начиная с момента чуть раньше перегрузки ЦПУ(100%).
Нижняя отдельная строка - нормальная работа под нагрукой.


Больше всего похоже что юзер начал качать с DC, с того интерфейса чья ARP запись уже потеряна но MICRODC2 еще неотвалился, поток с сервера на свич нормальный а со свича на сервер дублируется броадкастом через процессор на 5 портов(в табличке показан броадкаст тока на 24 порт).

Сброс арп таблици нормализует загруз ЦПУ но уже отвалившиеся вланы обратно невосстанавливаются.

6го в 12 раздал вланам на фре случайные маки, с тех пор нагруз на ЦПУ пики 50%,средний - 5-20%, все dc клиенты живы.
У кошаков на всех интерфейсах одинаковые маки - при использовании 3326 и циски вместе, 2х общих адресных пространствах в разных вланах возможна такаяже ситуация?

П.С. планирую, конфигурю 3627 теперь уже неспеша

В DGS-36XX такая проблема точно не наблюдается. А Вы в такой момент можете прислать выводы таблиц IPFDB и ARP? Вы кстати пробовали прошивку ветки 4.50-BXX?

Пробовал но тогда была еще проблема с 23 портом и одно накладывалось на другое, ща работает отлично 2е суток.

Пост выше с прошивкой Build 4.40-B16.

Когда были подвисания писал, ща разобрал, прошивка была Build 4.40-B16.


Таблички писались примерно минуту, 192.168.136.7 - один из адресов сервера, 192.168.125.43 другой для примера.



сниму - поэксперементирую

Ждём результатов!

Вот значения счётчиков, которые Вы просили:

1. ipInReceives: Полученные IP-пакеты.

2.ipForwDatagrams: Кол-во полученных дейтаграмм для которых этот свитч не является финальным пунктом назначения по IP. Это пакеты по которым была сделана попытка найти маршрут к назначению и скоммутировать их в эту сторону.

Чем ЦПУ или АСИК? подозреваю что ЦПУ

По этому поводу уточняю.

Это вообщем на устройство. Вот более подробное описание в оригинале:

Name: ipInReceives
Type: OBJECT-TYPE
OID: 1.3.6.1.2.1.4.3
Full path: iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).ip(4).ipInReceives(3)
Module: IP-MIB

Parent: ip
Prev sibling: ipDefaultTTL
Next sibling: ipInHdrErrors

Numerical syntax: Counter (32 bit)
Base syntax: Counter32
Composed syntax: Counter32
Status: current
Max access: read-only

Description:
The total number of input datagrams received from
interfaces, including those received in error.
______________________________________________________________________

Name: ipForwDatagrams
Type: OBJECT-TYPE
OID: 1.3.6.1.2.1.4.6
Full path: iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).ip(4).ipForwDatagrams(6)
Module: IP-MIB

Parent: ip
Prev sibling: ipInAddrErrors
Next sibling: ipInUnknownProtos

Numerical syntax: Counter (32 bit)
Base syntax: Counter32
Composed syntax: Counter32
Status: current
Max access: read-only

Description:
The number of input datagrams for which this entity was not
their final IP destination, as a result of which an attempt
was made to find a route to forward them to that final
destination. In entities which do not act as IP routers,
this counter will include only those packets which were
Source-Routed via this entity, and the Source-Route option
processing was successful.