Перейти до

Допоможіть порадами.


Рекомендованные сообщения

Доброго дня.

 

В ядрі zyxel-4012F. На мртж перший графік це вхід зі світу. Далі порти свіча. Неподобається на першому порті драбина з піків. При чому цікаво, що та частина мережі, що приходить на цей порт в юзерів проблем немає, не жаліються. А з інших портів жаліються на пропадання нету. vpn зєднання в клієнтів залишається на звязку, а інтернет перестає бігати до переконекта. 

 

post-16327-0-18917200-1360175454_thumb.jpg

Ссылка на сообщение
Поделиться на других сайтах

а почему сразу виноват свитч?

может виновата та железка которая терминирует тоннели

 

p/s может еще одна жертва "чудо роутеров" тенда?)

Відредаговано zulu_Radist
Ссылка на сообщение
Поделиться на других сайтах

а почему сразу виноват свитч?

может виновата та железка которая терминирует тоннели

 

p/s может еще одна жертва "чудо роутеров" тенда?)

@p/s может еще одна жертва "чудо роутеров" тенда?)@ абсолютно не зрозумів про що мова

якби залізяка то то кругом були б проблеми - а є лиш на окремих

Ссылка на сообщение
Поделиться на других сайтах

А вы точно уверены что на порту #1 нет проблем со связью? Судя по графику - явно выраженные обрывы на этом сегменте по 10-30 минут, причем вечерний час пик!

После 1-го порта стоит свитч, который трафик от клиентов фильтрует от разного рода вирусов и мусора?

 

А вообще, что за свитч стоит за портом #1 и какую функцию выполняет?

 

P.S. Данные в MRTG Graphs у вас рисуются справа на лево :) Первый раз такое вижу (графики панели задач из винды не в счет).

Ссылка на сообщение
Поделиться на других сайтах

1. похожая проблема обсуждалась http://local.com.ua/forum/topic/43780-странное-поведение-в-сети-петля/unread/

2. у zyxel gs4012F весьма специфическое поведение, при переходе из up в down порта по snmp начинают отдаваться 0 по всем счетчикам порта, а при обратном переходе из down в up возвращаются старые значения, т.е. мониторилка получила например значение 300, потом порт ушел в down, и мониторилка получила 0, прикинула, что наверное счетчик переполнился и благополучно нарисовала соотв. "писюн" на графике.

3. Какие вы считываете счетчики? 32 бита или 64??? если 32 - то это 4Г максимум, т.к. mrtg обычно считывает с периодом в 5 минут - то 4Г*8/300 примерно 110М, т.е если у вас скорости более 110М, то 32б счетчики не дадут сколь-нибудь нормального представления о реальных показателях...

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

А вы точно уверены что на порту #1 нет проблем со связью? Судя по графику - явно выраженные обрывы на этом сегменте по 10-30 минут, причем вечерний час пик!

После 1-го порта стоит свитч, который трафик от клиентов фильтрует от разного рода вирусов и мусора?

 

А вообще, что за свитч стоит за портом #1 и какую функцию выполняет?

 

P.S. Данные в MRTG Graphs у вас рисуются справа на лево :) Первый раз такое вижу (графики панели задач из винды не в счет).

Порт 1 волокно до Zyxel моделі не памятаю L2 , netbios порізаний. На всіх інших портах перші свічі теж Zyxel різні. Доречі, що помітили при включеному flow-control зі сторони ядра й перших свічів навантаження на zyxel 4012f 20-25%. Час від часу піково навантаження піднімалось до 100% коли й починали втрачатись vpn зєднання та ріс час пінгів в мережі. При відключеному flow-control навантаження на zyxel 4012f 80-96% зате стало не обривати vpn. Відредаговано karonetua
Ссылка на сообщение
Поделиться на других сайтах

1. похожая проблема обсуждалась http://local.com.ua/forum/topic/43780-странное-поведение-в-сети-петля/unread/

2. у zyxel gs4012F весьма специфическое поведение, при переходе из up в down порта по snmp начинают отдаваться 0 по всем счетчикам порта, а при обратном переходе из down в up возвращаются старые значения, т.е. мониторилка получила например значение 300, потом порт ушел в down, и мониторилка получила 0, прикинула, что наверное счетчик переполнился и благополучно нарисовала соотв. "писюн" на графике.

