Un número entero de 32 bits puede almacenar valores hasta 4.294.967.295. En el contexto de velocidades de red, eso equivale a aproximadamente 4,29 Gbps. Durante años, esa fue la barrera invisible del filtro de paquetes de OpenBSD (PF): sus campos de control de ancho de banda estaban definidos como enteros de 32 bits, lo que hacía imposible configurar colas que superaran ese límite de forma nativa. Para redes de 10G, 25G o 100G, eso es un problema real.
En marzo de 2026, un parche extendió esos campos a 64 bits. La nueva capacidad teórica es de hasta 999 Gbps. No es solo una actualización de número: es el fin de una limitación arquitectónica que llevaba años obligando a administradores de sistemas a usar workarounds incómodos para hacer traffic shaping en enlaces modernos de alta velocidad.
¿Qué es PF y por qué importa el traffic shaping?
PF (Packet Filter) es el firewall por defecto de OpenBSD —un sistema operativo conocido por su énfasis en seguridad, código limpio y auditoría rigurosa. PF no es solo un firewall: también hace traffic shaping, que es la capacidad de controlar cómo se distribuye el ancho de banda entre distintos tipos de tráfico. Puedes decirle: “reserva el 30% del ancho de banda para VoIP, limita el tráfico de backup a 500 Mbps, y deja el resto para navegación HTTP”. Eso se logra con colas de prioridad.
Claude Desbloqueado
Mi curso avanzado para aprender a sacarle mucho más provecho a Claude en el trabajo y en el día a día, con funciones y usos más potentes. Comienza el 23 de marzo.
→ Inscríbete hoy 🚀El algoritmo que OpenBSD usa para esto se llama HFSC (Hierarchical Fair Service Curve). Sin entrar en los detalles matemáticos: permite construir jerarquías de colas con garantías de ancho de banda mínimo y máximo, con soporte para prioridad en condiciones de congestión. Es una forma sofisticada de asegurar que el tráfico crítico no compita en igualdad de condiciones con el tráfico de baja prioridad.
El problema era que los campos que definían los límites de ancho de banda en esas colas eran de 32 bits. Si intentabas configurar una cola con un límite de 10 Gbps, PF no lo representaba correctamente. En la práctica, cualquier configuración de shaping en interfaces modernas de alta velocidad requería trucos: dividir el tráfico en múltiples colas virtuales, usar interrupt balancing manual, o simplemente aceptar que el shaping no funcionaría como debería por encima de 4 Gbps.
El parche: de 32 a 64 bits
El cambio técnico es quirúrgico: los campos de ancho de banda en las estructuras de control de PF ahora usan enteros de 64 bits (uint64_t en lugar de uint32_t). Eso eleva el techo teórico a más de 18 exabytes por segundo —un número que en la práctica la documentación limita a 999 Gbps para evitar confusiones, pero que en cualquier caso resuelve todos los casos de uso reales actuales y los que se puedan prever en el futuro cercano.
La documentación de pf.conf(5) fue actualizada para reflejar los nuevos límites. Los changelogs en undeadly.org —el sitio de noticias de la comunidad OpenBSD— documentan el cambio con detalle técnico.
Para sistemas que ya usan PF con shaping, la migración debería ser transparente: las configuraciones existentes siguen funcionando. La diferencia está en que ahora puedes definir colas con límites de 10G, 25G o 100G sin necesidad de workarounds.
Por qué esto importa en 2026
OpenBSD tiene un nicho claro: routers, firewalls, y servidores donde la seguridad y la corrección del código importan más que tener el software más popular. Se usa en infraestructura de ISPs, equipos de red empresariales, y como firewall perimetral en entornos donde la auditoría del código es no-negociable.
En esos entornos, las interfaces de 10G son estándar hace años. Las de 25G y 100G son cada vez más comunes en centros de datos. Tener un tope de 4 Gbps en el traffic shaping era como tener un semáforo que solo funciona hasta 60 km/h en una autopista. Técnicamente presente, pero irrelevante para el tráfico real.
El parche habilita casos de uso que antes requerían soluciones de terceros o hardware especializado: shaping de tráfico en enlaces de backbone de ISP, control de QoS en redes de videoconferencia de alta resolución, limitación de tasas en plataformas SaaS con múltiples tenants compartiendo infraestructura de red, y balanceo de tráfico en clusters con múltiples interfaces 25G o 100G.
Para quien ya usa OpenBSD en infraestructura de alto rendimiento, esto elimina una razón concreta para considerar alternativas. Si estás evaluando si OpenBSD sirve para tu stack de red y el traffic shaping era el bloqueador, ahora ya no lo es.
Contexto: OpenBSD y su filosofía de parches pequeños
Vale notar que este parche es representativo del estilo de desarrollo de OpenBSD: cambio quirúrgico, bien justificado, con impacto claro y sin efectos secundarios obvios. No es una reescritura de PF —es una extensión de los tipos de datos que eliminan una limitación sin cambiar la lógica existente.
OpenBSD ha estado expandiendo su stack de red de otras formas también: versiones recientes mejoraron el soporte para multi-threading en PF y el manejo de interrupciones en tarjetas de red modernas como Intel 82599 y adaptadores AMD EPYC de alto número de colas. El parche de 64 bits se inserta en esa línea de mejoras progresivas.
Para quien trabaja en infra de red con requisitos de seguridad estrictos, OpenBSD sigue siendo una opción seria. El debate sobre qué sistema operativo usar en ese contexto —OpenBSD vs. Linux con nftables vs. FreeBSD con ipfw— tiene múltiples variables. Pero este cambio específico resuelve uno de los argumentos concretos contra OpenBSD en entornos de alta velocidad. Si quieres comparar cómo otras iniciativas están repensando la arquitectura de redes a nivel más fundamental, el trabajo de SCION para reemplazar BGP da un contexto más amplio sobre hacia dónde apunta la comunidad de seguridad de redes.
