[rm_]

23 minutes ago, darkagent said:

приводит или к administrative down или к suspend для "меньшинства". 

Вообще изчезла насовсем из настроек, будто бы никто и не создавал такую никогда.

[alibek]

1 час назад, darkagent сказал:

чего вдруг?!

Возможно и ошибаюсь.

Различные снупинги точно работают через CPU и от флуда не спасают, поэтому их использовать для фильтрации мало смысла.

[semop]

@Butch3r Я думаю это уже ближе к квалити оф доступ, просто как понятие качества.

В принципе можно на ближайшей агрегации это рубить.

Петли и шторма тоже бывали, но дальше порта агрегации не разлеталось. И LACP не разваливались. Читаю вот и настораживаюсь от прочитанного поведения агрегированых каналов.

Если "удаленные" петли/шторма умеют обваливать LACP/eth-channel, то это кошмар какой то. Я не знал и не сталкивался, если честно.

 

Включено все что можно: loop/traffic-control/stp disable/ddos

Вот и думаю теперь, что этого может быть недостаточно

[alibek]

ИМХО нет универсальной защиты от флуда, всегда можно словить такой, от которого конкретному коммутатору поплохеет.

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

[Butch3r]

5 минут назад, semop сказал:

@Butch3r Я думаю это уже ближе к квалити оф доступ, просто как понятие качества.

В принципе можно на ближайшей агрегации это рубить.

Петли и шторма тоже бывали, но дальше порта агрегации не разлеталось. И LACP не разваливались. Читаю вот и настораживаюсь от прочитанного поведения агрегированых каналов.

Если "удаленные" петли/шторма умеют обваливать LACP/eth-channel, то это кошмар какой то. Я не знал и не сталкивался, если честно.

 

Включено все что можно: loop/traffic-control/stp disable/ddos

Вот и думаю теперь, что этого может быть недостаточно

А вот кстати ddos мы выключили в итоге, от него больше проблем, чем пользы в ISP.

 

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

 

13 минут назад, alibek сказал:

ИМХО нет универсальной защиты от флуда, всегда можно словить такой, от которого конкретному коммутатору поплохеет.

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

да, и чтоб он ещё софтовым небыл

[vurd]

1 час назад, Butch3r сказал:

А вот кстати ddos мы выключили в итоге, от него больше проблем, чем пользы в ISP.

dos_prevention на длинках?

Эта та еще дрянь. Мне оно однажды порезало фрагментированые пакеты от юрика, тоже был рад до усрачки. Тоже выключил.

[semop]

DGS-3120-24SC:admin#sh log
Command: show log

Index Date       Time     Level   Log Text
----- ---------- -------- ------- ---------------------------------------------- 
60315 2019-04-03 14:37:15 INFO(6) Successful login through Telnet from 10.240.1.
                                  105 authenticated by AAA local method (Usernam
                                  e: root)
60314 2019-04-03 09:04:13 INFO(6) Blat Attack is blocked from (IP: 37.215.44.42 
                                  Port: 1:24)
60313 2019-04-03 08:00:57 INFO(6) Blat Attack is blocked from (IP: 88.202.190.144 
                                  Port: 1:24)
60312 2019-04-02 20:33:05 INFO(6) Blat Attack is blocked from (IP: 88.202.190.137 
                                  Port: 1:24)
60311 2019-04-02 20:02:38 INFO(6) Unit 1, Configuration successfully uploaded by
                                   SNMP (Username: Anonymous, IP: 172.20.74.9, M
                                  AC: 00-00-00-00-00-00)

DGS-3120-24SC:admin#show dos_prevention   
Command: show dos_prevention

Trap:Disabled   Log:Enabled     Function Version  : 1.01

DoS Type                    State     Action            Frame Counts
--------------------------  --------  ----------------  ------------
Land Attack                 Enabled   Drop              -           
Blat Attack                 Enabled   Drop              -           
TCP Null Scan               Enabled   Drop              -           
TCP Xmas Scan               Enabled   Drop              -           
TCP SYNFIN                  Enabled   Drop              -           
TCP SYN SrcPort Less 1024   Disabled  Drop              -           
Ping of Death Attack        Disabled  Drop              -           
TCP Tiny Fragment Attack    Enabled   Drop              -           
 

 