3. Какие вы считываете счетчики? 32 бита или 64??? если 32 - то это 4Г максимум, т.к. mrtg обычно считывает с периодом в 5 минут - то 4Г*8/300 примерно 110М, т.е если у вас скорости более 110М, то 32б счетчики не дадут сколь-нибудь нормального представления о реальных показателях...

Ну з першого графіка видно там навантаження 700Мб

власне ту вітку читав неодноразово дякую.

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

Як на мене також - нормальний графік, нічого там критичного немає.

Погано що vpn пропадало пару раз на годину до вимкнення flow-control. Погано що свіч тепер на 80-96% зайнятий після вимкнення flow-control. Хотілось би якось до нормального режиму роботи повернутись.

Ссылка на сообщение
Поделиться на других сайтах

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

Затиків стараємся на вихід не роботи в запасі завжди є якихось 100Мб.

Не графік мене смущає а проблеми в юзерів, де краще зняти tcpdamp чи щось подібне щоб пошукати глибше.

Ссылка на сообщение
Поделиться на других сайтах

 

Як на мене також - нормальний графік, нічого там критичного немає.

Погано що vpn пропадало пару раз на годину до вимкнення flow-control. Погано що свіч тепер на 80-96% зайнятий після вимкнення flow-control. Хотілось би якось до нормального режиму роботи повернутись.

 

Ethernet flow control is a mechanism for temporarily stopping the transmission of data on Ethernet family computer networks.

 

 

For example, a flow can come into a switch on a higher speed link than the one it goes out, or several flows can come in over two or more links that total more than an output link's bandwidth. These will eventually exhaust any amount of buffering in the switch. However, blocking the sending link will cause all flows over that link to be delayed, even those that are not causing any congestion. This situation is a case of head-of-line blocking, and can happen more often in core network switches due to the large numbers of flows generally being aggregated.

 

И на что жалуемся??? сами включили..

Відредаговано greyshadow
Ссылка на сообщение
Поделиться на других сайтах

или на русском

Функция управления потоком (Flow Control) используется для
регулирования передачи сигналов в зависимости от пропускной способности
принимающего порта. Дело втом, что концентрация трафика на порту
вызывает падение пропускной способности и перегружает буферную память,
из-за чего происходит отбрасывание пакетов и потеря кадров.
Ethernet-коммутатор
использует управление потоком по стандарту IEEE802.3x в дуплексном
режиме (full duplex) и управление потоком методом обратного давления
(противодавления) в полудуплексном режиме (half duplex).
Управление
потоком по стандарту IEEE802.3x в дуплексном режиме подразумевает
отправку сигнала паузы на передающий порт, что позволяет приостановить
передачу при переполнении буфера принимающего порта.
Управление
потоком методом обратного давления (Back pressure) обычно применяется в
полудуплексном режиме и предполагает отправку на передающий порт сигнала
коллизии (имитацию состояния коллизии), из-за чего передающий порт на
некоторое время приостанавливает передачу.

Ссылка на сообщение
Поделиться на других сайтах

или на русском

Функция управления потоком (Flow Control) используется для

регулирования передачи сигналов в зависимости от пропускной способности

принимающего порта. Дело втом, что концентрация трафика на порту

вызывает падение пропускной способности и перегружает буферную память,

из-за чего происходит отбрасывание пакетов и потеря кадров.

Ethernet-коммутатор

использует управление потоком по стандарту IEEE802.3x в дуплексном

режиме (full duplex) и управление потоком методом обратного давления

(противодавления) в полудуплексном режиме (half duplex).

Управление

потоком по стандарту IEEE802.3x в дуплексном режиме подразумевает

отправку сигнала паузы на передающий порт, что позволяет приостановить

передачу при переполнении буфера принимающего порта.

Управление

потоком методом обратного давления (Back pressure) обычно применяется в

полудуплексном режиме и предполагает отправку на передающий порт сигнала

коллизии (имитацию состояния коллизии), из-за чего передающий порт на

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

Так праоблема не решилась ни с включеным ни с выключеным Flow Control до конца.

Ссылка на сообщение
Поделиться на других сайтах

Flow иногда нужен на клиентских портах(если там жесткий полисер стоит к примеру - с flow картинка по трафику значительно лучше). Между серверами или свичами он ни на что не влияет и смысла не имеет.

Ссылка на сообщение
Поделиться на других сайтах

Flow иногда нужен на клиентских портах(если там жесткий полисер стоит к примеру - с flow картинка по трафику значительно лучше). Между серверами или свичами он ни на что не влияет и смысла не имеет.

