наверняка наслышаны про нашу топологию .
Суть проблемы такова.

кольцо из des-3526 замыкается на CISCO 7609.

в кольце больше 20 свичей. Ну никак этого не избежать .
Там работает MSTP

Проблема номер 3 :
при установке ограничений на кол-во пакетов на порту непонятно как оно работает .
При любых раскладах выдает по счетчикам реально значение пакетов на порту . Несмотря на ограничение, только вот в одни моменты времени данный трафик выливается на магистральки , а в другие таки отсекается.

Как определить , можно ли делать какойто action shutdown
ножно ли слать в логах о возникновении прецендента .

Проблема номер 2 :

в последнее время появился весьма забавный вирус который очень красиво прикладывает сетку штормами разного рода.
Суть проблемы. В моменты шторма как и положено срабатвает safe guard нельзя ли сделать сейф гард таким образом чтобы всетаки доступность свича была. Даже в ущерб пользовательского трафика. Как пример в такие моменты оставлять по высшему приоритету management vlan и сервисы логирования, чтобы отсечь проблему.

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

Проблема номер 1 ( она же номер 0 ) :
Ну никак не можем победить MSTP постоянные заотичные перестройки колец. Я подозреваю что в моменты срабатывания safeguard теряются bpdu пакеты , и соседи думают что кольцо потеряло целостность . Перестроилось дерево . Свич попустило , он вернулся, опять перестроилось дерево и так постоянно .

Цыска при все своем масштабе нефигово приседает при перестройке колец, да и само кольцо в такие моменты теряется из виду.


Что делать ? как быть ?
Длинками пользуемся уже год . Никак не можем найти оптимальную схему при которой наша топология осталась работать и не падала .
з.ы. : Начинаем коситься на других производителей.

_________________
freenet

Вы не могли бы перезвонить в офис по телефону 744-00-99 доб.390.

Еще один момент

FW Build 5.01-B15

# LOOP_DETECT

enable loopdetect
config loopdetect recover_timer 60
config loopdetect interval 3
config loopdetect mode port-based
config loopdetect ports 1-8 state enabled
config loopdetect ports 9-26 state disabled



2210 00000 days 00:36:20 Port 5 link down
2209 00000 days 00:36:20 Port 2 link down
2208 00000 days 00:35:57 Possible spoofing attack from 00-19-5B-ED-8C-A1 port
2
2207 00000 days 00:35:57 Possible spoofing attack from 00-19-5B-ED-8C-A1 port
2
2206 00000 days 00:35:57 Possible spoofing attack from 00-19-5B-ED-8C-A1 port
2
2205 00000 days 00:35:57 Possible spoofing attack from 00-19-5B-ED-8C-A1 port
2
2204 00000 days 00:35:57 Possible spoofing attack from 00-19-5B-ED-8C-A1 port
5
2203 00000 days 00:35:57 Possible spoofing attack from 00-19-5B-ED-8C-A1 port
5
2202 00000 days 00:35:57 Possible spoofing attack from 00-19-5B-ED-8C-A1 port
5
2201 00000 days 00:35:57 Possible spoofing attack from 00-19-5B-ED-8C-A1 port
5
2200 00000 days 00:35:57 Possible spoofing attack from 00-19-5B-ED-8C-A1 port
2199 00000 days 00:35:57 Possible spoofing attack from 00-19-5B-ED-8C-A1 port
2
2198 00000 days 00:35:57 Possible spoofing attack from 00-19-5B-ED-8C-A1 port
2
2197 00000 days 00:35:57 Possible spoofing attack from 00-19-5B-ED-8C-A1 port
2
2196 00000 days 00:35:57 Possible spoofing attack from 00-19-5B-ED-8C-A1 port
2
2195 00000 days 00:35:57 Possible spoofing attack from 00-19-5B-ED-8C-A1 port
2
2194 00000 days 00:35:57 Possible spoofing attack from 00-19-5B-ED-8C-A1 port
5


Всунули кабель началось детектиться лупдетект .
Линк не ложится. Вверху логов видно , как мы сами выдернули кабель.

_________________
freenet

Укажите телефон в международном формате , буду из Киева звонить .
Или же скайп , или же по аське 73493998

_________________
freenet

+7(495)744-00-99 доб.390. Или если удобно укажите ваш телефон я перезвоню.

