Схема сети следущая все линки гигабитные кроме радиорелейки(750Мбит):
|роутер|--медный_линк_ethernet--|коммутатор|--оптика--|коммутатор|--медный_линк_ethernet--|РРЛ|--радио_линк--|РРЛ|--|коммутатор|

На последнем коммутаторе справа (модель D-link DES-3528) при просмотре ошибок на порту аплинка:
show error ports 26
Port Number : 26
RX Frames TX Frames
--------- ---------
CRC Error 7 Excessive Deferral 0
Undersize 0 CRC Error 0
Oversize 24 Late Collision 0
Fragment 0 Excessive Collision 0
Jabber 37027 Single Collision 0
Drop Pkts 88447415 Collision 0
Symbol Error 37041

Через пару секунд:

show error ports 26
Port Number : 26
RX Frames TX Frames
--------- ---------
CRC Error 7 Excessive Deferral 0
Undersize 0 CRC Error 0
Oversize 24 Late Collision 0
Fragment 0 Excessive Collision 0
Jabber 37027 Single Collision 0
Drop Pkts 88448466 Collision 0
Symbol Error 37041

Видно что растут Drop Pkts из-за чего это может быть, куда копать?
Из-за этого много потерь пакетов до самого коммутатора.

И второй вопрос:
Как нибудь можно отслеживать флаппинг мак-адресов между портами на коммутаторе DES-3528?
Чтобы флаппинг например писался в логи, как на cisco catalyst`ах, ну или что нибудь подобное.
Спасибо.

1) на обоих линках к РРЛ попробуйте включить flow control
2) ena loopdetect
conf loop ports all sta ena
config loopdetect trap both
config loopdetect log state enable

Спасибо за попытку помочь.
Включил flowcontrol на обоих портах коммутаторов смотрящих на ррл. Ситуация не изменилась. Я думаю flowcontrol тут работать не будет, нужно чтобы сами РРЛ его умели, но они этого не могут, слишком "плюшевые" ((.
Загрузка на аплинке DES-3528 небольшая, там не больше 120Мбит/с в его сторону, обратно не более 50мбит/с. Маловероятно, что где то там перегрузки возникают, что нужно вмешиваться в контроль передачи пакетов.
Посмотрел в FAQ`е на сайте d-link, там называет несколько причин почему могут расти drop packets:
1) Input buffer full - переполнение входного буфера на порту.
2) Packets denied by ACL - пакеты отброшенные ACL.
3) VLAN ingress checking - проверка по VLAN на входе

На nag.ru ещё больший список привели:
1). ingress back pressure, flow control, rate limitation
2). port is not in forwarding state
3). dropped by ACL
4). dropped because there are no destination ports for the packets
5). dropped because it is set to blocked in FDB
6). packet exceeds MAX MTU
7). packet buffer full

ACL точно нет у меня никаких.
Порт 26 у меня в режиме vlan_trunk, по идее не должен браковать вланы, которых нет на коммутаторе. Да и на порту коммутатора перед РРЛ список вланов ограничен.
По поводу ingress checking, как посмотреть включен он или нет на порту 26? В конфиге нашёл только строчку:
config port_vlan 1-28 gvrp_state disable ingress_checking enable acceptable_frame admit_all pvid 1
оно ни оно?

По второму пункту. Я сейчас пробовал вот такую конфигурацию повесить, для отслеживания петель в неуправляемом сегменте на 6-м порту:

# LOOP_DETECT
enable loopdetect
config loopdetect ports 6 state enable
config loopdetect ports 1-5,7-28 state disable
config loopdetect recover_timer 300 interval 60 mode vlan-based
config loopdetect trap none
config loopdetect log state enable

Почему то не работает, в untagged влане взглючело устройство и оттуда стал приходить мак роутера временами, переписывался в таблице мак-порт (default влана). Переписывалось на всех коммутаторах до роутера. Одна из причин потерь пакетов.

config loopdetect trap both - команда заставит коммутатор вести лог лупдетектов на самом коммутаторе или всё же это snmp-trap для отправки на удалённое устройство?

Обновили недавно вышедшее ПО на РРЛ, появилась функция flowcontrol на ethernet`е. Включили.