Якщо немає сенсу між свічами чому навантаження на core zyxel 4012f 80-96% при відключеному й 20-25% при включеному.

Ссылка на сообщение
Поделиться на других сайтах

А это вопрос к разрабам...

Кстати вполне может оказаться, что виновен с сем не столько зюх, сколько свич за ним, т.к. насколько вижу главные обрывы при росте out трафика.

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

А это вопрос к разрабам...

Кстати вполне может оказаться, что виновен с сем не столько зюх, сколько свич за ним, т.к. насколько вижу главные обрывы при росте out трафика.

Дякую й на тому ... будем шукати.

Пробували штучно створити потік 100мб між різними портами, між різними частинами міста btest на core свіча навантаження ставало в 100% при включеному Flow Control з 20-25% які були звичайно (vpn рвались). Та залишались майже без змін при виключеному Flow Control 80-96% (vpn зєднання не рвалось).

Якісь поради крім звернення до розробника ще будуть? ))

Відредаговано karonetua
Ссылка на сообщение
Поделиться на других сайтах

 

Якісь поради крім звернення до розробника ще будуть? ))

Я не зря спросил про свитчи, которые идут после core-коммутатора.

Нагрузка проца на центральном свитче может вырасти из-за флуда, который идет со стороны агрегации клиентов или из-за роста количества МАС-адресов.

В любом случае, на агрегации надо трафик максимально очистить, если на домах не стоит управляемое оборудование. Если я правильно понял, вы только netbios зарезали. А кроме него есть еще много чего, что надо резать.

Ссылка на сообщение
Поделиться на других сайтах

И забыл самое главное написать.
Чтобы вам быстрее могли помочь найти проблему, надо сперва понять на каком участке проблема происходит.
И первое, что я рекомендую проверить - это найти участок/точку где возникают проблемы с передачей пакетов.
Поэтому подтвердите, что на проблемном сегменте у клиентов у которых рвется VPN, нет потерь до:
1) Домового коммутатора
2) Узла агрегации домовых коммутаторов
3) Центрального коммутатора.
4) Центального маршрутизатора

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

 

 

Якісь поради крім звернення до розробника ще будуть? ))

Я не зря спросил про свитчи, которые идут после core-коммутатора.

Нагрузка проца на центральном свитче может вырасти из-за флуда, который идет со стороны агрегации клиентов или из-за роста количества МАС-адресов.

В любом случае, на агрегации надо трафик максимально очистить, если на домах не стоит управляемое оборудование. Если я правильно понял, вы только netbios зарезали. А кроме него есть еще много чего, что надо резать.

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

Відредаговано karonetua
Ссылка на сообщение
Поделиться на других сайтах

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

Политика правил в каждой сети своя, но есть достаточно распространенные правила (ACL правила на основе оборудования D-Link):

 

#1 DHCP ответы запрещены на всех юзерских портах (1-23), кроме uplink порта №24

create access_profile profile_id 1 ip udp src_port_mask ffff 
config access_profile profile_id 1 add access_id auto_assign ip udp src_port 67 port 1:1-23 deny

 

#2 Запрещаем arp подмену 
create access_profile profile_id 2 ethernet source_mac FF-FF-FF-FF-FF-FF 
config access_profile profile_id 2 add access_id auto_assign ethernet source_mac 00-00-00-00-00-00 port 1:1-24 deny
 

#3 Запрещенные dst TCP порты: 

 #69 tcp/udp - защита абонентских роутеров (протокол TFTP)
 #135 tcp/udp (epmap) - защита против уязвимостей в Microsoft Windows 
 #136 tcp/udp (profile) - защита против уязвимостей в Microsoft Windows 
 #137 tcp/udp (netbios-ns) - защита против уязвимостей в Microsoft Windows 
 #138 tcp/udp (netbios-dgm) - защита против уязвимостей в Microsoft Windows 
 #139 tcp/udp (netbios-ssn) - защита против уязвимостей в Microsoft Windows 
 #445 tcp (microsoft-ds) - защита против уязвимостей в Microsoft Windows 
 #901 tcp (SWAT) - чтобы не было доступа к настройкам самбы через web. 
 #1022 и 1023 - червь Jobaka (Sasser)
 #2869 - UPNP Universal Plug and Play Device Host
 #3332 tcp/udp - троянская программа. 
 #5554 и 9996 - Защита против вирусов "Lovsan", "Blaster", "Msblast", "Poza".
   create access_profile profile_id 3 ip tcp dst_port_mask ffff 
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 69 port 1-23 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 135 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 136 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 137 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 138 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 139 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 445 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 1022 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 1023 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 2869 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 3332 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 5554 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 9996 port 1-24 deny
 
