Flow control

[dandul 42]

Flow control на клиентских портах коммутатора, включать или не включать? Больше склонен к disable.

Flow control на агрегации домов используете?

[Losth 2]

Flow control на клиентских портах коммутатора, включать или не включать? Больше склонен к disable.

Flow control на агрегации домов используете?

google

[dandul 42]

Flow control на клиентских портах коммутатора, включать или не включать? Больше склонен к disable.

Flow control на агрегации домов используете?

google

Какой глубокий наполненный смыслом ответ? Сенкс.

[KaYot 3 707]

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

[Will 0]

Возможно глупый вопрос, но все же задам. В сети активно юзается локальный торрент трекер, юзеров 1 тысяча. К сожалению, заметил что, если включен flow контроль и кто-то активно качает с помощью uttorent, то пинг подымается очень сильно на этот порт(район). При выключеном flow контроле все стабильно намного стабильней.

 

Включать или не включать, вот в чем вопрос!

[KaYot 3 707]

А на 2см выше не судьба взглянуть?

[Will 0]

Упссс, как видите почти сразу после вас написал, а страничку долго не обновлял. Спасибо за ответ!

[dandul 42]

А на 2см выше не судьба взглянуть?

Это ж роллик на мышке нужно крутить. ))

Сенкс за вразумительный ответ.

[napTu 4]

Т.к. в частном секторе используются цепочки из неупраляемых свичей, а это периодически приводит к глюкам таких сегментов, то есть решение в выключении flowcontrol в неуправляемых свичах на чипсетах IC+ IP178(5)C,D.

Свичи на таких чипсетах давно зарекомендовали себя как независающие стабильные решения(в отличие от свичей на чипсетах realtek).

 

По даташиту на этот чипсет, функция flow control включена по умолчанию и выключается путем подачи низкого уровня на 75й пин.

Я предпочитаю сначала отдирать вывод от платы, а затем подпаивать на него проводок в минус.

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

 

ic178d используются в canyon, nxt sw-08, tenda s108...

[rsst 406]

Свичи на таких чипсетах давно зарекомендовали себя как независающие стабильные решения(в отличие от свичей на чипсетах realtek).

 

впервые слышу. и практика показывает обратное. Хотя в большей степени стабильность зависит от качества питания и производителя свича. Но в большинстве своем как раз реалтеки более неприхотливы, нежели ic+. А вообще, тяниите оптику и дробите свою цепочку на более мелкие. это позволит избежать массу проблем.

[napTu 4]

О том то и речь, что эти свичи независимые от качества питания, просто грамотный чипсет и еще, я полагаю, изначальная заточка на переменное или нестабилизированное питание (иногда подаем питание 15-20В до 100м по принципу POE).

 

свичи на ic+ используем несолько лет, вначале думали тоже что это зависит от производителя, но поставки хорошей модели одного производителя кончились, пошла другая модель, но уже на реалтеках и +5в питание, пошли висяки. Начали искать другого производителя, нашли, пользовались, поставки кончились. Нашли другого опять. И всегда стабильность и независимость от питания = внутри ic+ ip178d.

А начсчет производителей тоже прикол - вскрыл пару свичей Canyon и Encore, абсолютно разные корпуса, но внутри абсолютно одинаковые платы.

 

А вообще, тяниите оптику и дробите свою цепочку на более мелкие. это позволит избежать массу проблем.

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

[rsst 406]

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

 

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

[Туйон 1 259]

Подниму старое, дабы не плодить неактувльное новое.

Есть сетка на офисах из неуправляемых свитчей и компов, порядка 100.

Раньше в центре сети (туда сходятся около 5 "веток") стоял свитч типа тп-линка управляемого на 8 портов, там был отключен flow control - сеть работала нормально.

Свитч почил с миром..

Установили туда обычный свитч - начал скакать пинг и плохо работать сеть.

Прошлый админ рассказал, что в сети есть глючные устройства и они рассылают flow-control трафик, свитчи на него реагируют.

Выискивать виновников трудно и невозможно (дебильное начальство и пользователи).

Как решить данную проблему с помощью микротика? Можно ли им зафильтровать flow-control пакеты?

Можно ли как-то отключить это на тупых свитчах? На чипах реалтек? (там почти все такие).

 

Отака фигня, 21 век на дворе, а тут такое)

[napTu 4]

Ну так решение уже озвучено практически.

Любое устройство в сети, имеющее 10Мбит(вместо 100) подключение и качающее на полной скорости будет выставлять flow pause флаг, неуправляемые свичи передадут этот флаг по всему сегменту и весь сегмент будет тупить.

Отсюда варианты решения: ограничить скорость отдачи, при передаче данных, менее 10Мбит или отключить flowcontrol.

По вопросу отключения на реалтеках нужно курить даташит к этим чипсетам

[napTu 4]

И да, ещё можно устранить 10Мбит устройства и не дпускать полного 100мбит трафика. И ещё современные роутеры часто при зависании постоянно рассылают flow pause флаг и тогда сегмент ложится вообще.