Mikrotik CCR

[1550nm 0]

а можно и мне лог и пасс в лс, только чтоб посмотреть

[rsst 406]

  В 28.12.2014 в 19:39, 1550nm сказал:

а можно и мне лог и пасс в лс, только чтоб посмотреть

пишите запросы в лс, организуем

[NiTr0 585]

 

 

  В 28.12.2014 в 19:26, twg сказал:

брутфорс победить на раздва. Дропнуть 22 порт для всех, кроме себя любимого, та и все. А биллинг также можно оптимизировать по ходу.

Да это-то можно. Если не надо извне рулить по ssh (иначе наступает печаль).

Но это показывает подход к разработке софта - написать код так, чтобы при ssh коннектах вешалась вся железка, и потом годами не закрывать этот баг не смотря на жалобы счастливых владельцев - это какими осьминогами надо быть

[rsst 406]

в какой-то прошивке ssh повисал. лечилось выкл-вкл в services

Но чтобы вешал всю железку - не помню такого

[urs 13]

А какие результаты с Queue tree ?

[rsst 406]

  В 28.12.2014 в 20:28, urs сказал:

А какие результаты с Queue tree ?

на сколько знаю, для CCR пока не оптимизировано

[twg 871]

  В 28.12.2014 в 19:36, rsst сказал:

 

  В 28.12.2014 в 19:26, twg сказал:

 

  В 28.12.2014 в 19:01, NiTr0 сказал:

 

  В 28.12.2014 в 17:59, rsst сказал:

5-ю до CCR на x86 юзал активно. тот же билинг, никаких вопросов.

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

 

брутфорс победить на раздва. Дропнуть 22 порт для всех, кроме себя любимого, та и все. А биллинг также можно оптимизировать по ходу.

Хочется и себе попробовать какойнибуть сср. Вместо тазика. Непонятным для меня остается шейпинг/полисинг как его приготовить, чтобы его не вгрузило. Покупать на попробовать не хочется. С мтиками сталкивался только с вафельными вариантами, на птп линки, на БС работают парочка. Работают, кушать не просят.

 

шейпинг на simple queue, сейчас под него все оптимизировано и без проблем размазывается по ядрам. могу дать логин на посмотреть живую железку

 

читал гдето про симплк, что он как раз типа и грузит и они придумали PCQ. Я было подумал, что это линуховая дисциплина, но так и не нашел это для линукса. Но может то такая статья? хз. Этот симплк нужно на каждый ИП вешать. Этож будет больше 1к правил, ну в моем случае. Стремно. ) И по ядрам он себе сам раскидывает, или както нужно ручками?

[rsst 406]

  В 28.12.2014 в 20:36, twg сказал:

 

  В 28.12.2014 в 19:36, rsst сказал:

 

  В 28.12.2014 в 19:26, twg сказал:

 

  В 28.12.2014 в 19:01, NiTr0 сказал:

 

  В 28.12.2014 в 17:59, rsst сказал:

5-ю до CCR на x86 юзал активно. тот же билинг, никаких вопросов.

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

 

брутфорс победить на раздва. Дропнуть 22 порт для всех, кроме себя любимого, та и все. А биллинг также можно оптимизировать по ходу.

Хочется и себе попробовать какойнибуть сср. Вместо тазика. Непонятным для меня остается шейпинг/полисинг как его приготовить, чтобы его не вгрузило. Покупать на попробовать не хочется. С мтиками сталкивался только с вафельными вариантами, на птп линки, на БС работают парочка. Работают, кушать не просят.

 

шейпинг на simple queue, сейчас под него все оптимизировано и без проблем размазывается по ядрам. могу дать логин на посмотреть живую железку

 

читал гдето про симплк, что он как раз типа и грузит и они придумали PCQ. Я было подумал, что это линуховая дисциплина, но так и не нашел это для линукса. Но может то такая статья? хз. Этот симплк нужно на каждый ИП вешать. Этож будет больше 1к правил, ну в моем случае. Стремно. ) И по ядрам он себе сам раскидывает, или както нужно ручками?

 

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

[twg 871]

 

 

  В 28.12.2014 в 19:36, rsst сказал:

могу дать логин на посмотреть живую железку

спасибо за предложение. Я ещё покумекаю, ну шоб зря не напрягать Вас.

[rsst 406]

  В 28.12.2014 в 20:37, twg сказал:

 

  В 28.12.2014 в 19:36, rsst сказал:

могу дать логин на посмотреть живую железку

спасибо за предложение. Я ещё покумекаю, ну шоб зря не напрягать Вас.

 

закинул логин/пасс в личку

[twg 871]

Спасибо.

Трафик больше гига на транковом порту. нагрузка проца общая 21%, по ядрам все раскинуто и не превышает 33% на ядро. Лайкую )

[Кузьменко. 15]

 

 

  В 28.12.2014 в 20:39, rsst сказал:

закинул логин/пасс в личку

 

а можна і мені? 

[rsst 406]

  В 28.12.2014 в 21:35, Кузьменко. сказал:

 

  В 28.12.2014 в 20:39, rsst сказал:

закинул логин/пасс в личку

 

а можна і мені? 

 

