Resumen

  • RFC 9764 permite ampliar hasta un tamaño configurado la carga de transporte que contiene un PDU BFD. El relleno es cero y, con IPv4, Don't Fragment debe estar activo; Up pasa a ser evidencia recurrente de que ese tráfico llegó con ese tamaño.
  • La evidencia no cubre automáticamente el sentido inverso ni todos los miembros LAG o ECMP. Para una conclusión bidireccional hacen falta dos configuraciones, y el flujo BFD puede seguir por un miembro sano mientras otro descarta tráfico grande.
  • El mayor requisito entre varios clientes BFD debe gobernar la sesión compartida. Por ello, cambiar pdu-size puede derribar una sesión que ya estaba Up y activar decisiones de otros clientes antes de distinguir MTU real, rechazo del par, filtro o ataque.

El primer panel decía “conectividad normal”. El segundo mostraba reintentos de una aplicación cada vez que el datagrama superaba cierto tamaño. No había contradicción. Los dos instrumentos habían preguntado cosas distintas: BFD había enviado paquetes pequeños; la aplicación necesitaba paquetes mayores.

RFC 9764 introduce una forma de acercar ambas preguntas sin fingir que son idénticas. Su mecanismo hace más grande la envoltura de transporte de BFD durante el modo Asynchronous. Así, la máquina de estados deja de comprobar solo que pasa un pequeño control periódico y empieza a comprobar también un suelo de tamaño elegido por el operador.

La variable se llama bfd.PaddedPduSize. Los bytes adicionales deben contener cero y el receptor no debería tratarlos como un nuevo campo que validar. Para IPv4, el bit Don't Fragment debe estar activo. Si el paquete no cabe, no puede superar el ensayo mediante fragmentación silenciosa.

Hasta aquí, la regla es compacta. El riesgo aparece cuando la organización traduce “llegó este paquete” como “está certificada toda la ruta”.

El número configurado responde una pregunta mínima

La base de la máquina de estados sigue siendo RFC 5880. RFC 9764 no crea un estado MTU distinto ni cambia el contenido lógico del PDU. Si el receptor deja de ver los controles grandes, aplica el procedimiento normal por ausencia de paquetes y la sesión puede pasar a Down.

Up a 1.500 bytes no significa “el Path MTU es 1.500”. Significa que los controles BFD de 1.500 bytes observados han llegado por el tratamiento que recibieron. Es un límite inferior probado, no un máximo encontrado. Si el camino acepta 4.000 bytes, la sesión no lo descubre. Si la capacidad aumenta mañana, tampoco cambia de estado.

RFC 1191 cuenta otra historia: el emisor aprende una estimación asociada a una ruta y la reduce ante evidencia de que un datagrama no cabe. RFC 8899 define un marco de descubrimiento por sondeo para transportes de datagramas. RFC 9764 no sustituye esas técnicas ni explora una escala de tamaños. Mantiene una condición concreta que un cliente ha declarado necesaria.

Esa diferencia cambia la política de configuración. La MTU de una interfaz local no debe copiarse automáticamente a pdu-size. Una interfaz jumbo puede terminar en un camino estrecho. Una aplicación puede necesitar mucho menos que el máximo local. Elegir una cifra mayor de la necesaria transforma capacidad teórica en riesgo de disponibilidad; elegir una menor mantiene verde un control que no representa el requisito.

El sentido de vuelta no cabe en una casilla verde

Para decir que el tamaño funciona en los dos sentidos, RFC 9764 exige configurarlo en ambas puntas. El paquete de A a B prueba la recepción en B; no prueba que un paquete equivalente de B a A pase por la ruta inversa.

El detalle importa porque las rutas pueden ser asimétricas. Pueden cambiar la encapsulación, la cola, el filtro o el túnel según el sentido. Incluso pueden existir MTU deliberadamente distintas. En ese caso, la configuración correcta no es necesariamente el mismo número a ambos lados, sino el número que corresponda a cada requisito direccional.

RFC 5881 sitúa BFD en un solo salto, donde el MTU de enlace suele aportar una garantía fuerte. RFC 5883 describe sesiones multihop. En estas, el primer enlace no revela el cuello de botella posterior, y la trayectoria de ida puede no parecerse a la de vuelta.

La interfaz de operación puede mostrar un único estado, pero el registro probatorio debe conservar lado emisor, lado receptor, tamaño, hora y época de configuración. Si se borra esa granularidad, la palabra “bidireccional” empieza a hacer un trabajo que los paquetes no hicieron.

El cliente más exigente modifica la sesión de todos

Varios protocolos pueden apoyarse en una misma sesión BFD. Supongamos que uno necesita 1.300 bytes, otro 1.500 y un tercero 1.600. RFC 9764 recomienda seleccionar la mayor petición para los mismos extremos. Usar una inferior permitiría Up sin satisfacer al tercer cliente.

La recomendación es razonable, pero produce gobernanza compartida. El último cliente que pide el mayor tamaño puede alterar la disponibilidad observada por los anteriores. Si el extremo remoto no admite paquetes BFD acolchados de 1.600 bytes, la sesión puede caer y todos los consumidores pueden reaccionar.

