+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

CRS317 10G -> 1G трафик медленный, всё остальное в порядке.

CRS317 10G -> 1G трафик медленный, всё остальное в порядке., Аппаратное обеспечение

gmstack

Guest

20.12.2017 09:37:00

Трафик с 10Gbit машин на другие 10Gbit машины в порядке — около 9Gbit. Трафик с 1Gbit машин на другие 1Gbit машины тоже нормальный — около 950mbit. Трафик с 1Gbit машин на 10Gbit машины работает отлично — около 950mbit. Но… трафик с 10Gbit машин на 1Gbit машины при этом имеет очень много повторных передач и держится примерно на 150mbit. Сейчас у меня все 1Gbit машины на отдельной подсети, и CRS317 их маршрутизирует к 10G машинам — и это работает быстрее, примерно 950mbit. Проблема проявляется на RouterOS и SwOS — я пробовал последние версии RouterOS (6.41rc66) и 6.40.5, обе имеют эту проблему. SwOS тоже показывает этот баг — версия 2.3p, которую он поставляет, у меня не заработала, но в 2.6 проблема тоже есть. Я также пробовал, чтобы 1G сторона была через SFP-RJ45 конвертер, 1G была 1000BaseLX и через гигабитный порт на передней панели — всё ведёт себя одинаково. Посмотрел в интернете, там похожий топик с проблемами на CSS326. В changelog’ах видел: *) crs326 — исправлена скорость обработки пакетов на чипе коммутатора, если скоростные параметры портов отличаются; *) crs326 — улучшена производительность передачи с SFP+ на Ethernet порты; Думаю, у CRS317 может быть похожая проблема, потому что звучит так же, как моя ситуация… Ниже пример iperf3. 172.16.1.20 — 10Gbit сервер, 172.16.1.19 — 1Gbit машина. ----------------------------------------------------------- Сервер слушает на 5201 ----------------------------------------------------------- Принято соединение с 172.16.1.19, порт 55059 [ 5] локально 172.16.1.20:5201 подключено к 172.16.1.19:55060 [ ID] Интервал Передано Пропускная способность [ 5] 0.00-1.00 с 111 МБайт 931 Мбит/с [ 5] 1.00-2.00 с 112 МБайт 940 Мбит/с [ 5] 2.00-3.00 с 112 МБайт 940 Мбит/с [ 5] 3.00-4.00 с 112 МБайт 940 Мбит/с [ 5] 4.00-5.00 с 112 МБайт 940 Мбит/с [ 5] 4.00-5.00 с 112 МБайт 940 Мбит/с - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Интервал Передано Пропускная способность [ 5] 0.00-5.00 с 0.00 Байт 0.00 бит/с отправитель [ 5] 0.00-5.00 с 569 МБайт 955 Мбит/с получатель iperf3: клиент отключился ----------------------------------------------------------- Сервер слушает на 5201 ----------------------------------------------------------- Принято соединение с 172.16.1.19, порт 55062 [ 5] локально 172.16.1.20:5201 подключено к 172.16.1.19:55063 [ ID] Интервал Передано Пропускная способность Повторные передачи Cwnd [ 5] 0.00-1.00 с 17.1 МБайт 143 Мбит/с 282 12.7 Кбайт [ 5] 1.00-2.00 с 17.3 МБайт 145 Мбит/с 266 22.6 Кбайт [ 5] 2.00-3.00 с 17.5 МБайт 147 Мбит/с 264 14.1 Кбайт [ 5] 3.00-4.00 с 17.2 МБайт 144 Мбит/с 282 14.1 Кбайт [ 5] 4.00-5.00 с 17.3 МБайт 145 Мбит/с 251 12.7 Кбайт [ 5] 5.00-6.00 с 17.4 МБайт 146 Мбит/с 250 12.7 Кбайт [ 5] 6.00-7.00 с 17.8 МБайт 149 Мбит/с 282 15.6 Кбайт [ 5] 7.00-8.00 с 17.2 МБайт 144 Мбит/с 295 12.7 Кбайт [ 5] 8.00-9.00 с 17.3 МБайт 145 Мбит/с 268 12.7 Кбайт [ 5] 9.00-10.00 с 17.8 МБайт 149 Мбит/с 292 22.6 Кбайт [ 5] 10.00-10.01 с 255 КБайт 247 Мбит/с 4 14.1 Кбайт - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Интервал Передано Пропускная способность Повторные передачи [ 5] 0.00-10.01 с 174 МБайт 146 Мбит/с 2736 отправитель [ 5] 0.00-10.01 с 0.00 Байт 0.00 бит/с получатель

