Результаты тестов Mikrotik (RouterOS) в виртуальных средах / X86 / CCR1072 / CCR1036

[morf]

Так сказать - для будущих поколений и для тех, кто думаем запустить CHR в виртуальной среде и забацать кластер с High Available. Забегу вперед - ... вам.

 

Вдохновившись опытом своих коллег, решил собрать RouterOS в качестве BRAS на базе сервера. Как раз освободился с ДЦ сервак Asus z8nr-d12.

Поставил: 2 карты x520 (оригинал и китай), последние камни для этого сокета Xeon x5690 (2 шт по 12 ядер с HT, в сумме 24 ядра), оригинальные Intel DAC sfp+. И начал тестить все это дело в разных средах.

Честно говоря, тут должна быть подробная статья с описанием тестирования, но, честно - влом.  

Тесты:

- на гипервизорах: Xen + XCP-NG, Vmware, Proxmox; Hyper-V не тестил, т.к. это, на мой взгдят, перебор - RouterOS на Widows Server с ночными аптейтами :)

- тестил CHR и х86 RouterOS;

- тестил CCR1072 / CCR 1036.

- с использованием SR-IOV;

- с использованием PCI-Passthrough;

- с использованием паравиртуальных сетевых картах.

- гонял реальный трафик

 

Выводы по виртуальным средам, номер раз:

- SR-IOV не поддерживается RouterOS от слова вообще.

- худшие результаты были на гипервизорах с использованием паравиртуальных сетевых драйверов (Vmxnet3). В ~4-6 раз хуже самых лучших результатов + куча дропов.

- средние результаты были на гипервизорах с проброшенной X520 прямо в виртуалку (PCI-Passthrough). В ~2-3 раз хуже самых лучших результатов. Дропов почти нет.

- самые лучшие результаты были получены на чистом RouterOS для х86. 

 

Выводы по виртуальным средам, номер два:

- рассматривать CHR в качестве решения для BRAS, с трафиком больше 1G, не стоит.

- CHR с PCI-Passthrough рабочий вариант, но преимуществ в себе никаких не несет, т.к. нельзя использовать фишки виртуализации: миграция, кластеры, High Available. Ну и излишнее расточительство ресурсов имеет место быть.

- Никакие другие тесты даже близко не подходят к возможностям чистого RouterOS на Х86.

- CHR чисто для ДатаЦентров и какого-то количества виртуальных машин, чтобы рулить: роутингом, шейпером, НАТом, bgp/ospf; с аплинком не более 1 Gbps

 

Выводы по CCR 1072 /1036:

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

- для чистого forward / mpls трафика очень годное решение (гоняю 4-5 Gbps)

- c использованием очередей (queue), получаем повышенный jitter и нагрузку на CPU, небольшие дропы. Про шейпинг при  > 2 Gbps трафика лучше забыть.

- динамическая маршрутизация использует 1 ядро, поэтому 1-3 FV-таблицы не больше. Если BGP-Peer будет флапать, то получите конкретный ****ц из-за того, что префиксы не будут успевать удалятся и добавляться.

- Ядра 1-1.2 Ghz. Даже самый лёгкий DoS/DDoS укладывает CCR на лопатки так, что тот не успевает ничего понять.  Я перепробовал всё: tcp syn cookie, детекцию с занесением в raw и прочую хрень. RAW эффективен, но и он не всегда спасает.

 DDoS влияет на работу сервисов динамической маршрутизации (ospf/bgp), те, в свою очередь, не могут поддерживать сессии из-за высокой нагрузки CPU и падают. x86 c двумя Xeon X5690 держался очень достойно и схавал всё, чем я его ддосил. 

 

PS: Еще тестил PfSense и VyOS на X86.

 - Понравился VyOS, но для решения пограничного бордера (bgp/ospf).

 - PfSense рабочая лошадка с аналогичными возможностями RouterOS, но ТАКОЕ управление через WEB меня просто вгоняло в ступор. Кстати у PfSense есть крутое решения для High Available. Ни разу не VRRP, а полная синхронизация. 

 

К вопросу, насчет китайской и оригинальной карты: по результатам тестов разницы никакой. Только физический различия в качестве сборки и пайки. Чип в китайской такой же.

[Jora_1]

В ‎05‎.‎03‎.‎2020 в 11:56, morf сказал:

x86 c двумя Xeon X5690 держался очень достойно и схавал всё

x86 поддерживает новые версии routeros, аперативу более 2Gb, l2mtu нормально работает? 

[alvisid]

