¿Alguien más está usando OpenBSD como enrutador en la empresa? ¿En qué hardware lo estás ejecutando? [cerrado]


26

Tenemos un enrutador OpenBSD en cada una de nuestras ubicaciones, que actualmente se ejecuta en hardware genérico para PC "homebrew" en una caja de servidor 4U. Debido a problemas de confiabilidad y consideraciones de espacio, estamos buscando actualizarlos a un hardware adecuado para servidores con soporte, etc.

Estas cajas sirven como enrutadores, puertas de enlace y firewalls en cada sitio. En este punto, estamos bastante familiarizados con OpenBSD y Pf, por lo que dudamos en alejarnos del sistema a algo más, como el hardware dedicado de Cisco.

Actualmente estoy pensando en trasladar los sistemas a algunas máquinas HP DL-series 1U (modelo aún por determinar). Tengo curiosidad por saber si otras personas usan una configuración como esta en sus negocios, o si han migrado a una o desde otra.


1
Encontré que las respuestas nos ayudaron, ya que hemos estado ejecutando bsd abierto durante 9 años y comencé a pensar en cambiar a jos debido a problemas de alimentación en el centro de datos. Ahora lo pensaré nuevamente, ya que creo que hemos infravalorado los beneficios de ejecutar en una plataforma abierta.

Respuestas:


43

Ejecutamos exclusivamente enrutadores / cortafuegos de OpenBSD para servir FogBugz On Demand. A menos que esté operando en una función de tránsito y necesite el rendimiento pps extremadamente alto que puede proporcionar el hardware y el software integrado especialmente diseñados, OpenBSD en hardware sólido será una solución más manejable, escalable y económica.

Comparando OpenBSD con IOS o JUNOS (en mi experiencia):

Ventajas

  • El cortafuegos pf no tiene comparación en términos de flexibilidad, configuración manejable e integración en otros servicios (funciona a la perfección con spam, ftp-proxy, etc.). Los ejemplos de configuración no le hacen justicia.
  • Obtiene todas las herramientas de a * nix en su puerta de enlace: syslog, grep, netcat, tcpdump, systat, top, cron, etc.
  • Puede agregar herramientas según sea necesario: iperf e iftop me han parecido muy útiles
  • tcpdump. Basta de charla.
  • Configuración intuitiva para veteranos de Unix
  • Integración perfecta con la gestión de configuración existente (cfengine, puppet, scripts, lo que sea).
  • Las características de la próxima generación son gratuitas y no requieren módulos adicionales.
  • Agregar rendimiento es barato
  • Sin contratos de soporte

Desventajas

  • IOS / JUNOS simplifica el volcado / carga de una configuración completa. En ausencia de herramientas de administración de configuración, serán más fáciles de implementar una vez que se haya escrito su configuración.
  • Algunas interfaces simplemente no están disponibles o son estables en OpenBSD (p. Ej., No conozco tarjetas ATM DS3 compatibles).
  • Los dispositivos tipo Cisco / Juniper dedicados de alta gama manejarán pps más altos que el hardware del servidor
  • Sin contratos de soporte

Siempre que no esté hablando de enrutadores de red troncal en un entorno similar a un ISP o enrutadores de borde que interactúan con conexiones de red especializadas, OpenBSD debería estar bien.

Hardware

Lo más importante para el rendimiento de su enrutador son sus NIC. Una CPU rápida se abrumará rápidamente con una carga moderada si tiene NIC de mierda que interrumpen por cada paquete que reciben. Busque NIC gigabit que admitan la mitigación / fusión de interrupciones al menos. He tenido buena suerte con los controladores Broadcom (bge, bnx) e Intel (em).

La velocidad de la CPU es más importante que en el hardware dedicado, pero no es algo de lo que preocuparse. Cualquier CPU moderna de clase de servidor manejará una tonelada de tráfico antes de mostrar cualquier tensión.

Consiga una CPU decente (los múltiples núcleos no ayudan mucho todavía, así que mire los GHz sin procesar), una buena RAM ECC, un disco duro confiable y un chasis sólido. Luego duplique todo y ejecute dos nodos como un clúster CARP activo / pasivo. Desde la actualización pfsync de 4.5 puede ejecutar active / active, pero no lo he probado.

