[zorge1982]

Добрый день. Есть проблема подключения двух CRS 354-48G-4S+2Q по метровому DAC от MT. Проблема в следующем: не поднимается скорость через BWTESTН более 540Mbps независимо от кабеля и SFP модулей. Пробовал родные SFPшки от МТ, так же NAGовские и сам DAC метровый кабель от MT .Всегда одинаковая скорость ,что в both, что в receive режимах. Даже если в порты SFP+ вставляю SFP 1G модули, то даже гигабита не выдает. Тики сбросил в No Def Config , дал адреса на SFP+ порты  ,без бриджей и тд пока. На свичах пробовал разные прошивки ,сначала 7.1.5, потом даунгрейд до  6.48 long и 6.49 stable = проблема остается. Гугл кроме как замену DAC ничего не предлагает. Куда посмотреть, посоветуйте? Спасибо.

[sheft]

а что при замере скорости говорит system/resource/print или tool/profile ?

вы сервер и клиент поднимаете на этих же самых тиках? вам нужно сервер запустить вне этих коммутаторов на чём то более производительном.

[zorge1982]

Cpu0 - 100

Networking - 82-85

[jffulcrum]

В 04.04.2022 в 13:18, zorge1982 сказал:

BWTESTН более 540Mbps независимо от кабеля и SFP модулей

Э-э, у железяк процессор одноядерный MIPS  600MHz, он и гигабита по BWTEST не выдаст. Ставьте с двух сторон по какому-то роутеру как минимум 4011, или компы и мерить по iperf

[alibek]

В 04.04.2022 в 14:33, jffulcrum сказал:

как минимум 4011

Не уверен, что 4011 вытянет десять гигабит.

Я бы сказал, что его потолок — около 5 Гбит/с.

[zorge1982]

On 4/4/2022 at 2:33 PM, jffulcrum said:

о роутеру как минимум 401

Спасибо за ответы, те как я понял сам процессор коммутатора не в состоянии сгенерировать такой трафик, сейчас попробую через 2004 померить, компов с 10G в наличии нет

[jffulcrum]

В 04.04.2022 в 15:05, zorge1982 сказал:

не в состоянии сгенерировать такой трафик

Не то, что сгенерировать, а даже принять.

[Saab95]

В 04.04.2022 в 14:35, alibek сказал:

Не уверен, что 4011 вытянет десять гигабит.

Я бы сказал, что его потолок — около 5 Гбит/с.

10 прокачивает.

 

В 04.04.2022 в 14:33, jffulcrum сказал:

Э-э, у железяк процессор одноядерный MIPS  600MHz, он и гигабита по BWTEST не выдаст.

Выдает полтора-два. Это по UDP.

[sirmax]

В 05.04.2022 в 01:35, Saab95 сказал:

10 прокачивает.

У него ж 1 порт на 10 гиг
куда прокачивает, с какими настройками?

 

[Saab95]

У него еще в достатке медных портов на 1 гиг что бы как раз все 10 забрать. Настройки простые - IP интерфейсы на портах и OSPF. Более ничего.

[Корпич]

В 05.04.2022 в 01:35, Saab95 сказал:

10 прокачивает.

 

В 27.04.2022 в 22:22, Saab95 сказал:

У него еще в достатке медных портов на 1 гиг что бы как раз все 10 забрать.

НЕ верю...

 

В 04.04.2022 в 14:35, alibek сказал:

Я бы сказал, что его потолок — около 5 Гбит/с.

полностью согласен

[weedman]

В 28.04.2022 в 02:22, Saab95 сказал:

У него еще в достатке медных портов на 1 гиг что бы как раз все 10 забрать. Настройки простые - IP интерфейсы на портах и OSPF. Более ничего.

А разве OSPF это не маршрутизация и нагрузка на проц?

[Saab95]

В 02.05.2022 в 03:20, weedman сказал:

А разве OSPF это не маршрутизация и нагрузка на проц?

Маршрутизация без правил фильтров, манглов, шейперов по производительности выше, чем программный бридж без HW.

[sirmax]

В 03.05.2022 в 22:29, Saab95 сказал:

Маршрутизация без правил фильтров, манглов, шейперов по производительности выше, чем программный бридж без HW.

Можете обосновать это утверждение? Или бриджи сделаны плохо в микротиках? Я так не думаю 

[DeLL]

у сааба, судя по описанию, на 4011 нагрузка только в виде голой маршрутизации. В таком режиме без использования контрака 4011 может и 10г прокачать. Даже с 1 портом 10г. Роутер на палочке

[Saab95]

В 05.05.2022 в 23:17, sirmax сказал:

Или бриджи сделаны плохо в микротиках?

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

 

Но так же может работать на бридже и без аппаратных ускорений, программно. И вот если использовать не L2 на сети, а маршрутизацию, при этом без других настроек (без фильтров, манглов, шейперов, НАТ), то есть когда все разделы файрвола пустые, он очень много прокачивает в роутинге.

[sirmax]

22 часа назад, Saab95 сказал:

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

 