Ничего не понял. Говорите что для бордера микрот годное решение, но флап убивает и любой мало-мальсуий Ddos это смерть железке. Так в чем годность?!

[morf]

14 часов назад, jora_1 сказал:

x86 поддерживает новые версии routeros, аперативу более 2Gb, l2mtu нормально работает? 

Не у всех сетевухи. У меня встроенные в материнку поддерживают mtu до 9120. Точного рецепта нет. X520 ещё предстоит проверить. 

 

14 часов назад, alvisid сказал:

Ничего не понял. Говорите что для бордера микрот годное решение, но флап убивает и любой мало-мальсуий Ddos это смерть железке. Так в чем годность?!

 CCR с их маломощными ядрами гавно. И да, лёгкий Ddos их убивает. X86 пережевывает весь Ddos, которыми я их гонял. Поэтому да, да x86 лучше. 

Edited March 7, 2020 by morf

[Jora_1]

@morf Так и не понял, x86 поддерживает более 2гб оперативы и новые версии роутер ос?

[Zhenterik]

@jora_1 RouterOS x86 можно снять ограничение в 2Gb на оперативку.

Тут написано как это сделать.

[LostSoul]

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

Тестировал CHR и RouterOS x86   для иного применения, чем автор.

Задача была терминировать несколько десятков ipsec / EOIP туннелей  с использованием AES-NI акселерации.

 

Сервер для тестирования был Xeon E3-1225v2  ( socket 1155 DDR3 )

среда виртуализации -  kvm через libvirtd  , драйвера паравиртуальные virtio .

 

тест скорости ( тест микротик ) из виртуальной среды и обратно - около 4Гбит симплекса.

ipsec  с аппаратным ускорением AES-NI - работает на routeros x86 , дает около 2гигабит при около 80% загрузке 1 ядра ,  НО аппаратный offload включается только с одним из aes-алгоритмов ,   при использовании которого не включается offload на Mikrotik HEX-S и Mikrotik RB750Gr3 , а это была основная идея.

Если же разрешить алгоритм, аппаратно ускоренный на стороне RB750Gr3 то AES на стороне сервера уже чисто программный и жрет CPU как ни в себя.

Памяти больше 2Гб в моем случае видела версия X86 из коробки , хотя нагружать ее я не проверял.

 

Версия CHR видела и задействовала несколько ядер CPU , но не хотела включать AES-NI offload , почему я так и не разобрался.

 

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

В итоге он был сделан на Linux , но с потерей функциональности EOIP Keepalive  ( когда routeros мониторит живость линка и гасит статус running у интерфейса, при потере связанности) .  Пришлось решать это поднятием BFD поверх eoip .

 

[Jora_1]

@Zhenterik Спасибо, уже давно про это читал, но этот способ будет работать на последних версиях роутер ос? Собирать машину, и не быть уверенным что лицензия не слетит стрёмно. Как-то даже ставил на демо лицензии и она сразу слетела после обновления.

На данный момент использую один из микротиков  CCR1072 с частотой 1200, nat+pppoe+simple queue, среднее значение 50% cpu при 2.5Gb трафика.

Edited March 7, 2020 by jora_1

[Zhenterik]

@jora_1 Где то в феврале тестировал RouterOS в роли бордера. Накатил тестовую 6.31 поставил галку "System -> Resources -> Hardware": Allow x86-64", перезагрузил ОС слетела. Переустановил, добавил лицензию, выбрал Allow x86-64, после перезагрузки ОС стартовала нормально 16 Гиг памяти видел. Обновлял до последней стабильной версии RouterOS. BGP 2 full view работало нестабильно, в процессе вливания полной таблицы от одного пира, подвисал, выкидывал из winbox, просмотр полной таблицы так же сопровождался тормозами, в итоге отказался в пользу debian + FRR.

Edited March 7, 2020 by Zhenterik

[fractal]

4 часа назад, Zhenterik сказал:

@jora_1 Где то в феврале тестировал RouterOS в роли бордера. Накатил тестовую 6.31 поставил галку "System -> Resources -> Hardware": Allow x86-64", перезагрузил ОС слетела. Переустановил, добавил лицензию, выбрал Allow x86-64, после перезагрузки ОС стартовала нормально 16 Гиг памяти видел. Обновлял до последней стабильной версии RouterOS. BGP 2 full view работало нестабильно, в процессе вливания полной таблицы от одного пира, подвисал, выкидывал из winbox, просмотр полной таблицы так же сопровождался тормозами, в итоге отказался в пользу debian + FRR.

 