Mis enrutadores se ejecutan lado a lado con nuestros equilibradores de carga en configuraciones de nodo doble de 1U. Cada nodo tiene:

  • Chasis Supermicro SYS-1025TC-TB (NIC Intel Gigabit incorporadas)
  • CPU Xeon Harpertown Quad Core 2GHz (mis equilibradores de carga usan los núcleos múltiples)
  • 4 GB de RAM registrada Kingston ECC
  • NIC de complemento Intel Gigabit de doble puerto

Han sido sólidos como una roca desde el despliegue. Todo sobre esto es excesivo para nuestra carga de tráfico, pero he probado un rendimiento de más de 800 Mbps (limitado por NIC, la CPU estaba inactiva en su mayoría). Hacemos un uso intensivo de las VLAN, por lo que estos enrutadores también deben manejar una gran cantidad de tráfico interno.

La eficiencia energética es fantástica ya que cada chasis de 1U tiene una sola fuente de alimentación de 700W que alimenta dos nodos. Hemos distribuido los enrutadores y equilibradores a través de múltiples chasis para que podamos perder un chasis completo y tener una conmutación por error prácticamente ininterrumpida (gracias pfsync y CARP).

Sistemas operativos

Algunos otros han mencionado el uso de Linux o FreeBSD en lugar de OpenBSD. La mayoría de mis servidores son FreeBSD, pero prefiero enrutadores OpenBSD por algunas razones:

  • Un enfoque más estricto en seguridad y estabilidad que Linux y FreeBSD
  • La mejor documentación de cualquier sistema operativo de código abierto
  • Su innovación se centra en este tipo de implementación (consulte pfsync, ftp-proxy, carp, vlan management, ipsec, sasync, ifstated, pflogd, etc., todos los cuales están incluidos en la base)
  • FreeBSD tiene varios lanzamientos atrás en su puerto de pf
  • pf es más elegante y manejable que iptables, ipchains, ipfw o ipf
  • Proceso de instalación / instalación más eficiente

Dicho esto, si está íntimamente familiarizado con Linux o FreeBSD y no tiene tiempo para invertir, probablemente sea una mejor idea ir con uno de ellos.


Gracias por la respuesta extremadamente detallada. Lo que usted describe es exactamente el tipo de sistema que estamos buscando construir, un par de servidores con GigE dual integrado y una NIC de complemento GigE dual en una configuración de conmutación por error CARP. Es muy tranquilizador ver que alguien más está ejecutando dicha configuración en un sistema de producción importante.
Kamil Kisiel

1
Personalmente prefiero iptables, creo que pf está demasiado restringido. Mi experiencia con CARP en OpenBSD es que es excelente cuando desea realizar trabajos planificados (conmutación por error planificada), pero la conmutación por error a menudo no funcionará cuando hay una falla real. He tenido exactamente una exitosa conmutación por error de pf, y esto fue con OpenBSD 4.5. Además, la situación de soporte para OpenBSD es pésima. Si no tiene el conocimiento interno o no le paga a alguien, la respuesta a todas las preguntas o apoyo cuando se bloquea es: "tu madre está gorda".
Thomas

1
Ejecuto pf / pfsync / CARP dos firewalls en una configuración de conmutación por error. Experimenté dos situaciones de conmutación por error y, en ambos casos, solo me enteré por mi sistema de monitoreo y me dijo que uno de los firewalls estaba inactivo. Los servicios del clúster continuaron sin interrupción notable.
Insyte

8

pfsense es un excelente firewall basado en FreeBSD, tiene muchas funciones, es fácil de configurar y tiene una comunidad activa y opciones de soporte. Hay varias personas que lo usan en situaciones comerciales / de producción que están activas en el foro. Lo uso en casa y lo estoy presionando en el trabajo, es una alternativa muy bien organizada. ¡Incluso tienen una imagen de VM para descargar con la que probarla!


Miré ese enlace. esa variante de MonoWall se ve muy bien. :-)
djangofan

Creo que mono se enfoca en hardware embebido, mientras que pfsense se enfoca en sistemas basados ​​en PC. Creo que estaba destinado a ofrecer características más avanzadas / de clase empresarial que las que se encuentran en m0n0wall u otras distribuciones de firewall básicas.
Chance

2

Donde trabajo estamos usando RHEL5 + quagga y zebra en 4 cajas para ejecutar el tránsito a 450mbps. Entonces, sí, puede hacerlo en la empresa y ahorrar mucho dinero.

Hacemos limitación de velocidad usando TC y hacemos uso de iptables y reglas de notrack.


2

Utilicé OpenBSD 3.9 como firewall y cambié a Juniper SSG5.

