Подвисает Pfsense 2.2.1 в составе Proxmox 3.1.2
-
http://joealdeguer.com/how-to-virtualize-pfsense-firewall-including-using-virtio-drivers/
https://forum.pfsense.org/index.php?topic=88858.0
Disable tx offloading on the pfSense interfaces on the hypervisor side and you're good to go. If you want to overkill is, disable tx offloading on the whole bridge, or all bridges.
If your bridge were to be called lan-br, you would run: sudo ethtool -K lan-br tx off
–----
I'll have read up on how to make the ethtool changes permanent. On Debian/Ubuntu, in /etc/network/interfaces, simply add:
iface vmbr0 inet static
address 192.168.121.33
netmask 255.255.255.0
gateway 192.168.121.1
post-up /sbin/ethtool -K $IFACE tx offOther distro's will have similar mechanisms.
Also: pfSense has the option to turn "Hardware Checksum Offloading" off. Check it under System: Advanced: Networking
Is it not enough to just uncheck the box in the pfsense VM for tx offloading?
–--------------------No it is not. The problem isn't with pfSense, but with packets from the other VM's not having correct checksums and getting dropped inside the netfront driver on BSD.
Packets for pfSense need to have a correct checksum before they reach any pfSense virtual interface.
-
Мы поменяли машинку, на котором стоял Pfsense: поставили напрямую без Proxmox, как итог, gateway проработал около 8 часов, потом LAN вновь отвалился.
Проблемы с портом на свитче? Мы уже пробовали менять порт.
Гуглить я тоже умею: checksum offload можно отключить через GUI в Pfsense, - если эта фича не работает, то зачем этот чекбокс нужен? В любом случае не помогло.
"Рекомендую сменить тип сетевого адаптера с паравиртуального на e1000. Проверить работоспособность" - у нас был не паравиртуальный адаптер, а e1000e, что тоже не спасло.При чём отваливается LAN в примерно одинаковое время и поднимается тоже в примерно одинаковое время, как такое может быть?
Сейчас следующие сетевые интерфейсы:
RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet - LAN
RealTek 8139 10/100BaseTX - WAN -
Сейчас следующие сетевые интерфейсы:
RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet - LAN
RealTek 8139 10/100BaseTX - WANТ.е. исп. офисные сетевые адаптеры (а тем более RealTek 8139) на "сервере" Вы хотите не иметь проблем? На пальцах объясню.
Покупая Ладу требуете от нее того же кач-ва, что пресуще Мерседесу ?Душите свое пресмыкающееся (класс Reptilia), приобретайте Intel, broadcom и живите спокойно.
P.s. Вы же гуглом Вы пользоваться умеете (?)
-
У нас небольшой офис, парк из 20 машин, малый трафик: ваши нападки не обоснованы. Шлюз работает строго в определённые часы, а потом виснит, разве это в целом проблема железа? На Ладе можно и мешки картошки возить, не требуя комфорта и скорости.
Вы не внимательны: до этого у нас был установлен сетевой адаптер Intel, драйвер e1000e, проблема возникла именно на этом железе, - так что же мне осталось установить по Вашему, чтобы получить Мерседес? Так-так, наверно broadcom, точно!
Если вы не можете дать дельный совет, то зачем хамить? Хамство удел глупцов и людей слабым духом, крепитесь, и хамство исчезнет.
К примеру, на официальном сайте для малого офиса ("The perfect entry level firewall/router for small networks and remote workers") рекомедуется железка с NIC от Realtek: https://www.pfsense.org/products/product-family.html#vk-t40e, - думаю, они вводят в заблуждение клиентов, напишите им скорей!
-
Вы не внимательны: до этого у нас был установлен сетевой адаптер Intel, драйвер e1000e, проблема возникла именно на этом железе, - так что же мне осталось установить по Вашему, чтобы получить Мерседес? Так-так, наверно broadcom, точно!
Я более чем внимателен. У вас Intel e1000e исп-ся как виртуальный адаптер для pfsense. В кач-ве физ. адаптера на Proxmox - у Вас Realtek. Разницу чувствуете ?
Если вы не можете дать дельный совет, то зачем хамить? Хамство удел глупцов и людей слабым духом, крепитесь, и хамство исчезнет.
Дал более чем дельный совет. Повторюсь еще раз - купите\арендуйте\отожмите (нужное подчеркнуть) адаптер от intel\или др. какой и проверьте.
"Хамлю" еще. Советую отключить в БИОС всю не исп. периферию - com, lpt, usb, pci и т.д. Обновите БИОС мат. платы до последней версии и после сбросьте его в default. Так же переставьте дискретную сетевую в др. pci-разъем (чтобы сменить прерывание).
P.s. За то время, что Вы здесь со мной пререкаетесь - могли бы все эти варианты проверить. Сделайте.
P.s2. И да, пытаюсь помочь Вам ,пока что, только я. Цените это.
-
Гуглить я тоже умею: checksum offload можно отключить через GUI в Pfsense, - если эта фича не работает, то зачем этот чекбокс нужен? В любом случае не помогло.
Снова читаете между строк. Это необходимо делать и на физ. интерфейсе (в debian) и на виртуальном (в pfsense). Предварительно выключив все ВМ на proxmox.
Но сперва обновить БИОС мат. платы, заменить сетевую карту и вставить ее в др. pci-слот.
P.s. И заканчивайте минусить меня втихаря ;) Проверьте все советы - не сработают, тогда честно влепите минус.
-
Спасибо за советы :)
Я не минусовал, в том смысле, я даже не знаю, как тут минусовать, а если знал бы, то мне это вряд ли помогло в решении проблемы :)Снова читаете между строк. Это необходимо делать и на физ. интерфейсе (в debian) и на виртуальном (в pfsense). Предварительно выключив все ВМ на proxmox.
- Самое смешное, что я сделал и так, и эдак :)
Я даже поменял порядок запуска сервисов в proxmox: сначала запускается OpenVZ, а затем Networking, так как proxmox зависит от gateway, который сидит в контейнере в качестве Pfesense :)
Потом, как я уже упоминал, я сменил железку и накатил pfsense без proxmox: да, NIC от Realtek, да, возможно, они не к чёрту, хотя сами ребята из pfsense выпускают железки с NIC Realtek, но, как итог, это не помогло, сменили порт на свитче, сменили свитч (воткнули в другой порт в соседний свитч), не помогло! Вывод - очень маленькая вероятность, что проблема в железе.
И самая феерия заключается в том, что pfsense оживает, как по часам - в 08:16-8:30 утра. Как такое возможно?!
Благодарю за помощь, просто я уже все варианты практически попробовал: осталось переставить всё заново, накатить самую последнюю версию pfsense, попробовать взять воткнуть навороченный NIC от Intel, к примеру, что-нибудь в этом духе http://www.intel.com/content/www/us/en/ethernet-products/gigabit-server-adapters/ethernet-server-adapter-i350.html. Если все эти танцы с бубном не помогут, то я не знаю уже, выкину этот pfsense в окно, терпение имеет свой предел :)
Ещё раз, благодарю за советы!
Но вот тут есть проблема с использование CARP-функционала, симптомы похожие (https://forum.pfsense.org/index.php?topic=93941.0), и хотя мы не задействуем CARP, то всё же последнее, что остаётся - это заменить на более свежую, последнюю версию pfsense.
- Самое смешное, что я сделал и так, и эдак :)
-
Попробуйте также 2.1.5 - последнюю из ветки 2.1.х
-
Свитчи - управляемые? Может где петля ? Кабель от провайдера идет в LAN\WAN напрямую в pf или сперва в др. уст-во ?
И самая феерия заключается в том, что pfsense оживает, как по часам - в 08:16-8:30 утра. Как такое возможно?!
Он весь день лежит? Или ложиться с периодичностью?
-
Нет, ложится LAN pfsense вечером, часов в 9-10, а просыпается в районе в 8-8:30 :)
В остальное время он работает стабильно, как часы.
Дело не в свитчах, так как до этого, вместо pfsense мы вешали на коммутатор провайдера 68 Asus для проверки скорости и качества, и также запускали его в общую сеть. А потом уже нам настроили это "добро", а мне поручили его саппорт.
Возможно, выставлен какой-то таймаут на отключение LAN или политика безопасности настроена неверно, хотя какая там политика? Обычный аналог iptables.
Просто мистика: я не перезагружал, не рестартил networking service, а просто следил, когда начнут возвращаться пакеты, и они стали возвращаться в 8:29 утра :) Должен заметить, до этого ICMP пакеты проходили раз в 5 минут с большой задержкой.Просто феерия. ;D
-
А пакет cron не установлен ли ? Может с нем есть какой-то скрипт ?
Все же не мучайтесь. Сливайте бэкап\ делайте скрины правил правил и настроек, разворачивайте с новья, проверяйте рабоспособность и только потом заливайте бэкап.
P.s . Покажите скрины правил fw (LAN\WAN). Именно скрины.
-
Cron, конечно, поставлен: под его указку крутится куча скриптов.
Вот список правил и снимок со скриптами cron: https://flic.kr/s/aHskgdKAy6.
Возможно, проблема упирается в скрипт подсчёта траффика в связке c lightsquid, SQStat и ipcad.
Попробую всё вырубить по завершению раб дня.Ещё раз спасибо за отзывчивость!
-
Не имеет отношение к проблеме, но всё же:
1. 3-е снизу правило на LAN разрешает всё.
2. Первое сверху правило на WAN уже разрешает всё. И что делает 2-е правило сверху ? -
Есть избыточность с правилами, но это ничего не объясняет, в WAN описано правило для ssh-туннеля, как я понимаю: сервак не я один "кручу".
Поставили последнюю версию 2.2.3-RELEASE (amd64) built on Tue Jun 23 16:37:42 CDT 2015 FreeBSD 10.1-RELEASE-p13 с минимальной конфигурацией, посмотрим, как он доживет до утра :)Новая версия 2.2.3 Pfsense дожила до утра.
-
Вы "на чистую" ставили 2.2.3 или обновлялись ? Если "чистая" падает, то с 90% вер-ти - железо (сетевые). Меняйте.
P.s. Очень надеюсь, что всю лишнюю перефирию в БИОС отключили и сет. карту в другой PCI-слот воткнули.
-
На чистую, всё работает вторые сутки на том же железе. =) Пока не устанавливаем лишних скриптов: максимально простая рабочая версия.
Буду разбираться со старым снимком Pfsense.Спасибо за советы!
-
На чистую, всё работает вторые сутки на том же железе. =) Пока не устанавливаем лишних скриптов: максимально простая рабочая версия.
Буду разбираться со старым снимком Pfsense.Спасибо за советы!
Отключайте по очереди скрипты (особенно - самописные) и проверяйте.
-
В общем, сменили, как я уже писал, на чистую конфигурацию (2.2.3). Как итог, проработал около 4 суток, а с утра 20 числа опять подвис. В логах попрежнему молчок. >:(
-
Подскажите что за процесс pgrep? Грузит систему на 100% в составе proxmox. Помогает перезагрузка.