Esta es mi configuración actual donde tengo 40Gbpsenlaces entre los 4 conmutadores que se ejecutan OSPFusando enlaces L3 entre ellos, pero ahora quiero duplicar mi ancho de banda entre los interruptores, así que estoy planeando agregar enlaces L3 (enlaces de puntos) y dejar que el tráfico de equilibrio de carga OSPF en ellos , ¿Crees que hay algún problema para hacer eso o esto va a estar bien? (quiere un segundo par de ojos)

Esto es lo que mi configuración ospf se ve en los 4 conmutadores.

interface Ethernet2/10
  no switchport
  mtu 9216
  ip address 192.168.250.9/30
  no ip ospf passive-interface
  ip router ospf 100 area 0.0.0.0
  no shutdown

interface Ethernet2/11
  no switchport
  mtu 9216
  ip address 192.168.250.13/30
  no ip ospf passive-interface
  ip router ospf 100 area 0.0.0.0
  no shutdown

Más detalles sobre el flujo de tráfico actual

mi flujo de tráfico actual parece que el siguiente diagrama en este momento SWes un interruptor BGP activo, por lo que todo el tráfico de entrada / salida proviene del ISP. luego SW1 comparte la carga entre dos SW3 / 4 utilizando OSPF ECMP. Los últimos 1 años no tenemos una sola queja sobre el problema de la voz o la calidad (todos están contentos). Ahora, cuando falla mi SW1, OSPF mueve la ruta BGP a SW2 y hace que el activetráfico comience a fluir de SW2 a SW3 / 4 (lo he probado varias veces desplazando manualmente BGP)

Actualización - 2

Información de carga compartida para OSPF / ECMP

Tengo configurado el siguiente reparto de carga, que es el predeterminado en los conmutadores Cisco Nexus.

# show ip load-sharing
IPv4/IPv6 ECMP load sharing:
Universal-id (Random Seed): 2223335843
Load-share mode : address source-destination port source-destination
GRE-Outer hash is disabled.
Concatenation is disabled.

Como se trata de enlaces punto a punto, consideraría usar la interrupción para configurar cada interfaz / 30 ip ospf network point-to-point. (Enlaces nuevos y existentes). Esto reduce los temporizadores hola y muertos. Esta configuración también reduce la necesidad de negociar un DR y un BDR.

Por último, verificaría los estados vecinos OSPF y las tablas de enrutamiento, antes y después de la transición. Debería ver las rutas de ECMP después de los cortes y las vecindades apropiadas.

Hay dos formas de hacer eso.

• a su manera propuesta, agregando un segundo enlace con su propio / 30 o / 31, asegurándose de que OSPF instale múltiples rutas de igual costo en la tabla de enrutamiento, y permita que el reenvío ECMP (EqualCostMultiPath) de CEF maneje el envío de paquetes y la distribución de flujos a través de El conjunto de enlaces disponibles. CEF / ECMP utiliza una lógica de carga compartida diferente a Port-Channel, y puede manejar números desiguales de enlaces mucho mejor que Port-Channels. Consulte la publicación del blog de Ivan Pepelniak como referencia.

• use L3 Port-Channels: mueva la configuración de IP y enrutamiento a un objeto de canal de puerto (que no tiene el comando "switchport"), y una las interfaces dadas a ese objeto. Deje que la lógica de distribución de carga de Port-Channel maneje la distribución de flujos.

Su idea propuesta está más orientada a L3 / enrutamiento, pero el escalado podría tener algunos problemas: utilizará muchos / 30 o / 31s. Puede escalar en números impares, pero tendrá que configurar un nuevo enlace y posiblemente una subred para cada paso de escala (o ir ip unnumbered). Por el lado positivo, los enlaces individuales con su propia subred son más fáciles de solucionar, ya que "atravesar un enlace individual" es algo natural ".

Por otro lado, los canales de puertos L3 no necesitan más subredes IP y en realidad no tocan su lógica de configuración de enrutamiento dada. Port-Channel es un poco más "estilo Nexus", ya que toda la historia de los conmutadores Nexus se basa en el concepto VPC (lo cual no se aplica aquí, lo admito). El escalado de enlaces adicionales es más fácil: solo agregue dos más, sin tocar ninguna configuración de IP o enrutamiento. Sin embargo, se aplican las reglas para los canales de puertos (por ejemplo, mantener el número de enlaces en potencias de 2), mientras que la solución de problemas de enlaces individuales de un canal de puertos es menos sencilla (no se puede hacer ping a través de un enlace individual sin eliminarlo del canal de puerto y reconfigurarlo)

ADDON-1: Y sí, sí, siga los consejos de TDurden para configurar punto a punto en los enlaces ... ehm ... punto a punto (realmente mal juego de palabras, lo admito)

CAVEAT-1: cuando utilice canales de puerto, asegúrese de seleccionar una estrategia de equilibrio de carga que se ajuste a los patrones de comunicación esperados para el enlace dado. Al conectar un enrutador a un enrutador (esencialmente solo dos direcciones MAC en el enlace), entonces "Src / Dst MAC" podría no tener los resultados deseados ... Para referencia, consulte la Guía de configuración de interfaces NX-OS de Cisco Nexus serie 9000, Versión 9.2 (x)

ADDON-2: en Nexus 9000, con ECMP / CEF, el algoritmo de carga compartida se puede configurar para incluir propiedades L4: ip load-sharing address source-destination port source-destinationconsulte Configuración de carga compartida en la FIB de unidifusión desde el gude de configuración de enrutamiento de unidifusión.

CAVEAT-2 Cuando use canales de puerto L3, vigile la propiedad de "ancho de banda" de la interfaz de canal de puerto cuando un enlace miembro se cae. Dependiendo de la plataforma de hardware / software, el ancho de banda de la interfaz de canal de puerto podría reducirse en consecuencia, y OSPF podría reaccionar a eso aumentando el costo del enlace dado. Esto podría tener consecuencias (no) intencionadas para la topología.