Esta é minha configuração atual, onde tenho 40Gbpslinks entre todos os 4 switches em execução OSPFusando links L3 entre eles, mas agora quero duplicar minha largura de banda entre os switches, por isso estou planejando adicionar links L3 (com pontos pontilhados) e permitir que o OSPF balanceie o tráfego neles , Você acha que há algum problema em fazer isso ou isso vai ficar bem? (quer um segundo par de olhos)

É assim que minha configuração ospf aparece nos quatro switches.

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

Mais detalhes sobre o fluxo de tráfego atual

meu fluxo de tráfego atual parece que o diagrama a seguir SWé atualmente um switch BGP ativo, de modo que todo o tráfego de entrada / saída é proveniente do ISP. o SW1 faz o compartilhamento de carga entre dois SW3 / 4 usando o OSPF ECMP. Nos últimos 1 anos, não temos uma queixa única sobre problemas de voz ou de qualidade (todos estão felizes). Agora, quando meu SW1 falha, o OSPF move a rota BGP para SW2 e faz com que o activetráfego comece a fluir de SW2 para SW3 / 4 (eu testei isso várias vezes deslocando manualmente o BGP)

Atualização - 2

Informações de compartilhamento de carga para OSPF / ECMP

Eu tenho o seguinte compartilhamento de carga configurado, que é o padrão nos switches 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 esses são links ponto a ponto, eu consideraria usar a interrupção para configurar cada interface / 30 ip ospf network point-to-point. (Links novos e existentes). Isso reduz o olá e os temporizadores mortos. Essa configuração também reduz a necessidade de negociar um DR e BDR.

Por fim, eu verificaria os estados vizinhos do OSPF e as tabelas de roteamento, antes e depois da transição. Você deverá ver as rotas do ECMP após os cortes e as devidas vizinhanças.

Existem duas maneiras de fazer isso.

• da maneira proposta, adicionando um segundo link com seu / 30 ou / 31, certificando-se de que o OSPF instale várias rotas de custo igual na tabela de roteamento e permita que o encaminhamento de CEMP (EqualCostMultiPath) da CEF lide com o envio de pacotes e a distribuição dos fluxos o conjunto de links disponíveis. O CEF / ECMP usa uma lógica de compartilhamento de carga diferente da do canal de porta e pode lidar com números desiguais de links muito melhor do que os canais de porta. Veja a publicação no blog de Ivan Pepelniak para referência.

• use L3 Port-Channels: mova a configuração de IP e roteamento para um objeto de canal de porta (que não possui o comando "switchport") e junte as interfaces fornecidas a esse objeto. Deixe a lógica de distribuição de carga do Port-Channel manipular a distribuição de fluxos.

Sua ideia proposta é mais orientada para o L3 / roteamento, mas a escala pode ter alguns problemas: Você usará muitos / 30 ou / 31s. Você pode escalar em números ímpares, mas precisará configurar um novo link e, possivelmente, sub-rede para cada etapa da escala (ou ir ip unnumbered). Em contrapartida, os links individuais com sua própria sub-rede são mais fáceis de solucionar - o ping em um único link "ocorre naturalmente".

Por outro lado, os Canais de Porta L3 não precisam de mais sub-redes IP e nem tocam na lógica de configuração de roteamento fornecida. O Port-Channel é um pouco mais "estilo Nexus", pois toda a história dos switches Nexus é baseada no conceito de VPC (que não se aplica aqui, admito). O dimensionamento de links adicionais é mais fácil - basta adicionar mais dois, sem tocar em nenhum IP ou configuração de roteamento. No entanto, aplicam-se regras para Canais de Porta (por exemplo, mantenha o número de links em potências de 2), enquanto a solução de problemas de links individuais de um Canal de Porta é menos direta (não é possível executar ping em um link individual sem removê-lo do canal de porta e reconfigurando)

ADDON-1: E sim, de qualquer forma, siga o conselho de TDurden para configurar ponto a ponto nos ... ehm .. links ponto a ponto (trocadilho muito ruim, admito)

CAVEAT-1: Ao usar canais de porta, verifique se você selecionou uma estratégia de balanceamento de carga que se encaixa nos padrões de comunicação esperados para o link fornecido. Ao conectar um roteador a um roteador (essencialmente apenas dois endereços MAC no link), "Src / Dst MAC" pode não ter os resultados desejados ... Para obter referência, consulte o Guia de configuração de interfaces do Cisco Nexus 9000 Series NX-OS, Versão 9.2 (x)

ADDON-2: No Nexus 9000, com ECMP / CEF, o algoritmo de compartilhamento de carga pode ser configurado para incluir propriedades L4: ip load-sharing address source-destination port source-destinationConsulte Configurando o compartilhamento de carga no FIB de difusão ponto a ponto no guia de configuração de roteamento de difusão ponto a ponto.

CAVEAT-2 Ao usar canais L3-Port, fique de olho na propriedade "largura de banda" da interface do canal da porta quando um link membro cair. Dependendo da plataforma de hardware / software, a largura de banda da interface do canal da porta pode ser reduzida de acordo e o OSPF pode reagir a isso aumentando o custo do link fornecido. Isso pode ter consequências (não) pretendidas para a topologia.