Ping of Death Attack - 1500 байт гасит. Его я тоже отключил)

TCP SYN SrcPort Less 1024 - какой то сервер просил, пришлось тоже отключить.

Остальное ON.

На проц вроде не давит.

 

 

На хуавэе до кучи тоже заколотил.

Когда было свободное время сидел на стенде шторма устраивал и смотрел какие флаги работают у них.

Получились такие комбинации:

 

###BLAT ATTACK
deny tcp any any rst 1 syn 1 

###TCP_SYNFIN
rule 0 deny tcp ack 1 fin 1 psh 1 rst 1 syn 1 urg 1
rule 1 deny tcp rst 1 syn 1 fin 1
rule 2 deny tcp rst 1 syn 1 fin 1 ack 1
rule 3 deny tcp syn 1 fin 1
rule 4 deny tcp syn 1 fin 1 ack 1
rule 5 deny tcp syn 1 rst 1

 

Потом мне надоело. Их наверно очень дофига.

Причем так и осталось загадкой, какой именно вариант блокировки использует Д-линк, конкретно по SYNFIN флагам. Может быть один какой то, а может 20 их там. Не знаю.

 

Простите за оффтоп.

[EvgeniySerb]

14 hours ago, semop said:

@Butch3r Я думаю это уже ближе к квалити оф доступ, просто как понятие качества.

В принципе можно на ближайшей агрегации это рубить.

Петли и шторма тоже бывали, но дальше порта агрегации не разлеталось. И LACP не разваливались. Читаю вот и настораживаюсь от прочитанного поведения агрегированых каналов.

Если "удаленные" петли/шторма умеют обваливать LACP/eth-channel, то это кошмар какой то. Я не знал и не сталкивался, если честно.

 

Включено все что можно: loop/traffic-control/stp disable/ddos

Вот и думаю теперь, что этого может быть недостаточно

Они обваливают не LACP а весь control plane 

 

17 hours ago, vurd said:

Задался вопросом переключения своих роутеров на палочке с mode active на mode on, ибо словил тут одну проблемку с экстримом - свитч заглянул в транзитный влан, увидел в нем lacpbdpu и грохнул свой lag, сквозь который этот влан и был проброшен. Экстрим починить не получится никак, он уже eol, прошивки не лезут, да и саппорта нет на него. А вот убрать lacp и собрать каналы статически можно.

Возникает вопрос, что такого может случится неприятного в mode on? По идеи, если порт физически погаснет, то из агрегированной группы он исчезнет. Зачем нужен контрольный протокол? Он может помочь убрать порт из канала, только при односторонней деградации, когда не увидит соседа по rx, но эта ситуация настолько маловероятна, особенно в пределах стойки, что можно ей принебречь.

 

Кто-нибудь знает возможные проблемы от mode on?

В lacp  Bpdu frame передаётся много информации о пире, чем достигается 100% исключение проблем связанных с неправильным кабелированием , особенно актуально при подстроение mlag и когда нет физического доступа к оборудованию . “Неправильный» Статический port channel соберётся а с LACP  порт уйдёт в Suspended state. Также наличие lacp помогает выявить проблемы с каналом если состояние порта не изменно , ака bfd, но об этом  уже писали. Недостатки - это ещё один control plane протокол , с багами , нагрузкой на cpu и тп 

Изменено 4 апреля, 2019 пользователем EvgeniySerb

[Ser]

Ну как вариант чем плох mode on

К примеру используются двухволоконные модули sfp, если одно волокно оборвется, то упадет порт только с одной стороны, а другая сторона продолжит слать пакеты в этот порт.

Тоже самое касается неисправных медных патчкордов.

Изменено 4 апреля, 2019 пользователем Ser

[alibek]

17 минут назад, Ser сказал:

К примеру используются двухволоконные модули sfp, если одно волокно оборвется, то упадет порт только с одной стороны, а другая сторона продолжит слать пакеты в этот порт.

Да, такие риски есть.

Но все же в норме такого не должно быть, это авария, которая проявит себя сразу и которую легко диагностировать.

[GrandPr1de]

В 03.04.2019 в 12:38, darkagent сказал:

в стандартной реализации практически любого вендора, мисматч портовых скоростей приводит или к administrative down или к suspend для "меньшинства". 

МХ умеет балансировку по портам с разной скоростью