Por eso no basta con registrar la cifra final. Hay que conservar quién la pidió, qué clientes comparten el estado, cuál era el valor previo, qué capacidades se comprobaron y qué acciones dispara Down. La sesión no tiene forma de explicar que la necesidad de 1.600 pertenecía a una sola aplicación.

Un cambio seguro también debe distinguir despliegue de descubrimiento. Subir el tamaño en una sesión ya Up puede revelar una restricción genuina, pero también introducir por primera vez una representación que el receptor no analiza. La modificación es parte causal del evento observado.

El mismo Down admite causas incompatibles

El estándar aprovecha que la longitud del transporte puede exceder la longitud del PDU BFD. Algunas implementaciones antiguas pueden rechazar esa envoltura o aplicar una validación demasiado estricta. Desde la máquina de estados, un rechazo local en el receptor y una pérdida en una interfaz estrecha se ven igual: no llegó un control aceptable.

Un dispositivo intermedio puede filtrar los paquetes grandes. Un atacante en ruta puede descartarlos selectivamente y forzar Down. Los ceros del relleno evitan filtrar memoria sin inicializar, pero no autentican la explicación del fallo.

La secuencia de investigación debería mantener tres niveles. Primero: “la sesión dejó de recibir controles de este tamaño”. Segundo: “estas pruebas favorecen tal causa”. Tercero: “esta acción está autorizada”. Saltar del primer nivel al tercero convierte una alarma precisa en una política imprecisa.

Una captura en ambos extremos, contadores del receptor, comparación con el tamaño anterior y una prueba de servicio acotada pueden separar hipótesis. Ninguna por sí sola convierte el resultado en una verdad universal sobre la red.

ECMP selecciona una muestra que BFD no controla por completo

Una LAG o un conjunto ECMP reparte flujos entre miembros. El hash puede fijar los controles BFD en un enlace sano. El tráfico de cliente puede caer en otro con MTU menor. El control conserva Up mientras el servicio falla por una fracción de sus flujos.

RFC 7130 aborda BFD sobre miembros de una LAG. Para ECMP multihop, RFC 9764 recuerda que no existe un mecanismo BFD general normalizado que ejercite todos los enlaces. Algunos equipos pueden usar conocimiento interno para variar mejor el recorrido, pero esa cobertura es propia de la implementación.

La conclusión válida es estadísticamente más humilde: este flujo de control atravesó el miembro que el forwarding le asignó. No hay permiso para extrapolar a todos los valores de entropía. MTU incoherentes entre miembros convierten la capacidad en una propiedad dependiente del flujo.

La pieza BTW sobre RFC 9978 ya separó el contador de controles BFD perdidos de la pérdida probada en el plano de datos. Esta investigación añade una separación distinta: tamaño comprobado por el flujo BFD frente a tamaño útil de cada flujo real.

Una hoja YANG puede producir el incidente que observa

El módulo ietf-bfd-large amplía los modelos de RFC 9314 siguiendo la arquitectura NMDA de RFC 8342. Publica una capacidad padding y una hoja escribible pdu-size en estructuras single-hop, multihop, LAG y MPLS.

La presencia de la hoja no prueba que el valor esté activo en ambos extremos. Tampoco prueba el recorrido. El expediente necesita configuración pretendida, estado operacional, versión, momento de aplicación y recepción de paquetes. Además, el acceso de escritura merece protección: cambiar el valor en una sesión Up puede derribarla y afectar a varios clientes.

La técnica también puede emplearse con S-BFD, cuyo marco aparece en RFC 7880. Poder reutilizar el mecanismo no unifica el alcance de todas las modalidades. Cada una conserva sus propios discriminadores, caminos y responsabilidades.

La repetición mejora la actualidad, no la universalidad

RFC 9869 emplea opciones UDP REQ y RES para confirmar una sonda concreta de tamaño. Su artículo BTW posee el límite entre esa sonda y un datagrama futuro. RFC 9764 aporta una diferencia real: el ensayo se repite como parte de BFD, reduciendo la antigüedad del dato.

Pero el siguiente datagrama de aplicación puede usar otra entropía ECMP, tener otra encapsulación o sufrir otra política. La repetición estrecha la ventana temporal; no convierte una muestra en el universo.

La frase de operación debería contener fecha y ámbito: “Up con controles acolchados de X bytes, en este sentido, bajo esta revisión de configuración”. Esa frase permite refutar y actualizar la observación. “La red admite X” oculta qué se comprobó.

Fuentes y frontera de evidencia

El paquete congelado contiene RFC 9764; las bases BFD RFC 5880, RFC 5881, RFC 5883, RFC 7130 y RFC 7880; los modelos RFC 9314 y RFC 8342; y el contexto de tamaño RFC 1191, RFC 8899, RFC 9869 y RFC 9978.

La lectura institucional procede de Heng Lu: Minimum Initial Specification, Running-Code Primacy y On Reality Layers. El método común consiste en mantener pequeña la afirmación compartida y dejar la decisión posterior en manos del operador que ve y asume sus efectos.