да, с BGP у него проблемы, нормального бордера на 5fw на нем не ожидается еще года 4 наверное, пока запилят 7ось пока затестят

[morf]

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

@jora_1 Где то в феврале тестировал RouterOS в роли бордера. Накатил тестовую 6.31 поставил галку "System -> Resources -> Hardware": Allow x86-64", перезагрузил ОС слетела. Переустановил, добавил лицензию, выбрал Allow x86-64, после перезагрузки ОС стартовала нормально 16 Гиг памяти видел. Обновлял до последней стабильной версии RouterOS. BGP 2 full view работало нестабильно, в процессе вливания полной таблицы от одного пира, подвисал, выкидывал из winbox, просмотр полной таблицы так же сопровождался тормозами, в итоге отказался в пользу debian + FRR.

 

Сегодня попробую сделать так же. Откачу сервер до 6.31, включу х86_64, обновлюсь до последнего long term и залью 2-3 FV. Хотя, в моем случае хватило бы и 2 Гб памяти, но все же интересно. 

[Zhenterik]

@morf Отпишитесь по результату, интересны будут Ваши наблюдения.

[Jora_1]

@ZhenterikСпс за ответ. Так и делал но без покупки лицензии, так как не хотел покупать лицензию на тестовый комп. Пробовал на fx-8350, материнка m5a97 и сетевая встройка не запустилась, хотя микрот её видел, но она не принимала и не отправляла пакеты. Вставил простую тплинк 100mb/s, которая заработала, но были проблемы с mtu. Потом проверил количество ядер на 6.31, и у видел, что поддерживается только одно ядро, обновил до последней роутер ос, и слетела демо лицензия, дальше забил с экспериментами :)

 

Интересно, если поставить x86 на райзен к примеру x2700 или 3700x, будет работать?

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

@morf Отпишитесь по результату, интересны будут Ваши наблюдения.

+

Edited March 7, 2020 by jora_1

[morf]

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

@ZhenterikСпс за ответ. Так и делал но без покупки лицензии, так как не хотел покупать лицензию на тестовый комп. Пробовал на fx-8350, материнка m5a97 и сетевая встройка не запустилась, хотя микрот её видел, но она не принимала и не отправляла пакеты. Вставил простую тплинк 100mb/s, которая заработала, но были проблемы с mtu. Потом проверил количество ядер на 6.31, и у видел, что поддерживается только одно ядро, обновил до последней роутер ос, и слетела демо лицензия, дальше забил с экспериментами :)

Внутри RouterOS поддержка небольшого кол-ва устройств. Могу точно сказать, что AMD не рекомендуется самим Mikrotik.

 

4 часа назад, Zhenterik сказал:

@morf Отпишитесь по результату, интересны будут Ваши наблюдения.

Поставил, увидел 8 Гб памяти, залил 2 Full View. 

Честно говоря, никакой разницы не заметил. Всё быстро и шустрою. Использовал winbox 3.20 x64. Из замеченного:

- Используется 1 ядро для работы BGP. На моих камнях Xeon X5690 (3300 Mhz), при заливке 2 FV, 1 ядро грузилось на ~20%. На CCR ~90%.

- Памяти скушало при 2 FV ~800 Мбайт.

- Поиск по таблицам  "ip route" и "bgp advertisements" через фильтры и cli работает быстро.

 

@Zhenterik Вообще, работая с большими списками (ip route, bgp advertisements), Winbox намеренно скрывает их, чтобы, как раз не подвиснуть.

 

[Zhenterik]

@morf Скорее всего разница в камнях. У меня стоит e5-2620 у него частота 2100. У Вашего больше. Быть может, если мне поменять проц, то будет более менее сносно работать. Но, я хочу попробовать встать на 4 "ноги". Сомневаюсь, что микротик нормально это пережует. 

[morf]

34 минуты назад, Zhenterik сказал:

@morf Скорее всего разница в камнях. У меня стоит e5-2620 у него частота 2100. У Вашего больше. Быть может, если мне поменять проц, то будет более менее сносно работать. Но, я хочу попробовать встать на 4 "ноги". Сомневаюсь, что микротик нормально это пережует. 

Поставьте E5-1660. У него повышенная частота при таком же кол-ве ядер и потоков. Производительность 1-го ядра в х2 раза больше, чем у 2620.

http://cpuboss.com/cpus/Intel-Xeon-E5-2620-vs-Intel-Xeon-E5-1660

https://aliexpress.ru/item/32807643257.html

Edited March 7, 2020 by morf

[Jora_1]

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

