Дослідження комутатора Dlink після грози

Стаття, яку ви зараз читаєте, є розширенням статті "Налаштування світчів рівня доступу до мережі провайдера". Я обосную правильність підходу автора скрінами і своїми спостереженнями. Отже, фото випробуваного.

image

Все як у фільмі ДМБ, сюжет про ховрашка: я теж не бачу кабелів, а є лінки. Налаштування комутатора скинуті до заводських командою #reset system.

Для наочності ще кілька скріншотів:

dlink_1

dlink_2

Лінки піднялися, комутатор працює, але чим він зайнятий нам підкаже wireshark і бачимо дивну картину:

wireshark_1

Представлений скріншот показує велику кількість ARP пакетів, які генерує сам комутатор, імовірно в результаті активності вийшли з ладу портів. На підставі цього включаємо функцію LoopDetected, функція призначається для формування дерева комутаторів, використовуючи протокол STP, але працює і при вимкненому STP:

enable loopdetect
 
config loopdetect mode vlan-basedconfig loopdetect recover_timer 1800
 
config loopdetect interval 10
 
config loopdetect ports 1-9 state enable
 

Ось як змінилася ситуація:

image

image

Після застосування налаштування loopdetected в логи комутатора вноситься запис про виявлений кільці на несправному порту, сам порт переходить в режим err-disabled, що видно на доданих вище скріншотах (mode vlan-based дозволяє налаштовувати виявлення кільця на транкових портах, в результаті чого буде блокуватися тільки трафік з того vlan, в якому виявлено кільце, при цьому інші vlan будуть працювати в штатному режимі).

Змінився також тип трафіку, пойманый wereshark. Тепер ми спостерігаємо велику кількість запитів dhcp (на приєднаному комп'ютері настроювання автоматичного отримання IP адреси).

image

З цього випливає, що ситуація з 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 24 permit
 
config access_profile profile_id 1 add access_id 2 ip, udp src_port 67 port 1-9 deny
 

image

image

Отже, після конфігурації ми маємо нормальний трафік на робочому порту, малі сплески broadcast-трафіку, так як вийшли з ладу порти періодично включаються по таймауту. Крім того, в логах отримуємо рядок виду «Port 1 VID 156 LBD відновлені. Loop detection restarted», а при необхідності trap на сервер моніторингу.

Всі зусилля дозволять методично працювати над ліквідацією наслідків грози в умовах мережі міста. Як показала практика (більше 5 років в операторі зв'язку на посаді адміністратора мережі) Dlink DES3200-series дуже любить грози.

Спасибі за витрачений час на прочитання.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.