Перейти к содержимому
Калькуляторы

DGS-3620 и дропы

Добрый день! Прошу помочь разобраться в проблеме. Имеется CCR1009-7G-1C-1S+ в роли BRAS, на нём терминируются абоненты PPPoe, абонентов около 300. CCR1009-7G-1C-1S+ подключен к CCR1036 (бордер) через DGS-3620-28SC, маршрутизация между бордером и брасом OSPF, NAT не используется, вообщем типичная схема. Проблема такая, когда на аплинк интерфейсе CCR1009-7G-1C-1S+ трафик достигает 500 мбит/с, начинает зависать ОТТ телевидение "Смотрёшка", при этом ресурсы интернет работают нормально, другие сервисы к примеру IVI, Kinopoisk так же работают нормально, свободная ёмкость есть, тестами интерфейс спокойно нагружается до 950 мбит/с, полок по трафику на линках нет, загрузка CPU в момент проблемы не поднимается выше 30-40%, ядер которые загружены под 100% тоже нет. 

 

Рядом стоит rb1100AHx4, перекидываю абонента на него всё в порядке, OTT работает, загружаем аплинк интерфейс до 900 мбит/с, так же всё в порядке, зависаний нет.

Что было сделано, меняли порты, меняли патчкорды, SFP. 

 

Прошивка на CCR1009-7G-1C-1S+ 6.45.8.  

 

Помогите пожалуйста, что можно посмотреть, куда копнуть. Спасибо. 

Изменено пользователем Timax
Причина проблемы в другом

Поделиться сообщением


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

Timax, здравствуйте.

 

Посмотрите, чтобы TCP MSS соответствовал MTU (на -40 от максимального проходящего по каналу MTU) на абонентской стороне (за PPPoE).

 

Вот пример правила, для задания значения MSS:

/ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=no tcp-flags=syn protocol=tcp out-interface=*название интерфеса* tcp-mss=1300-65535 log=no

/ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=no tcp-flags=syn protocol=tcp in-interface=*название интерфеса* tcp-mss=1300-65535 log=no

 

On-line проверка MTU и MSS - http://www.speedguide.net:8080/

Поделиться сообщением


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

49 минут назад, SUrov_IBM сказал:

Timax, здравствуйте.

 

Посмотрите, чтобы TCP MSS соответствовал MTU (на -40 от максимального проходящего по каналу MTU) на абонентской стороне (за PPPoE).

 

Вот пример правила, для задания значения MSS:

/ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=no tcp-flags=syn protocol=tcp out-interface=*название интерфеса* tcp-mss=1300-65535 log=no

/ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=no tcp-flags=syn protocol=tcp in-interface=*название интерфеса* tcp-mss=1300-65535 log=no

 

On-line проверка MTU и MSS - http://www.speedguide.net:8080/

Спасибо за ответ.

Данный тест показывает MTU = 1480, MSS = 1440. Если не ошибаюсь для PPPoE это нормальные значения. На mikrotik включен change TCP mss.

Поделиться сообщением


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

Хм, просто мысли в слух – возможно, CCR1009-7G-1C-1S+ под нагрузкой не справляется с фрагментацией пакетов? Можно попробовать перед ним, на вышестоящем узле принудительно задать значения MTU = 1480 и MSS = 1440, а на нём наоборот убрать change TCP mss. Чтобы пакеты не фрагментировались при переходе с  MTU = 1500 на MTU = 1480 непосредственно на CCR1009.

Поделиться сообщением


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

А что с QOS на портах? Сравните параметры на 1100 и 1009. У 1100 есть свитч-чип, а у 1009 нет, отсюда вопрос между какими портами (номера) на 1100 прокачиваете нагрузку и смотрите зависания?

Поделиться сообщением


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

3 часа назад, SUrov_IBM сказал:

Хм, просто мысли в слух – возможно, CCR1009-7G-1C-1S+ под нагрузкой не справляется с фрагментацией пакетов? Можно попробовать перед ним, на вышестоящем узле принудительно задать значения MTU = 1480 и MSS = 1440, а на нём наоборот убрать change TCP mss. Чтобы пакеты не фрагментировались при переходе с  MTU = 1500 на MTU = 1480 непосредственно на CCR1009.

Не помогло

 

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

А что с QOS на портах? Сравните параметры на 1100 и 1009. У 1100 есть свитч-чип, а у 1009 нет, отсюда вопрос между какими портами (номера) на 1100 прокачиваете нагрузку и смотрите зависания?

Сейчас перекинули, подключили напрямую CCR1009 к CCR1036, исключив DGS-3620-28SC, проблема ушла, вот теперь думаем что не так с DGS

Поделиться сообщением


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

47 минут назад, Timax сказал:

исключив DGS-3620-28SC

Видимо буфера забивают я, а может с физикой что

Поделиться сообщением


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

В 18.01.2022 в 11:45, Timax сказал:

Помогите пожалуйста, что можно посмотреть, куда копнуть. Спасибо. 

Сделайте на PPPoE мту = 1500. Уйдет фрагментация, обычно все роутеры, даже тплинки, такое поддерживают.

Поделиться сообщением


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

В 18.01.2022 в 18:13, Timax сказал:

Сейчас перекинули, подключили напрямую CCR1009 к CCR1036, исключив DGS-3620-28SC, проблема ушла, вот теперь думаем что не так с DGS

линки с микротиков 1009 и 1036 в дгс у вас оба были одинаковой скорости?

Поделиться сообщением


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

5 часов назад, nixx сказал:

линки с микротиков 1009 и 1036 в дгс у вас оба были одинаковой скорости?

Добрый день!

Как оказлось проблема в том что 1036 включен в дгс на 10г линк, а 1009 включен в 1г линк. Начал гуглить нашел, что это болячка у 3620, что там с буфером.