Como dijo sh-beta OpenBSD como MUCHAS buenas características: pf es increíble, tcpdump, muchas buenas herramientas ...

Tenía algunas razones para cambiar a Juniper. En particular, la configuración es rápida y fácil. En OpenBSD todo es "un poco complicado".

por ejemplo: la gestión del ancho de banda es, en mi opinión, mucho más fácil de configurar en el SSG.

La versión de OpenBSD que utilicé era bastante antigua; Quizás la versión más nueva sea mejor en este punto.


En el lado del hardware, mi caja OpenBSD era una vieja Dell GX280.
Matthieu

1

Para la pequeña empresa de mi padre con una sucursal, utilizo OpenBSD como enrutador / puerta de enlace / firewall tanto para la sucursal principal como para la principal. Nunca nos ha decepcionado. Utilizamos un servidor Dell Tower en cada ubicación. Cada servidor está equipado con una tarjeta Dual GiGE, 8GB de ram (excesivos, lo sé) y funciona bien. La sucursal está configurada para conectarse a la principal a través de IPSEC y la implementación de IPSEC de OpenBSD es deliciosamente fácil de usar.


1

Las puertas de enlace de OpenBSD se utilizan en muchas configuraciones empresariales. Tenemos dos puertas de enlace OpenBSD en nuestras redes.

Todavía recuerdo un episodio divertido con OpenBSD: el disco duro se murió, pero la puerta de enlace simplemente continuó enrutando el tráfico, como si nada hubiera pasado, sirviendo solo desde la memoria. Me dio algo de tiempo para configurar otra instancia.

Requisitos de hardware muy bajos, los Dual Opteron 248 son geniales. Raramente veo que la CPU supere el 5%. Son muy estables. Lo he estado usando hace poco más de 7 años sin problemas.


1

He estado ejecutando OpenBSD (4.9) en producción en nuestro firewall principal durante bastante tiempo. Es un ASUS MB bastante antiguo con 2 GB de RAM DDR (1) y un Athlon de doble núcleo (2 GHz). Compré una tarjeta Intel de cuatro puertos (pci-express) y la usé en el puerto de gráficos x16. NO deseche sus tarjetas gráficas PCI si tiene alguna por ahí. Lo necesitará como una tarjeta gráfica si planea usar el puerto PCI-express 16x para la NIC (el gfx incorporado no funcionó en mi caso).

Sé que no es hardware de "clase empresarial". pero estos son los claros beneficios de esta configuración:

  • Tengo muchos de estos MB por ahí y, por lo tanto, nunca se quedarán sin piezas de repuesto (preparándose para CARP también).

  • ¡Los bords AMD más baratos son compatibles con ECC RAM !.

  • Todo el hardware / repuestos son "del estante" baratos y estables

  • ¡El rendimiento en estos equipos es excelente (4x Gbps), incluso para nuestra configuración de hosting bastante pesada!


0

Lo tengo en el pasado. Lo instalé originalmente en algunas PC "whitebox", luego lo actualicé a un Dell Power Edge 2950. Fuentes de alimentación redundantes, discos duros: una gran mejora desde el punto de vista de la confiabilidad. No fue una mejora observada, por supuesto, tuvimos suerte y la caja blanca nunca se bloqueó, pero en teoría estábamos en mejor forma con más redundancia.

Solo lo estábamos usando para filtrar paquetes en un T1, por lo que no es una mejora notable en el rendimiento.


0

¿Consideró cambiar a FreeBSD? OpenBSD no puede utilizar completamente los sistemas SMP modernos (es decir, Core2Quad). FreeBSD tiene pf e ipfw que puede usar simultáneamente y también tiene una capa de red no GIGANTE.

Hemos estado ejecutando enrutadores de software FreeBSD como puertas de enlace de ISP durante años, esto nos ahorró muchos $$


0

No puedo hablar por * BSD (todavía ... dame tiempo ...) pero llevamos más de 10 años ejecutando enrutadores Linux y me encantan. Más barato, sin problemas de licencia, y si mira los documentos encontrará que tiene la mayoría de las herramientas que necesita para hacer las cosas. Sospecharía que BSD está muy en el mismo barco.

Estamos ejecutando un DL365 G1 con un solo socket de procesador lleno y 6 Gb, aunque la RAM es principalmente para el servicio de buzones ...


0

Utilice las NIC Intel (em) Gigabit Server.

Una tarjeta que funciona bien es la HP NC360T. Es de doble puerto y pci-express.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.