[7sergeynazarov7]

19 hours ago, Saab95 said:

Вход и выход лучше делать через разные физические карты, пусть даже на каждой и будет по 2 порта 10Г.

 

Само железо процессор + чипсет там все поддерживается, сетевушку модель уже написали - все отлично работает.

Спасибо за ответ. Так и думал, что лучше через разные карты, хоть и есть по 2 порта на каждой.

[NiTr0]

решил попробовать таки заапдейтить роутерось на одной ццр вундервафле с 6.44 на 6.46.7 (bugfix-only типа ветка, типа вылизана должна быть). итог: после ребута исчезли нахрен все dhcp сервера из конфига, при попытке скопипастить в терминал старый конфиг - ругалось ошибкой. повторны ребут волшебным образом вернул все сервера на место. но я совсем не уверен, что после очередного ребута у него опять не отсохнет dhcp опять, и с концами.

 

волшебный загадочный некротик...

[morf]

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

решил попробовать таки заапдейтить роутерось на одной ццр вундервафле с 6.44 на 6.46.7 (bugfix-only типа ветка, типа вылизана должна быть). итог: после ребута исчезли нахрен все dhcp сервера из конфига, при попытке скопипастить в терминал старый конфиг - ругалось ошибкой. повторны ребут волшебным образом вернул все сервера на место. но я совсем не уверен, что после очередного ребута у него опять не отсохнет dhcp опять, и с концами.

 

волшебный загадочный некротик...

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

[SyJet]

Что-то в последнее время очень много кому не везет с неподргоужаемым до конца конфигом 

[TriKS]

Тоже с последними релизами не очень. Использую эти вафельки как MPLSники. Дык вот все что после 6.44.6 - не работает с вланами qinq, т.е. не пролазит 1504 байта. Пинг без фрагментации на клиента в VPLS по 1462 ходит, а вот 1463 уже нет.  откатываешься на 6.44.6 и все как по книжке - 1472(минус заголовки) - все пролазит. До этого все было хорошо. А вот последние пол года - все.

[morf]

2 часа назад, TriKS сказал:

Тоже с последними релизами не очень. Использую эти вафельки как MPLSники. Дык вот все что после 6.44.6 - не работает с вланами qinq, т.е. не пролазит 1504 байта. Пинг без фрагментации на клиента в VPLS по 1462 ходит, а вот 1463 уже нет.  откатываешься на 6.44.6 и все как по книжке - 1472(минус заголовки) - все пролазит. До этого все было хорошо. А вот последние пол года - все.

Не пробовали в саппорт писать ? Скинь supout и версию. Они вполне адекватно решают проблемы и отвечают на вопросы. В последний раз я писал им по v7 о том, что BGP на CCR херово маршуты подтягивает, дак они траблу подтвердили и в следующей бете это пофиксили.

[TriKS]

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

Не пробовали в саппорт писать ? Скинь supout и версию.

я пару раз с ними связывался - бестолку. Просто время потратил. Поэтому считаю что и в этот раз все будет бестолку.

Они(мои микроты) все равно в отдельном управлении и в мир не выходят. Так что я не парюсь что работают на старой версии.

Изменено 23 октября, 2020 пользователем TriKS

[NiTr0]

12 часов назад, morf сказал:

Они вполне адекватно решают проблемы и отвечают на вопросы.

дада))))

писал как-то насчет того что в 6.45 дхцп при работе с радиусом И пулами стал тупо игнорить пулы, принимая от клиентов предложенные ними лизы (хоть 192.168.0.100). выглядело это так: "вышлите supout.rif... ой, вышлите его снова, прошлый криво сгенерился... ой, а почему у вас сейчас нет клиента, получившего 192.168.0.100? вышлите supout.rif с этим клиентом... ой, а вышлите журнал радиуса... а, ну да - радиус не задает ип, потому клиенту назначается ип который он запросил, все правильно, так и должно быть. что, в 6.44 было иначе? ну тогда вышлите supout.rif и лог радиуса для 6.44..."

[morf]

10 часов назад, NiTr0 сказал:

дада))))

писал как-то насчет того что в 6.45 дхцп при работе с радиусом И пулами стал тупо игнорить пулы, принимая от клиентов предложенные ними лизы (хоть 192.168.0.100). выглядело это так: "вышлите supout.rif... ой, вышлите его снова, прошлый криво сгенерился... ой, а почему у вас сейчас нет клиента, получившего 192.168.0.100? вышлите supout.rif с этим клиентом... ой, а вышлите журнал радиуса... а, ну да - радиус не задает ип, потому клиенту назначается ип который он запросил, все правильно, так и должно быть. что, в 6.44 было иначе? ну тогда вышлите supout.rif и лог радиуса для 6.44..."

Как бы да, есть такое :) Иногда проще забить, но когда-то можно и заморочиться. 

[Qlobus]

@morf есть новые тесты и рецепты? 

[morf]

8 часов назад, Qlobus сказал:

@morf есть новые тесты и рецепты? 

Пока новой беты v7 не выходило, поэтому и тестить нечего. 

Изменено 1 ноября, 2020 пользователем morf