отправил

[Кузьменко. 15]

  В 28.12.2014 в 21:39, rsst сказал:

 

  В 28.12.2014 в 21:35, Кузьменко. сказал:

 

  В 28.12.2014 в 20:39, rsst сказал:

закинул логин/пасс в личку

 

а можна і мені? 

 

отправил

 

про 36 ядерний я точно знаю, що він зашибісь працює і ядра розприділяє...

Питання в тому, чи можна зекономити і купити 9 або 16 ядер для трафіку в 500 МБіт і до 1000 сесій максимум

знайомий пробував, казав 9ка ядра не розприділяє

 

як що до 16ки

[rsst 406]

  В 28.12.2014 в 22:01, Кузьменко. сказал:

 

  В 28.12.2014 в 21:39, rsst сказал:

 

  В 28.12.2014 в 21:35, Кузьменко. сказал:

 

  В 28.12.2014 в 20:39, rsst сказал:

закинул логин/пасс в личку

 

а можна і мені? 

 

отправил

 

про 36 ядерний я точно знаю, що він зашибісь працює і ядра розприділяє...

Питання в тому, чи можна зекономити і купити 9 або 16 ядер для трафіку в 500 МБіт і до 1000 сесій максимум

знайомий пробував, казав 9ка ядра не розприділяє

 

як що до 16ки

 

мне вообще рассказывали страшилки, что CCR на одном ядре роутит...

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

Что с 9кой - хз, не видел. Надо смотреть форум микротика по этому поводу. Думаю там также масштабируется, бо платформа одна и та же.

[ttttt 195]

Там все очень не просто с распределением по ядрам, вы что-то путаете. Там вообще такого понятия в принципе нет, ибо это решетка либо 3х3 либо 4х4, там путь через ядра программируется и связь с сетевушками только с одной стороны решетки.

http://www.microarch.org/micro40/talks/aa-micro-talk-2007.pdf

Изменено 2014-12-28 22:19:53 пользователем ttttt

[rsst 406]

  В 28.12.2014 в 22:19, ttttt сказал:

Там все очень не просто с распределением по ядрам, вы что-то путаете. Там вообще такого понятия в принципе нет, ибо это решетка либо 3х3 либо 4х4, там путь через ядра программируется и связь с сетевушками только с одной стороны решетки.

http://www.microarch.org/micro40/talks/aa-micro-talk-2007.pdf

возможно.

сужу только по результатам работы железа...

[martin 170]

36 ядер - 2.5 гига ~ 50% цпу , 16 ядер - 1 гиг  ~ 22% цпу

[Кеша 546]

  В 28.12.2014 в 22:28, martin сказал:

36 ядер - 2.5 гига ~ 50% цпу , 16 ядер - 1 гиг  ~ 22% цпу

это что, просто роутинг, нат, шейпинг, пое??

[martin 170]

это НАТ

[ghzlviv 4]

CCR1009-8G-1S-1S+  ПППое сервер 150М 250онлайн  15%

ціна такого девайса 390уо

[Schultz 95]

  В 28.12.2014 в 20:33, rsst сказал:

 

  В 28.12.2014 в 20:28, urs сказал:

А какие результаты с Queue tree ?

на сколько знаю, для CCR пока не оптимизировано

 

  Цитата

 

 

What's new in 6.24 (2014-Dec-23 13:38):

 

*) ntp - fixed vulnerabilities;

*) web proxy - fix problem when dscp was not set when ipv6 was enabled;

*) fixed problem where some of ethernet cards do not work on x86;

*) improved CCR ethernet driver (less dropped packets);

*) improved queue tree parent=global performance (especially on SMP systems and CCRs);

*) eoip/eoipv6/gre/gre6/ipip/ipipv6/6to4 tunnels have improved per core balancing on CCRs;

*) fixed tx for 6to4 tunnels with unspecified dst address;

*) fixed vrrp - could sometimes not work properly because of advertising bad set of ip addresses;

воно?

[rsst 406]

  В 29.12.2014 в 10:20, Schultz сказал:

 

  В 28.12.2014 в 20:33, rsst сказал:

 

  В 28.12.2014 в 20:28, urs сказал:

А какие результаты с Queue tree ?

на сколько знаю, для CCR пока не оптимизировано

 

  Цитата

 

 

What's new in 6.24 (2014-Dec-23 13:38):

 

*) ntp - fixed vulnerabilities;

*) web proxy - fix problem when dscp was not set when ipv6 was enabled;

*) fixed problem where some of ethernet cards do not work on x86;

*) improved CCR ethernet driver (less dropped packets);

*) improved queue tree parent=global performance (especially on SMP systems and CCRs);

*) eoip/eoipv6/gre/gre6/ipip/ipipv6/6to4 tunnels have improved per core balancing on CCRs;

*) fixed tx for 6to4 tunnels with unspecified dst address;

*) fixed vrrp - could sometimes not work properly because of advertising bad set of ip addresses;

воно?

 

ага

но я пока с 6.15 боюсь уходить )

Изменено 2014-12-29 10:23:21 пользователем rsst

[ghzlviv 4]

version: 6.23

[Schultz 95]