hooyao

Guest

30.08.2018 14:58:00

Я только что получил ответ от Mikrotik и хочу сообщить вам, что нам известна проблема с производительностью при переходе с 10G на 1G на устройствах CRS3xx. В данный момент мы работаем над новым программным обеспечением с улучшенной системой распределения буферов.

awonglk Guest	#3 0 09.01.2019 04:28:00 Были ли какие-то ответы от поддержки Mikrotik с августа 2018 года?

ste Guest	#4 0 09.01.2019 04:35:00 Проверьте журналы изменений. Проблема решена.

awonglk Guest	#5 0 12.01.2019 03:43:00 Там написано: «crs3xx — улучшена передача данных между портами 10G и 1G». Кто-нибудь может измерить, насколько это действительно улучшилось?

ToBeFrank Guest	#6 0 26.01.2019 18:49:00 Могу подтвердить, что проблема исправлена в версии 6.43.8.

gmstack

Guest

18.01.2018 08:22:00

Похоже, частично исправлено в версии 6.42rc9. Подключение к хосту 172.16.1.20, порт 5201.
Режим обратной передачи, удалённый хост 172.16.1.20 отправляет данные.
[ 5] локальный 172.16.1.19 порт 55268 подключён к 172.16.1.20 порт 5201
[ ID] Интервал Передано Скорость
[ 5] 0.00-1.00 сек 78.5 МБайта 659 Мбит/с
[ 5] 1.00-2.00 сек 75.9 МБайта 636 Мбит/с
[ 5] 2.00-3.00 сек 77.8 МБайта 653 Мбит/с
[ 5] 3.00-4.00 сек 79.3 МБайта 666 Мбит/с
[ 5] 4.00-5.00 сек 77.7 МБайта 652 Мбит/с
[ 5] 5.00-6.00 сек 76.9 МБайта 645 Мбит/с
[ 5] 6.00-7.00 сек 77.2 МБайта 647 Мбит/с
[ 5] 7.00-8.00 сек 75.9 МБайта 637 Мбит/с
[ 5] 8.00-9.00 сек 77.0 МБайта 646 Мбит/с
[ 5] 9.00-10.00 сек 76.5 МБайта 642 Мбит/с
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Интервал Передано Скорость Повторы
[ 5] 0.00-10.00 сек 774 МБайт 649 Мбит/с 6065 отправитель
[ 5] 0.00-10.00 сек 773 МБайт 648 Мбит/с получатель

iperf завершён.

dksoft Guest	#8 0 19.01.2018 10:05:00 Пожалуйста, предоставьте текст, который нужно перевести.

ste Guest	#9 0 19.01.2018 10:15:00 SFP+RJ10 по-прежнему отображает состояние линии «включено/выключено» даже без подключённого кабеля.

geoffc123

Guest

#10

03.02.2018 16:29:00

Та же проблема у меня. Вот моя схема: ccr1036 → crs317 → crs212 10s 1s+. CRS317 работает очень медленно при загрузке у клиентов с 1G SFP, поэтому я был вынужден делать 10G трассу в CRS212 10s 1s+. CRS212 периодически нужно перезагружать каждые несколько недель, а CRS317 не дает хорошей скорости загрузки на 1G SFP (скорость загрузки для клиентов очень низкая). В итоге у меня 9 клиентов с 1G оптикой, и я не могу нормально их обслуживать, потому что CRS212 постоянно требует перезагрузок — я его менял уже 3 раза, и проблема остается. У CRS317 есть проблема с трафиком с SFP+ на 1G SFP — он медленно идет. Если это не исправят, мне придется искать альтернативные решения, кроме MikroTik.

netflow

Guest

#11

31.03.2018 12:23:00

Пока таких устройств нет, но любые находки интересны. Пробовали использовать RED queues https://wiki.mikrotik.com/wiki/Manual:Queue#RED? Хороший ресурс с распространёнными проблемами здесь: https://fasterdata.es.net/network-tuning/router-switch-buffer-size-issues/

hooyao

Guest

#12

03.04.2018 04:54:00

Привет! У меня есть 2 S+RJ10 на css326, они подключены к NAS и рабочей станции. Эти два модуля кажутся очень ненадёжными. Они отключаются постоянно, в среднем раза один в день. Я заметил это в логах рабочей станции. Иногда сетевая карта показывает, что соединение есть, но данные не отправляются и не принимаются. Кабель CAT6A. Также я поставил вентилятор рядом с этими двумя модулями внутри коммутатора. У тебя были похожие проблемы?

