¿Es posible configurar OSPF para usar la latencia en sus cálculos de costo / métrica de enlace? La idea es habilitar el enrutamiento basado en el rendimiento mediante el cual los enlaces más rápidos y menos congestionados en la red se elegirán dinámicamente, en lugar de depender del comportamiento predeterminado de OSPF que resulta en enlaces de 100Mbps que tienen el mismo costo que los enlaces de 1Gbps.
9
Respuestas:
Respuesta corta: No, no solo con OSPF
Respuesta larga:
La única forma para que OSPF calcule dinámicamente las rutas en función de la latencia / congestión es usar MPLS Traffic Engineering con optimizaciones fuera de línea de los costos de MPLS TE según sus criterios ; MPLS TE utiliza OSPF LSA para transportar información sobre las rutas de conmutación de etiquetas. Sin embargo, MPLS Traffic Engineering es un martillo pesado y muchas operaciones de red no pueden lidiar con el flujo de trabajo adicional introducido en el aprovisionamiento o la resolución de problemas de MPLS TE.
Otra respuesta sugiere que no debe ajustar los costos de enlace en función del ancho de banda, y utilizar la función de un nodo para los costos. No puedo hablar por su red, pero esta guía es innecesaria en muchos casos ya que la ruta de menor costo en una topología bien diseñada sigue automáticamente a través del núcleo de la red. No trataría de ajustar una topología ineficiente con costos de enlace ... solo haga que el tráfico fluya a través del núcleo de forma natural y asegúrese de que OSPF vea un 1GE como una mejor ruta que un enlace FastEthernet. Esto sucederá naturalmente si diseña bien la topología y utiliza el ancho de banda de referencia de costo automático en el proceso OSPF. Asegúrese de usar esto en todos los enrutadores OSPF para que entiendan los costos del enlace de la misma manera.
fuente
No debe confiar en las métricas / costos predeterminados, no en IGP o STP. Mi revisión de una pregunta si LAN fue diseñada es preguntar qué enlace está bloqueando, si el ingeniero no puede responder sin mirar, es una fuerte indicación de que la red no fue diseñada.
Debe diseñar cómo desea que fluya el tráfico en condiciones normales de operación y de falla y luego diseñar un estándar métrico que satisfaga esos requisitos. Prefiero hacer esto con lápiz y papel, agregue café si así lo desea.
Prefiero en gran medida el estándar métrico basado en roles , donde PP, P-PE, PE-PE, etc. tienen el mismo valor métrico, independientemente del ancho de banda o la latencia. Es decir, sé a dónde quiero que vaya mi tráfico, para mí no importa cuál sea la latencia o la capacidad, si no tengo suficiente capacidad donde quiero que fluya el tráfico, actualizaré el Enlaces.
Ciertamente, la función basada en roles no es solo una forma de hacerlo, si desea basar su estándar métrico en la velocidad del enlace o la latencia medida, continúe.
Independientemente de cómo diseñe su estándar métrico, será completamente estático y desconocerá las condiciones reales del enlace, como la pérdida de paquetes, la latencia, la fluctuación, la capacidad, etc. ) para cambiar las condiciones de la red, debe buscar RSVP o incluso SDN.
fuente
Otra opción es usar PfR u OER, es decir, los enrutadores usan sondas activas o datos de flujo de red para seleccionar una ruta dinámicamente. O, por supuesto, la opción más simple es codificar los valores de costo de OSPF.
La otra consideración es si está tratando de codificar una métrica estática o si desea un comportamiento dinámico (los cambios de latencia con la carga de tráfico).
Finalmente, como se mencionó anteriormente, ¿está seguro de que desea la complejidad? Si observa EIGRP, tiene una métrica de carga, pero nadie la utiliza porque agrega complejidad operativa y puede obtener la oscilación del tráfico.
fuente