Добрый день! Уточнил у коллег, пока пытаемся воспроизвести вашу проблему на стенде, продолжаем пробовать разные варианты. Сказали, что написали вам письмо, но пока не получили ответа.
Мы извиняемся за неудобства, с которыми вы столкнулись при эксплуатации нашего продукта. Мы понимаем, что есть проблемы, и работаем над ними. Они касаются не только самого кода, но и внутренних процессов. Нанимаем разработчиков и тестировщиков, переделываем архитектуру. Процесс долгий, результаты станут видны не сразу.
Подскажите, пожалуйста, почему в вашем случае необходимо использовать бета-версию 7.4 beta, а не 7.2.2 stable, например?
Софт без багов не бывает в принципе, достаточно посмотреть release notes любого мирового вендора. Вопрос в том, насколько они критичны, и как быстро исправляются. Ведем большую внутреннюю работу по усилению RnD и службы QA, изменения должны сказаться на следующих релизах.
На сегодня (27.06.2025) 7.4 находится в стадии бета, и не предназначена для установки на продуктив, о чем мы специально предупреждаем. Перед переходом 7.4 в статус stable будет выпущено не менее 3-х версий 7.4 в статусе bata.
Мы не можем не вкладывать в "рюшечки и фишечки", потому что нужно развиваться дальше, и прилетают новые требования клиентов, некоторые из которых являются блокерами для продаж. Некоторые рюшечки занимают до 3-5 лет в реализации, и получить их мгновенно, когда потребуется, невозможно.
Добрый день! Основная задача этой статьи - показать и прокомментировать данные публичного теста, который мы провели в ноябре 2024. Методику и ход тестов можно посмотреть и сейчас, что может быть ценным для кого-то из наших читателей. Выход следующих версий никак не влияет на этот аспект. Не все разработчики публично говорят об этом, и показывают миксы трафика, которые они используют. У многих нет таких генераторов трафика (Ixia и Spirent), и этот момент тоже может быть для кого-то интересным. В тот момент версия 7.2.0 была актуальна и только-только стала доступной заказчиком. Позже она была отозвана из-за нахождения критической уявимости. Вместо нее можно использовать 7.2.2.
Просмотрел скриншоты, картины "500 Мбит/с в начале - процессор на 80% не увидел". Возможно проглядел, уточните какой это скриншот по счету, пожалуйста? Скорее всего это CPS-тест. В этом случае CPU открывает как можно большее количество сессий, поэтому загрузка большая, а трафик еще не начал передаваться в каждой сессии.
В DCFW используется новая версия ПО, которая получила внутренний индекс 8. Так мы явно разводим 2 продукта - NGFW и DCFW, каждый из которых будет жить самостоятельно.
Не понятен термин "фактическая производительность", уточните, пожалуйста, его значение. У NGFW можно сделать сотни конфигураций тестирования, и в каждом случае фактическая производительность может быть разной.
В среднем в 2-3 раза, в зависимости от параметра и режима работы. Как написано в статье, у F8000 2 CPU по 18 ядер каждый + 128 ГБ RAM + HDD 1 ТБ, у F8010 - 2 новых CPU AMD EPYC по 48 ядер + 256 ГБ RAM + SSD 1 ТБ (кстати, в описанных тестах испытывалась платформа с 128 ГБ RAM, позднее мы решили увеличить объем оперативки). В совокупности это дает очень серьезный рост производительности.
Сейчас тестируем бету с поддержкой IPS на FPGA, показывает до 25 Гбит/с в режиме L3/L4+IPS на EMIX, Позже комплексно протестируем в разных режимах работы. Так у нас есть протокол испытаний от августа 2024 для крупного заказчика (который потом приобрел 150 платформ, в том числе FG), где FG при 85 000 правил FW (1000 из них были с 5 элементами) и 11 000 сигнатур IPS показала 14 Гбит/с на EMIX при 20 000 000 сессий и 84 000 CPS и 21 Гбит/с если просто включить FW L3/L4.
Добрый день! Извините за поздний ответ. По порядку:
Тут нужно уточнить, что такое "базовая конфигурация". Уточню в пунктах ниже, возможно это снимет вопросы.
Использовалось 131 000 односложных правил: 1 src сеть с маской 24 бита, 1 dst сеть с маской 24 бита, 1 сервис. Каждое правило было уникальным. У каждого какие-то сети и сервис. Они были похожи только тем, что под них не попадал трафик генератора. Кроме последнего, 131000-го по счету правила, у которого была настройка allow all.
Нет, allow all было только у 131000-ого правила.
В описании указан EMIX-тест на FW L3/L4 + СОВ (Cyberflood), вот в нем дополнительно использовался дефолтный профиль IDPS.
Соответственно, на основании этих предпосылок мы считаем, что такие тесты позволяют оценить реальную производительность NGFW. Можно посмотреть запись с процессом этого тестирования с техническими подробностями на сайте UserGate Data Center Firewall (DCFW), начиная с 46 минуты.
Если есть сомнения в честности теста, мы можем провести для вас тестирование именно под ваши требованиями с применением генераторов трафика Breaking Point и/или Spirent Cyberflood. Можем потом написать об этом совместную статью.)
Добрый день! Уточнил у коллег, пока пытаемся воспроизвести вашу проблему на стенде, продолжаем пробовать разные варианты. Сказали, что написали вам письмо, но пока не получили ответа.
Добрый день! Коллеги из ТП и службы сервиса должны были с вами связаться. Для воспроизведения проблемы соберем у себя стенд.
Укажите номера тикетов в ТП, пожалуйста, посмотрим что с ними, и вернемся сюда в комментарии.
Добрый день!
Мы извиняемся за неудобства, с которыми вы столкнулись при эксплуатации нашего продукта. Мы понимаем, что есть проблемы, и работаем над ними. Они касаются не только самого кода, но и внутренних процессов. Нанимаем разработчиков и тестировщиков, переделываем архитектуру. Процесс долгий, результаты станут видны не сразу.
Подскажите, пожалуйста, почему в вашем случае необходимо использовать бета-версию 7.4 beta, а не 7.2.2 stable, например?
Здравствуйте!
Софт без багов не бывает в принципе, достаточно посмотреть release notes любого мирового вендора. Вопрос в том, насколько они критичны, и как быстро исправляются. Ведем большую внутреннюю работу по усилению RnD и службы QA, изменения должны сказаться на следующих релизах.
На сегодня (27.06.2025) 7.4 находится в стадии бета, и не предназначена для установки на продуктив, о чем мы специально предупреждаем. Перед переходом 7.4 в статус stable будет выпущено не менее 3-х версий 7.4 в статусе bata.
Мы не можем не вкладывать в "рюшечки и фишечки", потому что нужно развиваться дальше, и прилетают новые требования клиентов, некоторые из которых являются блокерами для продаж. Некоторые рюшечки занимают до 3-5 лет в реализации, и получить их мгновенно, когда потребуется, невозможно.
Добрый день! Основная задача этой статьи - показать и прокомментировать данные публичного теста, который мы провели в ноябре 2024. Методику и ход тестов можно посмотреть и сейчас, что может быть ценным для кого-то из наших читателей. Выход следующих версий никак не влияет на этот аспект. Не все разработчики публично говорят об этом, и показывают миксы трафика, которые они используют. У многих нет таких генераторов трафика (Ixia и Spirent), и этот момент тоже может быть для кого-то интересным. В тот момент версия 7.2.0 была актуальна и только-только стала доступной заказчиком. Позже она была отозвана из-за нахождения критической уявимости. Вместо нее можно использовать 7.2.2.
Добрый день! UserGate NGFW 7.2
Добрый день!
Просмотрел скриншоты, картины "500 Мбит/с в начале - процессор на 80% не увидел". Возможно проглядел, уточните какой это скриншот по счету, пожалуйста? Скорее всего это CPS-тест. В этом случае CPU открывает как можно большее количество сессий, поэтому загрузка большая, а трафик еще не начал передаваться в каждой сессии.
В DCFW используется новая версия ПО, которая получила внутренний индекс 8. Так мы явно разводим 2 продукта - NGFW и DCFW, каждый из которых будет жить самостоятельно.
Не понятен термин "фактическая производительность", уточните, пожалуйста, его значение. У NGFW можно сделать сотни конфигураций тестирования, и в каждом случае фактическая производительность может быть разной.
В среднем в 2-3 раза, в зависимости от параметра и режима работы. Как написано в статье, у F8000 2 CPU по 18 ядер каждый + 128 ГБ RAM + HDD 1 ТБ, у F8010 - 2 новых CPU AMD EPYC по 48 ядер + 256 ГБ RAM + SSD 1 ТБ (кстати, в описанных тестах испытывалась платформа с 128 ГБ RAM, позднее мы решили увеличить объем оперативки). В совокупности это дает очень серьезный рост производительности.
Сейчас тестируем бету с поддержкой IPS на FPGA, показывает до 25 Гбит/с в режиме L3/L4+IPS на EMIX, Позже комплексно протестируем в разных режимах работы. Так у нас есть протокол испытаний от августа 2024 для крупного заказчика (который потом приобрел 150 платформ, в том числе FG), где FG при 85 000 правил FW (1000 из них были с 5 элементами) и 11 000 сигнатур IPS показала 14 Гбит/с на EMIX при 20 000 000 сессий и 84 000 CPS и 21 Гбит/с если просто включить FW L3/L4.
Добрый день!
Нет, описанная в статье методика и медика тестирования ЦБ РФ различаются. За разъяснениями лучше обратиться непосредственно к первоисточнику.
Добрый день! Ответил в этой же ветке.)
Добрый день! Извините за поздний ответ. По порядку:
Тут нужно уточнить, что такое "базовая конфигурация". Уточню в пунктах ниже, возможно это снимет вопросы.
Использовалось 131 000 односложных правил: 1 src сеть с маской 24 бита, 1 dst сеть с маской 24 бита, 1 сервис. Каждое правило было уникальным. У каждого какие-то сети и сервис. Они были похожи только тем, что под них не попадал трафик генератора. Кроме последнего, 131000-го по счету правила, у которого была настройка allow all.
Нет, allow all было только у 131000-ого правила.
В описании указан EMIX-тест на FW L3/L4 + СОВ (Cyberflood), вот в нем дополнительно использовался дефолтный профиль IDPS.
Соответственно, на основании этих предпосылок мы считаем, что такие тесты позволяют оценить реальную производительность NGFW. Можно посмотреть запись с процессом этого тестирования с техническими подробностями на сайте UserGate Data Center Firewall (DCFW), начиная с 46 минуты.
Если есть сомнения в честности теста, мы можем провести для вас тестирование именно под ваши требованиями с применением генераторов трафика Breaking Point и/или Spirent Cyberflood. Можем потом написать об этом совместную статью.)