En esta página
Puntos clave
- Registrar ambas dimensionesGbit/s mide bits por segundo; paquetes/s cuenta los paquetes procesados.
- Indicar la frontera de medidaUn contador de bytes IP, otro de tramas Ethernet y una estimación del enlace no son intercambiables.
- Guardar la evidencia junto a la cifraTamaños, dirección, funciones activas y pérdidas permiten interpretar el resultado.
Dos contadores describen exigencias distintas
Gbit/s expresa una tasa de bits y paquetes/s cuenta paquetes a lo largo del tiempo. Un enlace transporta bytes, pero el reenvío y filtrado también hacen trabajo por paquete: análisis, búsquedas, colas, contadores y seguimiento de estado. Por eso importa el tamaño al comparar dos patrones de tráfico.
Registre intervalo y dirección de cada valor. Un pico de recepción de un segundo no se compara directamente con un promedio de cinco minutos en ambos sentidos. Un agregado de varios enlaces puede contar el mismo tráfico más de una vez. Antes de atribuir un incidente a la capacidad, determine qué cuenta el gráfico.
Un ancho de banda bajo no excluye un límite de procesamiento de paquetes. Uno elevado tampoco demuestra que el CPU sea el límite. Relacione tasas con pérdidas, presión en colas y comportamiento aplicativo en la frontera relevante.
Usar una definición explícita de trama para convertir
El calculador Peeryx emplea la longitud de trama Ethernet con FCS y añade 20 tiempos de byte para preámbulo, delimitador inicial e intervalo entre tramas. Con esta convención: PPS = bits/s ÷ [8 × (bytes de la trama + 20)].
Es una operación sobre la tasa del enlace para un tamaño dado, no rendimiento útil de aplicación ni una prueba de hardware. Un contador IP puede omitir cabeceras Ethernet y FCS. Una captura también puede omitir FCS o mostrar efectos de descarga de procesamiento. Aplicar la fórmula a un contador sin explicar no lo convierte en una medida.
Las etiquetas VLAN, la encapsulación y las mezclas de tamaños cambian el cálculo. Conserve la definición junto a la cifra y utilice una distribución representativa para planificar tráfico real. Un tamaño medio único puede ocultar intervalos breves dominados por paquetes pequeños.
Dos ejemplos hipotéticos con operaciones reproducibles
Son ejemplos de cálculo, no incidentes de clientes ni mediciones de Peeryx. A 10 Gbit/s, las tramas Ethernet de 64 bytes ocupan 84 tiempos de byte cada una con esta convención: unos 14,88 millones de tramas por segundo. A igual tasa de bits, las tramas de 1.518 bytes ocupan 1.538 tiempos de byte y producen aproximadamente 0,81 millones de tramas por segundo.
El flujo de tramas pequeñas contiene unas 18,3 veces más tramas a igual tasa del enlace. Eso no predice un incremento idéntico de CPU: importan implementación, funciones, distribución y hardware. Sí muestra por qué el ancho de banda no basta para comparar cargas.
Otra comparación hipotética: 12 millones de tramas de 64 bytes por segundo representan 8,064 Gbit/s en el enlace con esta convención. Si un gráfico muestra otra cifra, compare primero muestreo, dirección y frontera de bytes. No invente un límite del equipo para hacer coincidir dos contadores distintos.
| Tasa hipotética del enlace | Trama Ethernet con FCS | Trama más 20 tiempos de byte | Tasa teórica |
|---|---|---|---|
| 10 Gbit/s | 64 bytes | 84 tiempos de byte | 14,88095 Mpps |
| 10 Gbit/s | 1.518 bytes | 1.538 tiempos de byte | 0,81274 Mpps |
| 100 Gbit/s | 64 bytes | 84 tiempos de byte | 148,80952 Mpps |
Localizar la primera restricción del recorrido
Compare utilización aguas arriba, pérdidas físicas, colas NIC, recursos de reenvío y síntomas aplicativos en el mismo intervalo. Si se pierden paquetes antes del host, un ajuste de aplicación no los recupera. Si una cola se satura con margen en el enlace, un puerto más rápido no necesariamente corrige esa cola.
El promedio de CPU puede ocultar un reparto desigual. Examine datos por núcleo o cola e identifique el camino de recepción utilizado. RSS y otros mecanismos Linux distribuyen el trabajo de forma distinta; los cambios deben adaptarse al controlador, NIC virtual o física y aplicación. Más colas no mejoran automáticamente el resultado.
Nuevas conexiones, fragmentos y tráfico que activa reglas costosas pueden ejercer presión que paquetes/s no describe por completo. Conserve funciones activas y características del tráfico en el registro. Una cifra medida sin filtrado no representa capacidad de filtrado.
Aplicar la mitigación donde pueda aliviar la restricción
Si el enlace aguas arriba es la restricción, el tráfico debe reducirse antes de atravesarlo para conservar capacidad útil. El filtrado local puede cumplir otra función, pero no transporta paquetes a través de un enlace saturado. El tránsito protegido y el desvío bajo demanda tienen condiciones de entrega y activación propias.
Si el procesamiento de paquetes es el límite, estudie el trabajo evitable y las necesidades legítimas. Filtrar antes, simplificar reglas o distribuir de otra forma puede ayudar, siempre con una aceptación medida. Una regla que elimina muchos paquetes también puede eliminar tráfico legítimo si es demasiado amplia.
Defense Fabric es software para equipos compatibles controlados por el operador; la licencia y los puertos declarados no constituyen una prueba Mpps universal. Servidor, funciones y recorrido determinan qué validar. Distinga esto de la capacidad de red compartida del proveedor.
Definir un plan de pruebas interpretable
Utilice un entorno aislado y autorizado para pruebas de sobrecarga. RFC 6815 limita expresamente las metodologías RFC 2544 en redes de producción. La observación ordinaria de servicios y una aceptación aplicativa autorizada tienen un objetivo distinto de llevar un equipo hasta la pérdida.
Registre versiones de hardware y software, dirección, tráfico ofrecido y recibido, tamaños o distribución, diversidad de flujos, reglas, duración y pérdidas. Conserve resultados aplicativos junto a los contadores. Indique lo no probado, incluidas dependencias de host, enlace y conmutación.
Un resultado reproducible respalda una configuración concreta bajo condiciones definidas. Una etiqueta de puerto, una ejecución breve y una conversión teórica permiten conclusiones más limitadas. Mantenga esas diferencias visibles al comprar o dimensionar.
Evitar conclusiones que los contadores no respaldan
- No compare bytes IP con una estimación Ethernet del enlace sin conciliar las fronteras.
- No sume recepción y transmisión para presentar el total como capacidad en un único sentido.
- No deduzca un resultado para paquetes pequeños de una prueba con paquetes grandes, ni filtrado de reenvío sin filtros.
- No describa un ejemplo calculado como un incidente de cliente observado o una medición de software.
- No suponga que un puerto mayor resuelve una cola, tabla de estados o aplicación saturada.
Preguntas sobre tasa de paquetes y capacidad de protección
¿Una cifra Mpps mayor siempre significa mejor protección?
Solo permiten compararlo medidas equivalentes. Revise tamaño y mezcla, dirección, funciones, pérdidas y condiciones. Un techo teórico del enlace y una capacidad de filtrado medida responden a preguntas diferentes.
¿Puedo convertir Gbit/s en Mpps sin un tamaño de paquete?
No en un único valor significativo. Necesita tamaño o distribución y una convención explícita de bytes. Si desconoce la distribución real, utilice un rango de tamaños pertinentes.
¿Mide el calculador mi servidor?
No. Realiza operaciones transparentes con los valores introducidos. La capacidad de servidor y filtrado necesita mediciones separadas con configuración y criterios de aceptación definidos.
