Resumen

  • RFC 5180 mide el comportamiento de un dispositivo dentro de un laboratorio definido. El resultado cambia con el tamaño de trama, la distribución de destinos, la longitud de prefijo, el estado de vecinos, el sentido del tráfico, los filtros y la versión probada.
  • Su prueba Hop-by-Hop no busca el throughput habitual: aplica 1 %, 10 % y 50 % de la interfaz y observa recursos. En el contexto posterior de RFC 8200, hay que documentar además si el nodo estaba configurado para procesar esa cabecera.

El modelo de capacidad asignó un único número a dos direcciones. La red real enviaba paquetes pequeños hacia un lado y respuestas grandes hacia el otro. Una política adicional se ejecutaba sólo en ingreso. Cuando apareció la congestión, el benchmark fue presentado como prueba de que el equipo no podía ser el problema.

La prueba no había fallado. La inferencia sí.

RFC 5180, publicado como documento informativo en 2008, complementa la metodología de RFC 2544 para dispositivos IPv6 y adopta términos de RFC 1242. No crea una propiedad abstracta llamada rendimiento IPv6. Define estímulos controlados para que los resultados sean repetibles, para que la variación quede visible y para que un conjunto pequeño de ensayos no adquiera una certeza estadística que no posee.

La capacidad necesita una distribución

En Ethernet, la metodología propone tramas de 64, 128, 256, 512, 1024, 1280 y 1518 bytes. El mismo caudal de bits puede implicar números muy distintos de decisiones por segundo. Una prueba con tramas grandes favorece la cifra de Gbit/s; una con tramas pequeñas presiona el procesamiento por paquete. Ninguna representa por sí sola una carga operacional.

Por eso el planificador necesita la curva y su correspondencia con el tráfico esperado. También necesita las hipótesis físicas. Las tasas máximas Ethernet son teóricas y admiten una desviación de reloj de más o menos 100 ppm. En Packet over SONET, el bit stuffing puede alterar la tasa de tramas. La precisión visual de un panel no supera la precisión de su método.

Los destinos forman otra distribución. Un solo par de direcciones puede mantener caliente una ruta estrecha de búsqueda. Direcciones de destino aleatorias ejercitan otro comportamiento. RFC 5180 pide ambas fases y sugiere /48, /64, /126 y /128 como fronteras de prefijo. El responsable de capacidad que recibe sólo el máximo pierde el mapa de trabajo que produjo el máximo.

Bidireccional no significa simétrico

Las pruebas deben ejecutarse en ambos sentidos. Sin embargo, el propio RFC advierte que el resultado bidireccional muestra únicamente el menor rendimiento entre las dos direcciones. Si existe asimetría, una prueba unidireccional permite localizarla.

Esta separación importa en redes con políticas de entrada y salida diferentes, respuestas más grandes que solicitudes, tablas distintas o clasificación aplicada en un solo camino. Sumar ambos sentidos puede ocultar la causa; escoger el peor puede ocultar el margen del otro. Para decidir dónde ampliar, el plan necesita los dos componentes y no sólo su resumen.

La mezcla entre IPv4 e IPv6 también cambia el mecanismo. El documento incluye perfiles IPv4-only, IPv6-only y proporciones 90/10, 50/50 y 10/90. Un valor puro de IPv6 no demuestra el comportamiento de recursos compartidos bajo coexistencia. Tampoco un ratio histórico representa automáticamente la mezcla del próximo año.

Escala de puerto es una tercera dimensión. Un ensayo de puerto único caracteriza una interfaz. Uno multiport investiga el escalado de toda la plataforma. La tela interna, la memoria o el plano de software pueden ser compartidos. Multiplicar el resultado de un puerto por el número de puertos no convierte la aritmética en evidencia.

El caso Hop-by-Hop revela el camino oculto

RFC 5180 trata por separado las cabeceras de extensión. Recomienda probar cada tipo y luego una cadena. Para comparar tráfico con y sin cabeceras en tamaños pequeños, usa un mínimo común. Así evita atribuir a la cabecera una diferencia creada por tramas desiguales.

Con Hop-by-Hop, la pregunta cambia. El probador ofrece 1 %, 10 % y 50 % del ancho de banda total y vigila recursos. No intenta hallar throughput ordinario; intenta observar el impacto de procesamiento. CPU y memoria, recogidos fuera de banda y separados de las interfaces de prueba, pueden indicar si el paquete siguió hardware, recirculó o cayó en software.