Поделиться сообщением


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

7 часов назад, nixx сказал:

линки с микротиков 1009 и 1036 в дгс у вас оба были одинаковой скорости?

Я так понимаю раз Вы задали такой вопрос, Вам что то известно о данной проблеме? Расскажите.

Поделиться сообщением


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

В 21.01.2022 в 15:51, Timax сказал:

Я так понимаю раз Вы задали такой вопрос, Вам что то известно о данной проблеме? Расскажите.

ну вы сами написали то, что мне известно ) точно так же стоял DGS-3420 (они с 3620 почти одинаковы), вход 10гбит, выход 1гбит, потери пакетов начинались на 400 мбитах.

путем ковыряний и исследований выяснилось, что на длинке расчет счетчик HOL Drops при пропаданиях. выключение hol prevention дало еще мегабит 200, а потом резко стало совсем плохо. лучше не выключать, а просто убрать линки с разной скоростью.

Поделиться сообщением


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

Сейчас поставили Eltex 3324f, потерь нет.

Я думаю тему можно переименовать на DGS-3620 и дропы, перенести в другой раздел. Модераторы, поправьте пожалуйста.

Поделиться сообщением


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

В 21.01.2022 в 18:47, Timax сказал:

Сейчас поставили Eltex 3324f, потерь нет.

у него буфер еще меньше, чем у длинка )) значит, проблема в днк длинка.

Поделиться сообщением


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

11 часов назад, nixx сказал:

у него буфер еще меньше, чем у длинка )) значит, проблема в днк длинка.

Да, я знаю, у него всего 1.5 мб, а у длинк 2 мб))) Говорят в DGS-3630, не проблем там 4 мб буфер

Поделиться сообщением


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

В 21.01.2022 в 12:59, Timax сказал:

Начал гуглить нашел, что это болячка у 3620, что там с буфером.

А писали что микротик коммутаторы только дропы дают. Хотя у нас 6 портов 1г собираются в 10Г порт без проблем, по мегабит 500-800 через каждый порт сливается, дропов вообще нет.

Поделиться сообщением


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

Timax, здравствуйте.

 

В 21.01.2022 в 18:47, Timax сказал:

Я думаю тему можно переименовать на DGS-3620 и дропы

 

В своё время, посчастливилось мне быть обладателем DGS-3120-24SC. Ничего особенного от коммутатора не требовалось, он служил медиаконвертером для единственного Native VLAN. Простая задача, правда на канале была высокая нагрузка PPS, из-за прохождения iSCSI. На оптическом порту наблюдался постоянный рост Drop Pkts и как следствие, осень низкая производительность iSCSI. Коммутатор был практически новым (до меня, его не использовали).

 

К сожалению, никакие танцы с бубном вокруг прошивки не помогли, Drop Pkts продолжали нарастать. Было принято решение, выкинуть его нафиг отдать в хорошие руки просто так.

 

После этого, на форуме увидел, что это может быть связано с малым Traffic Control Threshold -

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

 

С того момента, к коммутаторам D-Link, у меня окончательно сложилось какое-то отвращение очень осторожное отношение и воспринимаются они исключительно как access switches для доступа офисных компьютеров в сеть.

Поделиться сообщением


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

В 22.01.2022 в 21:22, SUrov_IBM сказал:

на форуме увидел, что это может быть связано с малым Traffic Control Threshold

а вы использовали traffic control на проблемных портах? ) так-то да, может (и даже должен, если настроен на drop), но если он выключен?

Поделиться сообщением


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

Nixx, здравствуйте.

 

В 22.01.2022 в 23:46, nixx сказал:

а вы использовали traffic control на проблемных портах? )

Честно? Не знаю, специально я его не настраивал. ;) Если Traffic Control включен на DGS-3120-24SC по умолчанию, то получается использовал и зря грешу на железку. В той схеме, была абсолютно дефолтовая конфигурация, никаких дополнительных настроек не производилось, кроме IP адреса управления и VLAN растегировался, потом просто (для проверки) уже был native vlan ID 1.

 

Там на самом деле, всё достаточно курьёзно произошло, у дружественной компании вышел из строя СХД, компания в которой я работаю, пошла на помощь и разрешила использовать дисковое пространство нашего СХД, а вот связать эту "ниточку iSCSI" по дороге, через условное место где я располагался, возложили на меня. Поэтому я и схватил первое попавшееся, что мог - DGS-3120-24SC. ;)

Поделиться сообщением


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

В 21.01.2022 в 17:30, nixx сказал:

точно так же стоял DGS-3420 (они с 3620 почти одинаковы), вход 10гбит, выход 1гбит, потери пакетов начинались на 400 мбитах.

400 мбит даже для DGS-3100 ископаемых (где нет десяток но есть LACP) мало. у нас 3420 вполне себе 10>1G переливают с трафиком под 900 мбит и не жужжат. правда, не в некротики.

 

мож там у вас flow control вкючен?...

Поделиться сообщением


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

Здравствуйте. Оказывается много людей сталкивались с такой проблемой, странно что я не нашёл подобные темы касательно DGS-3620. У нас на 3620 очень простая конфигурация, молотит только L2 трафик. Traffic Control и Flow control, всё это не используется. Штук 30 вланов, влан управления и snmp, на этом всё. Трафика не много в райне 6 гигабит и тот бежит через 10г порты. Как и говорил выше пока поставили mes3324, хотя по буферу он хуже, работает нормально. 

Поделиться сообщением


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

Проблема у них будет только при переходе из 10г в 1г.

Просто 10г линки между собой работают нормально.

Включите hol prevention, будет лучше.

Ну и красить трафик надо нужный.

До 2-3 гигов терпимо, дальше хуже.

 

 

Поделиться сообщением


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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.