#4 Запрещенные dst UDP порты:
 #69 tcp/udp - защита абонентских роутеров (протокол TFTP)
 #135 tcp/udp (epmap) - защита против уязвимостей в Microsoft Windows 
 #136 tcp/udp (profile) - защита против уязвимостей в Microsoft Windows 
 #137 tcp/udp (netbios-ns) - защита против уязвимостей в Microsoft Windows 
 #138 tcp/udp (netbios-dgm) - защита против уязвимостей в Microsoft Windows 
 #139 tcp/udp (netbios-ssn) - защита против уязвимостей в Microsoft Windows 
 #1900 udp (SSDP SSDP Discovery Service) - Самый простой способ получения несанкционированного доступа к компьютеру! 
 #3332 tcp/udp - троянская программа. 
 #5554 и 9996 - Защита против вирусов "Lovsan", "Blaster", "Msblast", "Poza".
   create access_profile profile_id 4 ip udp dst_port_mask ffff 
   config access_profile profile_id 4 add access_id auto_assign ip udp dst_port 69 port 1-23 deny
   config access_profile profile_id 4 add access_id auto_assign ip udp dst_port 135 port 1-24 deny
   config access_profile profile_id 4 add access_id auto_assign ip udp dst_port 136 port 1-24 deny
   config access_profile profile_id 4 add access_id auto_assign ip udp dst_port 137 port 1-24 deny
   config access_profile profile_id 4 add access_id auto_assign ip udp dst_port 138 port 1-24 deny
   config access_profile profile_id 4 add access_id auto_assign ip udp dst_port 139 port 1-24 deny
   config access_profile profile_id 4 add access_id auto_assign ip udp dst_port 1900 port 1-24 deny
   config access_profile profile_id 4 add access_id auto_assign ip udp dst_port 3332 port 1-24 deny
   config access_profile profile_id 4 add access_id auto_assign ip udp dst_port 5554 port 1-24 deny
   config access_profile profile_id 4 add access_id auto_assign ip udp dst_port 9996 port 1-24 deny

P.S. Сорри если криво текст вышел, просто у меня в Chrome до сих пор не работает полноценно меню ответов после внесения Фостером изменений в движок форума: теги вообще не отображаются и приходится "в слепую" тест подгонять.

Відредаговано mace
Ссылка на сообщение
Поделиться на других сайтах

 

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

Политика правил в каждой сети своя, но есть достаточно распространенные правила (ACL правила на основе оборудования D-Link):

 

#1 DHCP ответы запрещены на всех юзерских портах (1-23), кроме uplink порта №24

create access_profile profile_id 1 ip udp src_port_mask ffff 
config access_profile profile_id 1 add access_id auto_assign ip udp src_port 67 port 1:1-23 deny

 

#2 Запрещаем arp подмену 
create access_profile profile_id 2 ethernet source_mac FF-FF-FF-FF-FF-FF 
config access_profile profile_id 2 add access_id auto_assign ethernet source_mac 00-00-00-00-00-00 port 1:1-24 deny
 

#3 Запрещенные dst TCP порты: 

 #69 tcp/udp - защита абонентских роутеров (протокол TFTP)
 #135 tcp/udp (epmap) - защита против уязвимостей в Microsoft Windows 
 #136 tcp/udp (profile) - защита против уязвимостей в Microsoft Windows 
 #137 tcp/udp (netbios-ns) - защита против уязвимостей в Microsoft Windows 
 #138 tcp/udp (netbios-dgm) - защита против уязвимостей в Microsoft Windows 
 #139 tcp/udp (netbios-ssn) - защита против уязвимостей в Microsoft Windows 
 #445 tcp (microsoft-ds) - защита против уязвимостей в Microsoft Windows 
 #901 tcp (SWAT) - чтобы не было доступа к настройкам самбы через web. 
 #1022 и 1023 - червь Jobaka (Sasser)
 #2869 - UPNP Universal Plug and Play Device Host
 #3332 tcp/udp - троянская программа. 
 #5554 и 9996 - Защита против вирусов "Lovsan", "Blaster", "Msblast", "Poza".
   create access_profile profile_id 3 ip tcp dst_port_mask ffff 
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 69 port 1-23 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 135 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 136 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 137 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 138 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 139 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 445 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 1022 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 1023 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 2869 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 3332 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 5554 port 1-24 deny
   config access_profile profile_id 3 add access_id auto_assign ip tcp dst_port 9996 port 1-24 deny
 
