Добрый день.
Из двух коммутаторов DES-3226S собран стек. Модуль стекирования DES-332GS. Прошивка 4.02-B05.
На стековом порту в большом количестве возникают ошибки - RX frames Oversize. Ошибки есть как на master коммутаторе, так и на slave.
С чем это может быть связано?

характер трафика в сети?

_________________
С уважением, Карагезов Владислав

Обычный траффик - офисные приложения, интернет, почта. Загрузка на портах не высокая, обычно 3-4%. Эта ошибка появляется только на портах стекирования, на других портах такой ошибки не бывает.

У нас два таких стека по два DES3226S, соединены между собой транком (тип агрегатирования LACP). Ошибки возникают и на первом стеке, и на втором.

ок, разберемся.

_________________
С уважением, Карагезов Владислав

Разобрались? Аналогичный вопрос, пока был задействован один стек 3326 ошибок не замечал, запустили второй на 3226 и связали между собой транком (агрегатирование static) и увидел такие же ошибки.
В каждом стеке по два устройства, прошивки последние что есть у вас на фтп.

_________________
WBR,
Alexander

Еще раз повотрю вопрос - в чем может причина? Документацию читал, кроме описания что это за ошибка, ничего больше нет.

_________________
WBR,
Alexander

Мы протестировали данную ситуацию на двух стеках DES-3226S и DES-3326S. Нигде проблема не проявилась. В обоих случаях были последние прошивки.

Кажется наблюдаю аналогичную ситуацию.

Есть канал по такой схеме

Стек из двух 3226s во второй порт первого свича включен рутер
в пятый порт второго свича включен vdsl модем

vdsl модем на другом конце включен в 3ком1100
дальше идет оптика и доходит до второго 3 ком1100 потом опять идет оптика
она заканчивается на медиаконвертере через который подключен обычный свич и в который уже включен сервер клиента + всякие воипные железки
Фактически весь канал сделан чтобы клиенту предоставить эзернет, все железки совершенно простые, и прозрачные

До какого-то момента все это прекраснейшим образом работало, но вдруг (действительно вдруг - никто ничего не делал!)
рутер и сервер клиента перестали друг друга видеть

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

Так вот теперь самое главное
на стековом порту 1:26 первого свича в RX frames со страшной силой (~100pps) растут ошибки Oversize !
на стековом же порту второго свича 2:26 ошибки тоже есть, но растут они гораздо медленнее. на два порядка медленнее наверно.
Вопросов два.
Что делать?
Кто виноват?

Доберусь до узла - включу канал в другой порт на там же длинке, чтобы через стековые порты трафик не шел - результаты сообщу.

Забыл же самое главное добавить
Воипные железки прекрасно функционируют, но это потому что идут в обход рутера и работают с другими серверами (но опять же, между прочим, включенными на том же 1 свиче в стеке где и рутер)
Причем сервер клиента тоже прекрасно работает с другими серверами
Чтобы не думали - говорю сразу, traffic segmentation, vlan - все эти вещи я проверил.
Мне очень очень интересно - что думают гуру - что бы это могло значить? Я вроде тоже не дурак - но такое впервые вижу, чтобы ну по всем показателям должно работать - а не работает...

Единственная зацепка - вот эти Oversize пакеты, больше грешить не на что
Прошивка была 4.02B05, пользуясь случаем (стек стоит в центре сети, трогать без необходимости нельзя) залил 4.02B26 (надеюсь действительно избавлюсь от глюка с "забытием" шлюза по умолчанию)

Если возможно пришлите по почте конфиги коммутаторов, схему сети и желательно захваченные Sniffer-ом эти пакеты

Проблема существует, разработчикам отправлена просьба с тем, чтобы ее решить. Как только появятся новости - обязательно сообщим здесь.

Извиняюсь что не прислал никаких данных - времени не было, постараюсь на днях.
Проблему я решил - переткнул все в один коммутатор так что стековые порты перестали быть задействованы.
Самое интересное что источник ошибочных oversize пакетов был совершенно другой сервер (но кстати в том же 2-м свиче в стеке) характер трафика у него - только хттп и фтп пакетики диалапных пользователей полученных с тарелки, загрузка под 1 мбит
После того как и этот сервер переткнул в 1-й свич в стеке (т.е. опять без участия стековых портов) - ошибки расти перестали. Что интересно эти Oversize пакеты работе вроде как не сильно мешали, по крайней мере юзеры не сильно жаловались.

ответ из HQ по поводу oversize packets:

We can duplicate customer's scenario in our lab. It 's chip limitation. More detailed information as follow.

1.environment:

SMARTBIT-1
|
(1)
DES-3226S-1(4.02B26)
(26)
|
(26)
DES-3226S-2(4.02B26)
(1)
|
SMARTBIT-2


2.SMARTBIT-1 sent 1514 bytes to SMARTBIT-2 without CRC ,we also can find oversize parameter from DES-3226S-2 CLI .

3.Rule

1. Stacking port 26 support max packet length 2052(include 4 bytes CRC) bytes, Others,
this type have one characteristic, 4 bytes should be appended to packet with stack tag.
2. Other port support max packet length 1522(include 4 bytes CRC) bytes.
3. Oversize counters should be accounted: Counter incremented untag packet is received which exceeded 1518 bytes(Include 4 bytes CRC); Counter incremeneted tag packet is received which exceeded 1522 bytes(Include 4 bytes CRC).

4.For example

SMARTBIT1 inject 1514 untag packet(Without CRC), DES-3226S-2(4.02B26) port26 should appear oversize counters. But inject under 1510 untag packet(Without CRC), DES-3226S-2(4.02B26) port26's should not appear oversize counters.
-------- explain: 1514 untag packet(without CRC), DES-3226S-1(4.02B26) port26's should send packet max length's 1514 + 4(vlan tag) + 4( stack tag) + 4 (CRC) = 1526 > 1522. So counters should be appeared.

5.Explaintaion

This is chip limitation.Once packet total size length is over 1518 bytes(untag packet) or 1522(tag packet), Oversize counters will be accounted. But stacking port 26 received max packet lenght undersize 2052, the packet can be forwarded.Send 1514 bytes form smartbit 1 to smartbits 2, the stacking port 26 should be received max lenght 1514 + 4 (vlan tag) + 4 (stack tag) + 4 (CRC) = 1526 > 1522 . So stacking port 26 oversize counters should be accounted, but the packet can be forwarding nomarlly.

Прим. smartbit - это железки для тестирования.

_________________
С уважением, Карагезов Владислав

У меня такаяже проблема.
два коммутатора DES-3226s + DES-332GS
F: 4.02-B26
центр DGS-3212SR + DEM540
F: 3.00-B01
подключены по звезде
растет счетчик oversize... Сейчас выпустили вместо DES-332GS модуль стекирования DEM-320GS.
Данную проблему можно решить только заменой блока либо поиском источника oversize пакетов ?
Да они не сильно мешают работе коммутатора, но видеть:
Port number : 9:26
RX Frames ........... TX Frames
----------------------- ---------------------
CRC Error 0...................Excessive Deferral 0
Undersize 0....................CRC Error 0
Oversize.. 1247731930.....Late Collision 0
Fragment 0....................Excessive Collision 0
Jabber...... 0....................Single Collision 0
Drop Pkts.. 581194...........Collision 0

проблема только в принятых модулем DES-332GS пакетах...
Можно ли заменить старые модули на новые ?

Обмен вряд ли возможен - так как это не влияет на передачу трафика, то проще просто не обращать внимание. Дело в том что логика работы стекирующих портов несколько отличается от обычных