Буду писать сюда . о своих проблемах , дыбв все было в одном месте .

Из заявления сотрудника д-линк :

"Луп детект не сработает если один кабель воткнуть в оба порта длинка. Для таких случаев нужен СТП"

Сегодня сел и подумал , это ж что получается. На клиентских портах я отлючаю СТП дабы не мешали зверьки . И ставлю лупдетект .

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


-----


Дальше следующая проблема.

Никак не могу понять как работает traffic control взял поставил 1к пакетов на порту . Включаю нмап в жестком режиме, там в течении секунд 10-20 на порту висит порядка 3-4К пакетов.

И очень неприятен тот факт что для ЮНИКАСТА хоть он и не работает нет action drop.

Вот конфиг свича с новой прошивкой b16 в которой у меня такая картина Репина.

И кстати , было бы не плохо видеть что на порту превышен лимит , по СНМП или по логам.


# STORM

config traffic control_trap none
config traffic control 1-3 broadcast enable multicast enable unicast enable action drop threshold 1
config traffic control 4-5 broadcast disable multicast disable unicast disable
action drop threshold 128000

_________________
freenet

LBD бывает двух типов зависимый от STP и независимый. В первом случае отрабатывает эти ситуации но всё равно не он а протокол STP. А кажется что LBD так как они не могут включаться отдельно. Так как большинство клиентов выключает STP на клиентских портах то м сделали более продвинутый вариант LBD независимый от STP.

Если Вы хотите защититься от таких ситуаций то надо включить STP на клиентских портах, а защищаться от поддельных BPDU можно при помощи функций Restricted Role и Restricted TCN (стандартные аналоги Cisco Root Guard и Forwarding BPDU disabled). Также мы работаем надо новой функцией которая поволит отсекать любые BPDU сразу на клиентском порту (BPDU Restiction).

Такое действие невозможно для Unicast пакетов (причём это DLF пакеты) в аппаратной части в приниципе. При Action drop пока нет логирования но оно добавится в следующем релизе, который ожидается в марте.

А почему тогда не срабатывает ограничение в кол-во пакетов на порту ?
Ведь при скане нмапом одного хоста раотает железно режим юникаста .

_________________
freenet

Этот хост существует в сети?

разумеется . неясно только какое это имеет значение ведь трафик то всеравно улетел с порта в аплинк.

_________________
freenet

Этот тип Storm Control рубит только DLF пакеты а не любой Unicast.

А как мне сделать тогда просто ограничение просто pps на порту . И все независимо от типа трафика .

_________________
freenet

Это невозможно. Только рубить трафик при помощи ACL Flow Meter (трафик policing) с шагом 1 Мбит/с.

Все это конечно хорошо, но тем не менее решает не все возможные проблемы. Итак, имеем следующую конфигурацию:



При такой конфигурации отрабатываются петли д-линка на самого себя и между двумя д-линками. Но если взять тупой свич, сделать на нем петлю на самого себя, т.е. воткнуть патчкорд в два порта тупого свича, а из третьего порта этого тупого свича сделать аплинк другим патчкордом на отконфигуренный, как упомянуто выше д-линк, то у последнего благополучно отваливается менеджмент из-за перегрузки ЦПУ. При этом, надо отметить, что основная функциональность, т.е. коммутация пакетов, продолжает работать (при поверхностной проверке).

Вот собственно кусок лога после втыкания/выдергивания тупого свича с петлей.



Каким образом Вы бы порекомендовали побороть такую ситуацию?
Хотелось-бы все-таки не терять менеджмент д-линка.

P.S. Не уверен, что абсолютно точно понял смысл, заключенный в первом абзаце цитаты. Чувствуется недостаток связующих частей речи. Сами то хоть перечитывали перед тем как отпостить?

_________________
freenet.com.ua

А что непонятного в том что я написал? Я всегда перечитываю то что пощу. Просто писал быстро. Хотел сказать что хотя и STP LBD включён и кажется что он отрабатывает петли, по настоящему это делает просто STP.

При ваших настройках в режиме VLAN Based есть такой эффект, потому что именно в этом режиме устройство отбрасывает пакеты определённого VLAN-а средствами CPU. SafeGuard Engine должен частично помочь. Если переключить функцию в Port Based режим то такого эффекта уже не будет.