AK
Кто нить занимался настройкой резервирования производительности шлюза так, чтобы при резком росте трафика шлюз не отваливался от менеджемента? Планирую вынести fwd и cpd на отдельное ядро используя sim affinity
Size: a a a
2020 October 19
AK
Сделать тюнинг как у "взрослых" железок
AK
Шлюзы у нас стоят на мониторинге и произошел случай, когда кто то накосячил с маршрутизацией и трафик за минуту вырос в 3 раза. Мы даже понять не успели что происходит.
AK
Есть ли подводные камни? Кроме снижения общей производительности устройства из-за удаления 1-го ядра из обработки трафика.
AK
Так как в лабе это все прекрасно работает, а вот по реальной нагрузкой не понятно как себя поведет. Может кто-то такое уже делал?
A
Смотрел на статейку Management Data Plane Separation?
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk138672
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk138672
ND
Коллеги, добрый день.
а какое устройство ? там может и выделять нечего ?
ND
это актуально для устройств где ядер cpu больше 10 штук на мой взгляд
ND
есть хороший lifehack использовать bond из нескольких интерфейсов
AK
Это open server
AK
есть хороший lifehack использовать bond из нескольких интерфейсов
Да в том то и дело, что утилизировались все 4 ядра на 100%
AK
а какое устройство ? там может и выделять нечего ?
Вопрос с увеличение количества ядер в процессе, но заказчик хочет подстраховаться. Пока оптимизировали ему базу правил, загрузка немного спала.
AK
Смотрел на статейку Management Data Plane Separation?
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk138672
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk138672
Амир, спасибо! Полезная статья
ND
Да в том то и дело, что утилизировались все 4 ядра на 100%
В этом кейсе есть более жёсткие механизму можно ограничить количество одновременных tcp сессий , но надо очень аккуратно подбирать порог, лишний траффик будет отбрасываться от слова совсем
AK
В этом кейсе есть более жёсткие механизму можно ограничить количество одновременных tcp сессий , но надо очень аккуратно подбирать порог, лишний траффик будет отбрасываться от слова совсем
Мы вообще хотим защититься от бродкаст шторма, что собственно и произошло.
VC
хм.. . а на активке это уже не модно делать?
AK
хм.. . а на активке это уже не модно делать?
Это незыблемое правило, но ни кто не застрахован от случайностей. Например обновление софта.
2020 October 20
SK
Коллеги, добрый день!
А кто-то сталкивался с неверной маршрутизацией пакетов?
Чек маршрутизирует две подсети с "белыми" адресами, обе помечены как DMZ.
Пакет от SRV A уходит до SRV B, но примерно половина исходящих пакетов почему-то вылетает через тот же интерфейс что пришла. При этом их не ловит даже правило в которм явно указана исходящая сеть, не зона.
А кто-то сталкивался с неверной маршрутизацией пакетов?
Чек маршрутизирует две подсети с "белыми" адресами, обе помечены как DMZ.
Пакет от SRV A уходит до SRV B, но примерно половина исходящих пакетов почему-то вылетает через тот же интерфейс что пришла. При этом их не ловит даже правило в которм явно указана исходящая сеть, не зона.
SK
Есть предположение что это началось после апгрейда на 80.40 и GAIA 3.10. Нашёл вот такую статейку https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk168881 но не уверен что это поможет.
AK
в JHF 83 :
In some scenarios, when VPN blade or ISP Redundancy are used, traffic may be routed to the wrong interface. Refer to sk168881.
In some scenarios, when VPN blade or ISP Redundancy are used, traffic may be routed to the wrong interface. Refer to sk168881.