#4 Запрещенные dst UDP порты:
 #69 tcp/udp - защита абонентских роутеров (протокол TFTP)
 #135 tcp/udp (epmap) - защита против уязвимостей в Microsoft Windows 
 #136 tcp/udp (profile) - защита против уязвимостей в Microsoft Windows 
 #137 tcp/udp (netbios-ns) - защита против уязвимостей в Microsoft Windows 
 #138 tcp/udp (netbios-dgm) - защита против уязвимостей в Microsoft Windows 
 #139 tcp/udp (netbios-ssn) - защита против уязвимостей в Microsoft Windows 
 #1900 udp (SSDP SSDP Discovery Service) - Самый простой способ получения несанкционированного доступа к компьютеру! 
 #3332 tcp/udp - троянская программа. 
 #5554 и 9996 - Защита против вирусов "Lovsan", "Blaster", "Msblast", "Poza".
   create access_profile profile_id 4 ip udp dst_port_mask ffff 
   config access_profile profile_id 4 add access_id auto_assign ip udp dst_port 69 port 1-23 deny
   config access_profile profile_id 4 add access_id auto_assign ip udp dst_port 135 port 1-24 deny
   config access_profile profile_id 4 add access_id auto_assign ip udp dst_port 136 port 1-24 deny
   config access_profile profile_id 4 add access_id auto_assign ip udp dst_port 137 port 1-24 deny
   config access_profile profile_id 4 add access_id auto_assign ip udp dst_port 138 port 1-24 deny
   config access_profile profile_id 4 add access_id auto_assign ip udp dst_port 139 port 1-24 deny
   config access_profile profile_id 4 add access_id auto_assign ip udp dst_port 1900 port 1-24 deny
   config access_profile profile_id 4 add access_id auto_assign ip udp dst_port 3332 port 1-24 deny
   config access_profile profile_id 4 add access_id auto_assign ip udp dst_port 5554 port 1-24 deny
   config access_profile profile_id 4 add access_id auto_assign ip udp dst_port 9996 port 1-24 deny

P.S. Сорри если криво текст вышел, просто у меня в Chrome до сих пор не работает полноценно меню ответов после внесения Фостером изменений в движок форума: теги вообще не отображаются и приходится "в слепую" тест подгонять.