[Qlobus]

В 01.11.2020 в 10:42, morf сказал:

Пока новой беты v7 не выходило, поэтому и тестить нечего. 

Уже есть 7.1beta3))) 

[morf]

Да, видел, но не стал писать, так как она сильно на багах. Из нового:
- поддержка очередей cake и fq_codel

- поддержка SR-IOV.

 

Использование многоядерности для BGP/OSPF и низкое использование памяти под таблицы маршрутизации, как я понял - этот вопрос решен.

Осталось ждать стабильной версии - хз, год или два, судя по тому как они пилят обновления.

Изменено 5 декабря, 2020 пользователем morf

[jffulcrum]

В 05.12.2020 в 21:59, morf сказал:

- поддержка SR-IOV.

В x86 не работает, только в CHR. На производительность, как ни странно, не повлияло, как стопорило в районе 60% интерфейсной скорости, так и продолжает, видимо порог в другом месте.

[Qlobus]

@morf Я кое что хотел уточнить: У знакомый товарища CCR1072 - при траффика ~4GB траффика cpu грузится до 100% и перезагрузки. Там BGP(default)+nat+ospf+ 2 facebook сервера. Я предлагал обновить до 7.1. Теперь, на winbox нет BGP и другие разделы... Пока что поставили CCR2004 с 6.47 на замену... Так и будет работать? 

Изменено 17 декабря, 2020 пользователем Qlobus

[morf]

5 минут назад, Qlobus сказал:

@morf Я кое что хотел уточнить: У знакомый товарища CCR1072 - при траффика ~4GB траффика cpu грузится до 100% и перезагрузки. Там BGP(default)+nat+ospf+ 2 facebook сервера. Я предлагал обновить до 7.1. Теперь, на winbox нет BGP и другие разделы... Пока что поставили CCR2004 с 6.47 на замену... Так и будет работать? 

 Если ещё был шейпер, то, боюсь, для CCR 1072 это нормально поведение. Ребутов у меня, конечно, не было, но роутинговые службы отваливались регулярно. Обновлять на 7-ю бету в корне опрометчивое решение. И как 2004? 

Изменено 17 декабря, 2020 пользователем morf

[Qlobus]

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

 Если ещё был шейпер, то, боюсь, для CCR 1072 это нормально поведение. Ребутов у меня, конечно, не было, но роутинговые службы отваливались регулярно. Обновлять на 7-ю бету в корне опрометчивое решение. И как 2004? 

2004 с 6.47, нагрузка 75-80%, перезагрузки нет не каких.

 А то что на 1072 винбоксе не показывает BGP, это нормално?

Изменено 17 декабря, 2020 пользователем Qlobus

[morf]

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

2004 с 6.47, нагрузка 75-80%, перезагрузки нет не каких.

 А то что на 1072 винбоксе не показывает BGP, это нормално?

 

Конечно, она же бета. BGP конфигурится через cli, т.к. они еще не добавили этот функицонал в winbox. И все таки - есть шейпер или нет ?

Изменено 17 декабря, 2020 пользователем morf

[Qlobus]

8 часов назад, morf сказал:

Конечно, она же бета. BGP конфигурится через cli, т.к. они еще не добавили этот функицонал в winbox. И все таки - есть шейпер или нет ?

Нет нет, шейпера нет, только bgp+nat+ospf. 

[morf]

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

Нет нет, шейпера нет, только bgp+nat+ospf. 

Нагрузка мне кажется большой. Если нет шейпера, то добавьте самым первым в IP>Firewall>Filter правило chain=forward и action=fasttrack_connection. Возможно нагрузка на CPU снизится.

Изменено 18 декабря, 2020 пользователем morf

[Qlobus]

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

Нагрузка мне кажется большой. Если нет шейпера, то добавьте в IP>Firewall>Filter правило, самым первым, chain=forward и action=fasttrack_connection. Возможно нагрузка на CPU снизится.

Просто так как вы говорите? на интерфейсе и не куда не надо? 

[morf]

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

Просто так как вы говорите? на интерфейсе и не куда не надо? 

Да, для всего forward-трафика c action=fasttrack connection. 

Часть трафика станет проходить по короткой цепочке передачи трафика, тем самым снизится нагрузка на CPU. При этом NAT работать будет.

Изменено 18 декабря, 2020 пользователем morf

[Qlobus]

В 18.12.2020 в 10:50, morf сказал:

Да, для всего forward-трафика c action=fasttrack connection. 

Часть трафика станет проходить по короткой цепочке передачи трафика, тем самым снизится нагрузка на CPU. При этом NAT работать будет.

Значит так: Так как не успели обновить и проверить CCR1072, в тот период на замену поставили CCR2004 - и на нем поставили action=fasttrack connection. Скажу что cpu с 80-90% нагрузки подал на 50-60%. Спасибо тебе дорогой друг. 

[Hun2eR]

 

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

период на замену поставили CCR2004

ccr 2004 сколько по времени в работе? оба блока питания используете?

[7sergeynazarov7]

Подскажите intel x520-da2 какое l2 mtu поддерживает qinq vlan-ы пережовывает ?