hooyao

Guest

#13

13.08.2018 14:53:00

У меня есть CRS326 и 2 модуля s+rj10 10G base-t, этот коммутатор страдает от той же проблемы с переключением 10G → 1G. Я пробовал твой совет: включал IP-фильтрацию в мосте, создавал правило mangle для маркировки пакетов 10G → 1G, создавал очередь red/pcq/... с максимальным лимитом 1000M. Это ускоряло передачу данных с 200M до 300M, но загрузка процессора взлетала до 80%. Потом заметил, что просто включение IP-фильтрации и отключение аппаратного оффлоада на портах дают тот же результат. Можешь дать ещё какие-нибудь подсказки?

lapsio Guest	#14 0 15.08.2018 22:32:00 Возможно связано: http://forum.mikrotik.com/t/s-rj10-improperly-auto-negotiates-to-10g/122418/1

lapsio Guest	#15 0 15.08.2018 22:37:00 Это всё ещё происходит в августе…

marekm

Guest

#16

28.01.2019 11:20:00

Какой размер буфера у коммутатора? Для локальной сети он может быть вполне подходящим, но всё же слишком маленьким для реального всплеска трафика из Интернета. Буфер должен быть примерно такого размера, чтобы вместить количество данных, соответствующее среднему времени задержки (RTT — round trip time), а в коммутаторе это ограничено железом (быстрой памятью внутри чипа коммутатора, а не значительно большей оперативной памятью, доступной RouterOS). Некоторые коммутаторы указывают размер буфера (например, TP-Link T1700G-28TQ — память буфера пакетов: 1,5 МБ), и это достаточно мало (примерно 12 мс данных на скорости 1 Гбит/с — мало по сравнению со средним RTT в Интернете), поэтому очень важно, как эта память распределяется динамически между портами.

mkx

Guest

#17

28.01.2019 14:29:00

Размер буфера (RTT умноженное на скорость), о котором вы говорите, слишком большой (это обычно называют buffer-bloat). Необходимый размер буфера в коммутаторе обычно меньше — всего несколько кадров (jumbo, если нужно) на коммутатор. Если возникает перегрузка на одном порту, должен сработать flow control. Размер буфера, который вы упоминаете, — это типичный размер окна TCP, который выделяется и управляется IP-стеком на конечных точках TCP-соединения.

marekm Guest	#18 0 28.01.2019 15:08:00 Буфер должен справляться с резкими всплесками трафика не от одного, а от многих одновременно работающих TCP-соединений — я знаю это из личного опыта как небольшой местный провайдер (несколько сотен клиентов), который сталкивался с проблемами у разных провайдеров upstream три раза за несколько лет. Размеры буфера в их оборудовании оставались заводскими по умолчанию (порт 1 Гбит → порт 100 Мбит) или в лицензированных радиоканалах (порт 1 Гбит → радиоканал 150 Мбит, порт 1 Гбит → радиоканал 300 Мбит), и увеличение размера (когда проблема была обнаружена и меня удалось убедить сделать эту настройку) сильно помогло. Иначе происходила потеря пакетов (и мои клиенты жаловались на плохие результаты speedtest, несмотря на новый, больший и, по идее, лучший канал upstream), даже когда линия была загружена лишь наполовину. Например, у NEC iPasolink 200/400 стандартный размер очереди — 64 КБ, максимум — 1 МБ. Мои жалобы провайдерам upstream сначала отбрасывали, ведь они не видели проблемы при тестировании их тестером сети (который посылал пакеты равномерно, а не в резких всплесках, как реальный трафик из интернета). Управление потоком тоже имеет свои проблемы: на другом устройстве должен быть достаточно большой буфер, чтобы это работало, ведь по сути очередь просто переносится туда, и если сделать неправильно, можно сильно ухудшить работу сети (плохое устройство будет непрерывно захламлять порт pause-фреймами). Мой вывод: размер буфера должен быть задан явно и настраиваем, и у NEC в радиооборудовании с этим всё нормально, но оператор должен читать документацию, чтобы использовать эту настройку. Не каждый порт нуждается в таком большом размере, но для реального интернет-трафика это обязательно, потому что трафик действительно скачкообразный. Хотя я мог регулировать исходящий трафик у себя, чтобы уменьшить всплески, контролировать входящий (с загрузкой от upstream-провайдера) я не мог.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры