Si se intenta configurar las adyacencias vecinas sin una MTU coincidente, los enrutadores no pueden convertirse en vecinos. Supongo que esto es para proteger el protocolo de enrutamiento de sí mismo, pero no entiendo de qué se está salvando. ¿Cuál sería (podría) la consecuencia sin hacer coincidir MTU?

Pete dijo :

No puedo pensar en una situación en la que necesites esto. Solo quería saber cuál era la lógica que hace que esto sea una verificación explícita en estos protocolos de enrutamiento.

Respuesta corta

Los protocolos de enrutamiento son algunos de los bloques de construcción más fundamentales en Internet; Necesitamos que sean muy confiables en todos los casos posibles. No sirve de nada mostrar una adyacencia OSPF o EIGRP en una MTU no coincidente.

Los protocolos de enrutamiento deben eliminar cualquier MTU potencial no coincidente de la ruta de reenvío del enrutador.

Respuesta larga

Puedo pensar en tres posibles situaciones en las que encontraría MTU IGP no coincidentes ...

1. Falta de coincidencia de MTU no intencional en la capa 2 (por ejemplo, si alguien accidentalmente no coincide MTU en una línea en serie, o diferentes proveedores tenían MTU predeterminadas diferentes en el mismo medio)
2. Las MTU de Layer2 coinciden, pero la implementación del enrutador tiene un error que calcula mal la interfaz requerida MTU IP
3. Desajuste intencional de MTU

Las MTU de IP están directamente correlacionadas con las MTU de Capa 2 (al menos para el Caso 1, arriba). No importa lo que hagamos, siempre estamos a merced de mitigar los problemas de los desajustes involuntarios de Layer2 MTU, ya que no existe un mecanismo de descubrimiento de Layer2 MTU (a diferencia de IP, que tiene mensajes de error ICMP).

Esto significa que tenemos que hacer todo lo posible para evitar desajustes de MTU de capa 2, incluso si los casos 2 y 3 anteriores son víctimas de mitigar problemas con el caso número 1. El caso 1 tiene implicaciones colosales a menos que lo resuelvamos; es decir, agujerear todo el tráfico solo porque permitimos MTU no coincidentes.

Siempre estamos limitados al mínimo común denominador en el enlace. Las tramas más grandes que la MTU de recepción de una interfaz se descartan silenciosamente, y el enrutador no tiene forma de saber si la MTU no coincidió intencionalmente o si sucedió accidentalmente.

En consecuencia, EIGRP y OSPF requieren adyacencias válidas de Capa ^{2 Nota 1} (incluidas las MTU).

¿Cuál sería (podría) la consecuencia sin hacer coincidir MTU?

Citando a John Moy (autor de OSPF) en RFC 2329 Página 4 :

• Problemas con todo el reenvío de IP
• Problemas de OSPF

También citandolo de la lista de correo de OSPF :

^{Nota 1:} algunas personas no entienden el significado de adyacencia como estrictamente un concepto de protocolo de enrutamiento IP. Esta afirmación pierde la realidad de que todo (incluida la IP) requiere MTU de capa2 coincidentes , para que los dominios de Capa2 funcionen correctamente.

Una de las funciones más importantes de un protocolo de enrutamiento es crear una tabla FIB / CEF / reenvío válida. Esa tabla asigna la información aprendida a través de protocolos de enrutamiento a la información de reescritura de capa2 . Esas relaciones de capa 2 en el mismo enlace físico son lo que Cisco también llama adyacencias.

De acuerdo con OSPF RFC 2328 (10.6):

Si el campo Interfaz MTU en el paquete Descripción de la base de datos indica un tamaño de datagrama IP que es más grande de lo que el enrutador puede aceptar en la interfaz receptora sin fragmentación, se rechaza el paquete Descripción de la base de datos.

La respuesta simple es que el estándar fue diseñado para simplemente eliminar datagramas que son demasiado grandes en lugar de fragmentarlos. El tráfico fragmentado aumenta la carga de CPU de un dispositivo y disminuye el rendimiento debido a la necesidad de la fragmentación necesaria para el tráfico adicional. Teniendo en cuenta que el objetivo de un protocolo de enrutamiento dinámico es que sea un protocolo convergente estable y rápido, se debe eliminar todo lo contrario a esos objetivos. Establecer el requisito para que las MTU coincidan ayuda a hacer cumplir este requisito de rendimiento.

Más del OSPF RFC:

4.3.  Routing protocol packets

    The OSPF protocol runs directly over IP, using IP protocol 89.
    OSPF does not provide any explicit fragmentation/reassembly
    support.  When fragmentation is necessary, IP
    fragmentation/reassembly is used.  OSPF protocol packets have
    been designed so that large protocol packets can generally be
    split into several smaller protocol packets.  This practice is
    recommended; IP fragmentation should be avoided whenever
    possible.