Дякую все читабильне.

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від scaran
      Обращаюсь за помощью к коллективному разуму.
      Попалась сеть в условное обслуживание. В ней есть проблема в рандомный период времени - не важно  хоть в час пик, хоть ночью, хоть раз неделю, но может и  пару раз за день происходит следюущие: перестают быть доступны все шлюзы абонентов с реальными IP (соответсвтенно и все абоненты  по всех 9 сетках /24). Пинги проскакивают один из 20. Тоесть недоступость почти 100%. Прекращается все если не трогать максимум за 15 минут, но бывает и за минут 5 попустит. Ну или лечится ребутом одного агрегационного узла на 48 даунлинков (extreme x450a-24x, soft 15.3.5.2 patch1-12 + dgs-3120-24sc прошивка последняя). Все менеджмент сетки при этом живут (шлюзы менеджмента на другом сервере висят и  естественно в каждая в разных вланах). Бывает помогает потушить один из домов оптического свитча и шлюзы отпускает, но иногда тушение одного порта помогает, иногда другой, конкретно грешить на какой-то дом не могу. С этого агрегационного узла все даунлинки только на управляемые домовые свитчи, тупых линков нет, медных колбас тоже. Всего в сети 9 агрегационных узлов с 20-30 даунлинками в сторону домов. Все агрегационные узлы стекаются в ящик extreme bd 8810, с него линк на фрибсд сервак где и висят все шлюзы для абонентов. Схема чистая звезда, петли на аплинках исключены.
      Суммарно по сети примерно 150 управляемых коммутаторов, тупых линков  в виде медик+тупарь штук 30-40 (в основном где по 1-2 абонента, в дальнейшем и эти  точки заменятся на управляемые).
      На каждом агрегационном узле своя менеджмент сеть /24 и свой абонская сеть тоже /24 с реальниками. Адреса все статикой. Тоесть суммарно 9 менеджмент подсетей и 9 подсетей абонских  (конечно же разбито все на 9 вланов все и в менеджменте и отдельными 9 вланов в абонских сетках)
      Схема набросками следующая:


      Оптические коммутаторы на агрегациях следующие:
      Extreme x450a-24x, Dlink DGS-3120-24sc, Edge-Core ES4612, Dlink DGS-3612G, TP-Link TL-SG5412F
      Коммутаторы на домах таких моделей:
      Extreme summit x150, x250, x350, x450, 200-24, 200-48
      Dlink DES-3200-10/28
      Cisco WS-C2960-24TC-L, 8TC-L, WS-C2950, WS-C2940, WS-C3560/3750
      Huawei S2326TP-EI/S2309
      TP-Link TL-SL2210WEB
      В % соотношениях: экстримов 75%, хуавеев 10%, длинки 10%, циски 5%

      На всех экстримах  и длинках включен dos-protect. На всех свитчах включены шторм контроли, бродкаст/мультикаст контроли с огричением в 5% от пропускной спосбности порта, джамбофреймы везде отключены. dhcp snooping включены везде. loopdetect на всех абонских поратх включены. IGMP snooping тоже везде включен, но по нему я заметил, что когда на аксес свитчах чекаю igmp snooping querier , то querier-ом как правило выступают абоны, а это я так понимаю не есть хорошо и квериером должен быть онли шлюз. но вряд ли это ложит шлюзы. В логах свичтей и на графиках я не вижу ни всирания цпу ничего. Но заметил странную тенденцию - на аксес свитчах в момент начала вот такого флуда даунятся как правило линки на конце которых висят,  опростят меня боги - наши "любимые" тенды. Проблема не в них - я ради инетереса тушил вообще все порты с тендами (их суммарно по сети не более полутора десятка, флуд все равно происходил).
      Единственное что на свитчах не настроено это защита arp spoofing. Похоже ли это на бомбежку арпами от которых шлюзы с ума сходят? Понятно что правильнее будет зеркалить трафик на ящике  BD 8810 c порта уходящего на сервак freebsd с шлюзами абонентов (я так и планирую делать), но пока едет сборка на х99 китайце под тазик, то приходится только догадки догадывать. Ах да,  доступа на сервак с фрибсд у меня отсутствует, потому зайти на него и глянуть что у него в логах я не могу. Куда еще можно покопать?, у кого может мысля проявится, может что на аксесах подонастраивать, но я уже не представляю что.
    • Від Keen
      можно ли такое реализовать?
      К примеру, если топик "спам" или "откровенный флуд" в неверной рубрике?
    • Від adik_v
      Добрый вечер ! 
      Ситуация такова  в населенных пунктеах  запускают 4г  и время от времени в вечернее время с 21:00 до 23:00 ложаться радио каналы поочередно в разных направлениях SNR(dB) падает на линках до 0 Базовые станции находяться друг от друга до 10 км  направление линков разное смена частот и спектр анализатор нечего не показывает оборудование разное mimoza с5с b5c  mikrotik netmetal , cambium   - У кого- то такое было ? как с этим бороться ?
    • Від andr1y
      Останнім часом вже 6-й абонентський роутер Tenda починає глючити і флудити влан в якому він включений. Хтось з таким стикався ?
      Авторизація в нас по dhcp.
    • Від vit75
      Есть небольшая сетка. Часть по оптике, часть медь. Несколько управляемых коммутаторов, остальные нет. Сервер на Линукс. Изредка, иногда пару раз в день, иногда в час, появляется очевидно arp-флуд. Так как пинги между любыми компами идут с потерями 90%. Так 1-2 мин. Зайти на коммутатор отключить ветку тогда невозможно. Выключать часть сети и ждать пол дня не вариант. Какие есть способы вычислить? Возможно ли это увидеть по tcpdump на сервере?
       
      [root@]# /usr/sbin/tcpdump -n arp tcpdump: listening on eth0 13:20:08.314922 arp who-has 192.168.0.102 tell 192.168.7.101 13:20:08.365384 arp who-has 192.168.1.42 tell 192.168.7.101 13:20:08.443489 arp who-has 192.168.9.58 tell 192.168.0.1 13:20:08.443513 arp who-has 192.168.9.135 tell 192.168.9.1    
×
×
  • Створити нове...