Статья, которую вы сейчас читаете, является расширением статьи "Настройка свитчей уровня доступа в сети провайдера". Я обосную правильность подхода автора скринами и своими наблюдениями. Итак, фото испытуемого.
Все как в фильме ДМБ, сюжет про суслика: я тоже не вижу кабелей, а линки есть. Настройки у коммутатора сброшены к заводским командой #reset system.
Для наглядности еще несколько скриншотов:
Линки поднялись, коммутатор работает, но чем он занят нам подскажет wireshark и видим удивительную картину:
Представленный скриншот показывает большое количество ARP пакетов, которые генерирует сам коммутатор, предположительно в результате активности вышедших из строя портов. На основании этого включаем функцию Loop Detection, функция предназначается для формирования дерева коммутаторов, используя протокол STP, но работает и при выключенном STP:
enable loopdetect
config loopdetect mode vlan-based
config loopdetect recover_timer 1800
config loopdetect interval 10
config loopdetect ports 1-9 state enable
Вот как изменилась ситуация:
После применения настройки Loop Detection в логи коммутатора вносится запись об обнаруженном кольце на неисправном порту, сам порт переходит в режим err-disabled, что видно на приложенных выше скриншотах (mode vlan-based позволяет настраивать обнаружение кольца на транковых портах, в результате чего будет блокироваться только трафик из того vlan, в котором обнаружено кольцо, при этом остальные vlan будут работать в штатном режиме).
Изменился также тип трафика, пойманый wereshark. Теперь мы наблюдаем большое количество запросов dhcp (на подключенном компьютере настройка автоматического получения IP адреса).
Из этого следует, что ситуация с broadcast трафиком не изменилась. Это пагубно влияет на функционирование сети, так Broadcast пакеты клонируются коммутаторами, и это приводит к такому явлению как броадкаст-шторм. На основании этого принято решение ограничить количество broadcast тарфика посредством команды (если количество пакетов превысило уровень, то пакеты отбрасываются):
config traffic control 1-9 broadcast enable action drop threshold 64 countdown 5 time_interval 30
Кроме того запретим коммутатору пропускать ответы на DHCP запрос со всех портов кроме Uplink. Помимо ограничения трафика мы получаем возможность блокировать абонентские dhcp-server Пример конфигурации через CLI — настройка ACL, который разрешает передавать ответы DHCP с порта 10 и запрещает со всех остальных портов:
create access_profile ip udp src_port_mask 0xFFFF profile_id 1
config access_profile profile_id 1 add access_id 1 ip udp src_port 67 port 10 permit
config access_profile profile_id 1 add access_id 2 ip udp src_port 67 port 1-9 deny
Для чего это всё затевалось, и что получили в результате
Итак, после конфигурации мы имеем нормальный трафик на рабочем порту, малые всплески broadcast-трафика, так как вышедшие из строя порты периодически включаются по таймауту. Кроме того, в логах получаем строку вида «Port 1 VID 156 LBD recovered. Loop detection restarted», а при необходимости trap на сервер мониторинга.
Все усилия позволят методично работать над ликвидацией последствий грозы в условиях сети города (замены коммутаторов). Как показала практика (больше 5 лет в операторе связи на должности администратора сети) Dlink DES3200-series очень любит грозы.
Спасибо за потраченное время на прочтение. Отдельное спасибо коллегам за Ваши комментарии и рекомендации, а так же интерес к данному исследованию.
P.S.
Цикл статей Конструктивная админская лень или как я конфиг автоматизировал целью которого является снижение нагрузки на всеми любимых компьютерщиков на должности администратор сети.