Hola,
Hay un problema muy común que siempre nos encontramos fácilmente y el problema podría resolverse, pero no pudimos recordar la causa raíz nuevamente, ya que es bastante simple. Entonces, la próxima vez, nos encontraríamos con la misma pregunta nuevamente y aún tendríamos que gastar mucho tiempo, energía para localizar y resolver este problema.
El problema que vamos a discutir es:
¿Por qué el peer OSPF no puede alcanzar el estado "FULL", especialmente con otro proveedor?
Y el estado de vecino OSPF se detuvo principalmente en el estado "Exstart" o "Exchange".
¿Por qué? Si el estado del peer OSPF puede llegar a "Intercambio" o "Inicio", significa que los paquetes que se envían y reciben entre dos routers son normales, ya intercambiaron información enviando y recibiendo paquetes.
Aquí está la razón más probable:
Las MTU de ambas interfaces laterales pueden no coincidir.
Pero, ¿por qué el valor de MTU afectará el estado del peer OSPF?
Aquí está la respuesta:
En el estándar RFC 2328, se especifica que el campo "MTU de interfaz" en el paquete DD debe establecer el mismo valor que el valor de MTU de enlace local (para el tipo de enlace v, el valor de MTU de interfaz debe establecerse como 0). Y el estándar RFC también solicita que: si el router local recibió un paquete DD en el que el valor de "interfaz MTU" es mayor que el MTU de enlace local, entonces el paquete DD debe descartarse. Entonces, en este caso, el vecino OSPF se detendrá en el estado "Inicio de intercambio".
En realidad, alguna versión anterior de Cisco IOS verificará esta configuración de MTU estrictamente, por lo que para la operación de múltiples proveedores, habrá algunos problemas al respecto. Cuando el proveedor es consciente de esto, la nueva versión de IOS aumentó 1 línea de comando adicional debajo de la interfaz: "ip ospf ignore mtu", para ignorar la comprobación de "interfaz MTU" en el paquete DD. Entonces, si esta línea de comando se configuró, incluso ambos routers no tenían exactamente el mismo valor de MTU, su estado vecino aún puede alcanzar el estado "Completo" y, por supuesto, los LSDP se pueden sincronizar con éxito. Pero preste atención aquí, incluso en este caso, el valor de MTU de ambos lados no debería ser dramáticamente diferente.
La descripción anterior describe principalmente por qué el MTU de enlace afectó la relación de peers OSPF. Pero tenemos que resolver otro problema común:
¿Por qué los lados de Huawei y Cisco (u otros proveedores) ya están configurados con el mismo valor de MTU: como 9194, el mismo problema "El peer OSPF se detu****l inicio o al cambio" todavía ocurre?
La razón es que diferentes proveedores tienen una concepción diferente sobre el enlace MTU. O, en otras palabras, el valor MTU de los routers Huawei es diferente del de otros proveedores.
Por ejemplo, en los routers Cisco, la MTU significa: El valor predeterminado de la MTU es generalmente el tamaño de trama de capa 2 más grande posible para el tipo de interfaz. La interfaz Ethernet es el datagrama de capa 3 más 14 bytes.
Ethernet—1514 bytes
Ethernet dot1q sub interfaz —1518 bytes
POS—4474 bytes
Tunnel—1500 bytes
Loopback—1514 bytes
ATM—4470 bytes
Mientras está en los routers Huawei, el valor de MTU de enlace / interfaz solo significa el tamaño máximo de carga útil de trama de capa 2 para el tipo de interfaz. Para el escenario de IP sobre Ethernet, también podemos decir que MTU es MTU de capa IP, no el tamaño de trama de capa 2 más grande.
Esto significa que si el lado de Huawei y el lado de Cisco configuraron el mismo valor de MTU: 9194.
Significa que la MTU de la capa IP real es 9180 en el lado de Cisco, que simplemente no coincide con el lado de Huawei.
Si el lado de Cisco mantiene este valor de MTU 9194, para el lado de Huawei en otro para que coincida con este valor de MTU, el lado de Huawei debe establecer MTU de enlace / interfaz en 9180.
Después de hacer el cambio de esta manera, se resolvió el problema de estado de igual de OSPF.