Но так же может работать на бридже и без аппаратных ускорений, программно. И вот если использовать не L2 на сети, а маршрутизацию, при этом без других настроек (без фильтров, манглов, шейперов, НАТ), то есть когда все разделы файрвола пустые, он очень много прокачивает в роутинге.

1 - я говорю только о программной коммутации 
2 - можете обосновать а не просто высказывать свое мнение? (подсказываю - "я думаю что коммутация медленнее маршрутизации по тому что (тут список аргументов) )"

Мне кажется что для того что бы переложить пакет с одного интерфейса  на второй на L2 (коммутация) то нужно сделать лукап в табличке маков и все
Пакет не модифицируется, маки не меняются

Для того что бы смаршрутизировать пакет нужно во-первых разобрать его до уровня ip и уже потом сделать лукап по табличке роутинга найти куда слать, собрать новый пакет с новым маком 

Те сильно больше действий для процессора

По-тому мне кажется что аршрутизация может быть быстрее программной коммутации только если что-то криво написано (в чем я тоже сомневаюсь ибо линукс)


 

[Saab95]

Процессор роутера не будет пересобирать пакет, он просто возьмет его в сборе и отправит на нужный интерфейс, обратившись к таблице маршрутизации.

 

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

[SUrov_IBM]

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

 

На уровне L3, маршрутизатор не «перебрасывает» IP пакет интерфейсу назначения «сам по себе», даже если IP пакет является «транзитным» для маршрутизатора и к IP пакету не применяются дополнительные действия (NAT, ACL (Firewall) и т.п.).

 

Как минимум, при классической IP маршрутизации происходит:

- Отделение заголовка от payload data, чтение заголовка. Перемещение payload data в буфер, прекращение существования оригинала заголовка.

- Поиск адреса назначения, определение выходного интерфейса.

- Формирование нового заголовка, на основе данных из оригинального заголовка, с дополнением информации о переходе.

- Присоединение к новому заголовку payload data ожидающего в буфере.

 

Для этих действий, как раз таки нужен ресурс CPU. Не говоря о том, что когда добрались до L3 и получили IP, маршрутизатор произвёл множество действий с фреймами на L2 на входном интерфейсе до этого и вновь произведёт при переходи L3 => L2 на выходном интерфейсе.

 

Соглашусь с форумчанином Sirmax, L2 коммутация в чистом виде (L2 - L2), должна происходить быстрее, чем L2 => L3 =>L2.

 

P.S. От больших L2 сегментов стараются уходить по совершенно иным причинам, не связанным со скоростью.

[sol]

В 07.05.2022 в 23:57, Saab95 сказал:

Процессор роутера не будет пересобирать пакет, он просто возьмет его в сборе и отправит на нужный интерфейс, обратившись к таблице маршрутизации.

Даааа дааааа. Магическое мышление.

И не будет у пакета уменьшаться TTL, и не будет в связи с этим пересчитываться CRC. Так же не будет меняться L2 заголовок т.к. MAC адреса отправителя и получателя останутся прежними...

 

[Saab95]

В 08.05.2022 в 02:11, SUrov_IBM сказал:

Для этих действий, как раз таки нужен ресурс CPU. Не говоря о том, что когда добрались до L3 и получили IP, маршрутизатор произвёл множество действий с фреймами на L2 на входном интерфейсе до этого и вновь произведёт при переходи L3 => L2 на выходном интерфейсе.

Многие из указанных действий выполняются процессором аппаратно. На то он и роутер.

[edo]

В 09.05.2022 в 23:03, Saab95 сказал:

Многие из указанных действий выполняются процессором аппаратно. На то он и роутер.

но при этом пакет проходит через RAM процессора, что позволяет победить малый объём буфера у микросхемы свитча?

как-то всё это сомнительно

[sol]

В 09.05.2022 в 23:03, Saab95 сказал:

Многие из указанных действий выполняются процессором аппаратно

Ну вообще так-то программа выполняется процессором аппаратно, да.

 

[Saab95]

В 10.05.2022 в 09:30, edo сказал:

как-то всё это сомнительно

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

[sol]

В 12.05.2022 в 01:24, Saab95 сказал:

Там аппаратно сравниваются сразу все данные разом для поиска нужной информации.

О б-ги!

Данные в кэше ни с чем не сравниваются. Данные в нём разделены на строки некоторого размера (в x86 архитектуре это 64 байта). И при каждой строке в отдельной памяти типа TCAM живёт тэг этой строки. И вот в этом тэге и находится адрес в ОЗУ, которому принадлежит эти строка. При операциях чтения/записи сравниваются "все адреса разом" именно в этой, очень специфично устроенной аппаратно (TCAM) памяти тэгов. Она на 386/486 материнках даже стояла отдельной микросхемой. Там было 4 или 8 микросхем собственно кэша и одна, немного другая - тэги.

 

Но какое это имеет отношение к объективно меньшему кол-ву действий при организации программного бриджа по отношению к маршрутизации IP решительно не понятно. Кол-во действий меньше на порядок. И если при этом роутинг быстрее чем свитчинг - то это очень знаковое и нелестное замечание в адрес криворуких программистов из микротик, которые корёжат код ядра linux.