Внутри RouterOS поддержка небольшого кол-ва устройств. Могу точно сказать, что AMD не рекомендуется самим Mikrotik.

 

Поставил, увидел 8 Гб памяти, залил 2 Full View. 

Честно говоря, никакой разницы не заметил. Всё быстро и шустрою. 

 

В скорости разницы не будет, у меня была ситуация когда на старом ccr1016 не хватало 2Гб оперативы, и роутер ребутелся, и за многих динамических адрес листов и SimplQueues.

[alvisid]

Окончательно мозг взорвали.  Для чего тогда можно использовать микрот?

 

Нужен бордер не менее чем на 5гбит + нат, и чтобы с сормом проблем не было 

[morf]

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

В скорости разницы не будет, у меня была ситуация когда на старом ccr1016 не хватало 2Гб оперативы, и роутер ребутелся, и за многих динамических адрес листов и SimplQueues.

Я про х86, не про CCR - с ними, как раз все понятно. 

[Jora_1]

@morf а я про то, что 2гб памяти может не хватить :) Ну а так когда увидел всю память, это уже хорошо, можно теперь пробовать.

 

48 минут назад, alvisid сказал:

Нужен бордер не менее чем на 5гбит + нат, и чтобы с сормом проблем не было 

Точно не ccr, что-то на x86 собирать.

Edited March 7, 2020 by jora_1

[morf]

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

Окончательно мозг взорвали.  Для чего тогда можно использовать микрот?

 

Нужен бордер не менее чем на 5гбит + нат, и чтобы с сормом проблем не было 

 

Если только это, без нескольких Full view и без шейпера, то справится CCR1072, впрочем и 1036 под силу. Но подчеркну - без шейера, без нескольких FV и с использованием fasttrack. Работоспособность во время Ddos - никакая.  х86 точно справится, но возможны свистопляски с подбором платформы, сетевух и камней.  

И кстати, в CCR1016 можно памяти добавить. У меня стоит 8 гигов.

Edited March 7, 2020 by morf

[morf]

Заменил свой CCR1072 на X86_64 версию с последним long term; Два Xeon X5690. Несколько BGP-сессий, трафик 2-3 Gbit (~200 тыс pps), около 2000 сессий, simple queue на абона. Дропов нет, джиттер ровный, cpu 15%.

В час-пик будет больше - буду наблюдать. 

Единственный косяк был в том, что intel x520 имеют vendor lock и лочат порты, если подключать "не вкусную" SFP+, но DAC-кабель кушали любой, даже голимый китай.

Edited March 11, 2020 by morf

[alvisid]

28 минут назад, morf сказал:

Заменил свой CCR1072 на X86_64 версию с последним long term; Два Xeon X5690. Несколько BGP-сессий, трафик 2-3 Gbit (~200 тыс pps), около 2000 сессий, simple queue на абона. Дропов нет, джиттер ровный, cpu 15%.

В час-пик будет больше - буду наблюдать. 

Единственный косяк был в том, что intel x520 имеют vendor lock и лочат порты, если подключать "не вкусную" SFP+, но DAC-кабель кушали любой, даже голимый китай.

по ядрам распределяется нормально?

[morf]

Так же, как и в CCR, только ядер меньше и они у меня по 3.3 Ghz.

 

Очень радует, как IRQ (прерывания) распределяет у Intel x520. Их кол-во равно кол-ву ядер CPU. 

 

[TriKS]

53 минуты назад, morf сказал:

Заменил свой CCR1072 на X86_64 версию с последним long term; Два Xeon X5690. Несколько BGP-сессий, трафик 2-3 Gbit (~200 тыс pps), около 2000 сессий, simple queue на абона. Дропов нет, джиттер ровный, cpu 15%.

В час-пик будет больше - буду наблюдать. 

Единственный косяк был в том, что intel x520 имеют vendor lock и лочат порты, если подключать "не вкусную" SFP+, но DAC-кабель кушали любой, даже голимый китай.

1) на одном E5649 2.4Ггц загрузка 22% тащит 11Гб трафика(около 1.2Mpps). Убунту правда. Так что ваши микротики вместе с их ROS - я продалжаю слать далеко, особенно после ваших тестов.

2) На линуксах отключается вендорлок всего 1 строчкой: allow_unsupported_sfp.

4) Заставьте флапать пару линков, с которого заливаете фуллвью. Ради интереса.

3) Я просто мимо пробегал, не смог удержаться и дать сравнение с линухом на платформе куда слабее, чем ваша.

Edited March 11, 2020 by TriKS