«¿Cuánto ancho de banda puede gestionar
PF?»
«¿Qué características debe tener mi
máquina para gestionar mi conexión a Internet?»
No existen respuestas concretas para estas preguntas. Para algunas
aplicaciones, un 486/66 con un par de NIC (tarjeta de interfaz de red)
ISA de buena calidad pueden filtrar y gestionar NAT a unos 5Mbps, pero
para otras aplicaciones podría no ser suficiente una
máquina mucho más rápida con unas NIC PCI mucho
más eficientes. La cuestión no es la cantidad de bits por
segundo, sino la cantidad de paquetes por segundo y la complejidad del
grupo de reglas.
El rendimiento de PF se determina mediante algunas variables:
El número de paquetes por segundo. La cantidad de
procesamiento necesaria para un paquete con 1500 bytes de carga
útil es casi la misma que para un paquete con un byte de carga
útil. El número de paquetes por segundo determina el
número de veces que hay que evaluar la tabla de estado y, en caso
de no econtrar ahí la concordancia, las reglas de filtrado
tendrán que ser evaluadas cada segundo, lo que a su vez determina
la demanda efectiva en el sistema.
El rendimiento del bus del sistema. El bus ISA tiene
un ancho de banda máximo de 8MB/s, y cuando está siendo
accedido por el procesador tiene que disminuir hasta la velocidad
efectiva de un 80286 a 8MHz, sin que importe lo rápido que pueda
ser en realidad el procesador. El bus PCI tiene un ancho de
banda efectivo mucho mayor, y el impacto del procesador es menor.
La eficiencia de la tarjeta de red. Algunas adaptadoras de red son
más eficientes que otras. Las tarjetas basadas en Realtek 8139
(rl(4))
tienden a ofrecer un rendimiento relativamente pobre, mientras que las
tarjetas basadas en Intel 21143
(dc(4))
tienden a ofrecer un rendimiento bastante bueno. Para obtener un
máximo de rendimiento, hay que considerar el uso de las tarjetas
gigabit Ethernet, aun cuando no se vaya a conectar a redes gigabit, ya
que disponen de una memoria mucho más avanzada.
La complejidad y el diseño del grupo de reglas. Cuanto
más complejo sea el grupo de reglas, más lento
funcionará. Cuantos más paquetes se filtren con
keep state y quick, mejor será el rendimiento.
Cuantas más líneas deban ser evaluadas por cada paquete,
más bajo será el rendimiento.
También hay que mencionar la CPU y la RAM. Como PF es un
proceso basado en el núcleo del sistema, no usa espacio de
memoria de intercambio (swap). Por lo tanto, si tenemos
suficiente RAM funcionará, pero en caso contrario generará
estados de pánico a causa del agotamiento de
pool(9).
No son necesarias enormes cantidades de RAM; 32MB deberían ser
suficientes para unos 30.000 estados, que son muchos estados para una
aplicación en una pequeña oficina o en casa. La
mayoría de usuarios se encontrarán con que una
máquina «reciclada» es más que suficiente para
un sistema de filtros PF; un sistema con 300MHz moverá un gran
número de paquetes con rapidez, siempre que esté
respaldado con unas buenas NIC y un buen grupo de reglas.
Los usuarios suelen preguntar por bancos de pruebas para PF. El
único banco de pruebas digno de tener en cuenta es el rendimiento
del propio sistema en el propio entorno. Un banco de
pruebas que no replique nuestro entorno no nos ayudará a planear
correctamente nuestro sistema de cortafuegos. Lo mejor que podemos
hacer para obtener un banco de pruebas de PF es simular nosotros mismos
un entorno con las mismas condiciones de red -o lo más parecidas
que sea posible- que experimentaría el cortafuegos real, y en el
mismo hardware que usaría el cortafuegos.
PF se usa en algunas aplicaciones muy grandes con mucho tráfico,
y los mismos desarrolladores son usuarios de PF que requieren gran
potencia. Lo más seguro es que el funcionamiento para un usuario
normal sea excelente.
![[Índice]](../../../images/back.gif){kind=small}
![[OpenBSD]](../../../images/smalltitle.gif){kind=small}