La regla histórica no debe presentarse sin fecha. RFC 5180 se escribió cuando RFC 2460 describía procesamiento en cada nodo. RFC 8200 dice después que los nodos del camino sólo se espera que examinen y procesen Hop-by-Hop cuando estén configurados explícitamente. RFC 7045 ya había señalado que routers de alto rendimiento pueden ignorarlo o enviarlo a un camino lento. RFC 9098 analiza límites de inspección, recirculación, plano de software y descarte.

Por tanto, el paquete no basta. El informe debe incluir configuración, contenido de opciones, carga, duración, política y telemetría. Un descenso de throughput es un síntoma de camino; no identifica por sí mismo hardware, software, control plane ni protección. Y una prueba limitada no certifica resistencia frente a ataques.

Los vecinos y los filtros consumen trabajo real

La metodología permite vecinos estáticos o Neighbor Discovery dinámico. Prefiere que el probador mantenga activas las cachés y sitúa los extremos simulados a un salto del dispositivo para evitar tormentas de Neighbor Unreachability Detection. Una caché fijada, una caché renovada y una expiración durante la carga son estados distintos.

Los filtros también cambian el recorrido. Si el equipo necesita encontrar información de transporte después de una cadena de cabeceras, puede activar análisis profundo o un camino diferente. Tamaño de tabla, número de filtros, tráfico de routing y gestión deben conservarse. Una prueba sin política no refuta un cuello de botella que aparece al aplicar la política necesaria para operar.

La metodología distingue además recuperación tras sobrecarga de recuperación tras reset de dispositivo o software. Y deja de recomendar back-to-back frames para IPv6 por su variación de corto plazo. No todos los números posibles son buenos indicadores.

El aislamiento es una frontera de autoridad

El banco debe ser independiente y no puede verter tráfico hacia producción ni hacia la red de gestión. La observación es externa y de caja negra; no deben existir funciones especiales dedicadas al benchmark. Son controles esenciales contra una demostración artificial.

También significan que el laboratorio no midió producción. No vio los fallos compartidos, el churn, las colas cruzadas, las actualizaciones desiguales ni el comportamiento de los usuarios. Su autoridad termina donde termina el estímulo controlado.

La dirección reservada conserva esa frontera. El RFC publicado contenía un error técnico verificado; el registro IANA actual identifica 2001:2::/48 como espacio de benchmarking, no globalmente alcanzable. La corrección ayuda a mantener la prueba dentro de su dominio.

Hay además límites de tecnología. RFC 8219 dedica otra metodología a traducción y encapsulación. Dual stack puede evaluarse con RFC 2544 y RFC 5180, pero las funciones con estado requieren preguntas sobre tablas y sobrecarga. La etiqueta IPv6 no convierte mecanismos distintos en una sola capacidad.

Una decisión basada en recibos

Antes de usar el resultado en un presupuesto, conservar: equipo y build; funciones; puertos y medio; topología; herramienta; relojes; serie de tamaños; prefijos y entropía de destino; modo de vecinos; cabeceras y opciones; filtros, rutas y control; dirección; mezcla IP; carga ofrecida; duración; repeticiones; pérdida, latencia y muestras; recursos fuera de banda; recuperación; y desviaciones del RFC.

Asignar propietarios diferentes a diseño de método, operación del laboratorio, estadística, equivalencia del release y observación de producción impide que una firma se convierta en aprobación universal. La cifra sigue siendo útil: responde exactamente a la pregunta que se le hizo. La dirección debe negarse a dejar que responda también a las preguntas que el laboratorio nunca ejecutó.

Fuentes

  1. RFC 5180 — HTML
  2. RFC 5180 — texto
  3. Página informativa del RFC Editor
  4. Documento en IETF Datatracker
  5. Historial en Datatracker
  6. Referencias en Datatracker
  7. Erratas de RFC 5180
  8. RFC 2544
  9. RFC 1242
  10. RFC 8200
  11. RFC 7045
  12. RFC 9098
  13. RFC 4861
  14. RFC 8201
  15. RFC 6890
  16. Registro IANA de direcciones IPv6 de propósito especial
  17. RFC 8219
  18. Heng Lu — capas de realidad
  19. Heng Lu — especificación mínima y adopción voluntaria
  20. Heng Lu — primacía del código en ejecución