Questa è la mia configurazione attuale in cui ho 40Gbpscollegamenti tra tutti e 4 gli interruttori in esecuzione OSPFutilizzando i collegamenti L3 tra di loro, ma ora voglio raddoppiare la mia larghezza di banda tra gli interruttori, quindi sto programmando di aggiungere collegamenti L3 (punti punteggiati) e lasciare che il traffico di bilanciamento del carico OSPF su di essi , Pensi che ci sia qualche problema a farlo o questo andrà bene? (vuoi una seconda serie di occhi)

Ecco come appare la mia configurazione ospf su tutti e 4 gli switch.

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

Maggiori dettagli sull'attuale flusso di traffico

il mio flusso di traffico attuale sembra che il seguente diagramma SWsia attualmente lo switch BGP attivo, quindi tutto il traffico in / out proveniente dall'ISP. quindi SW1 esegue la condivisione del carico tra due SW3 / 4 utilizzando OSPF ECMP. Negli ultimi 1 anni non ci siamo lamentati di problemi vocali o di qualità (tutti sono felici). Ora quando il mio SW1 fallisce, OSPF sposta la rotta BGP su SW2 e fa in modo che il activetraffico inizi a fluire da SW2 a SW3 / 4 (l'ho testato più volte spostando manualmente BGP)

Aggiornamento - 2

Informazioni sulla condivisione del carico per OSPF / ECMP

Ho configurato la condivisione del carico seguente, che è predefinita sugli switch 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.

Dato che si tratta di collegamenti Point-to-Point, prenderei in considerazione l'utilizzo dell'interruzione per configurare ciascuna interfaccia / 30 ip ospf network point-to-point. (Link nuovi ed esistenti). Questo riduce i ciao e i timer morti. Questa configurazione riduce anche la necessità di negoziare un DR e un BDR.

Infine, verificherei gli stati vicini OSPF e le tabelle di routing, prima e dopo il ritaglio. Dovresti vedere i percorsi ECMP dopo le interruzioni e i vicini vicini.

Ci sono due modi per farlo.

• il modo proposto, aggiungendo un secondo collegamento con il proprio / 30 o / 31, assicurandosi che OSPF installi più percorsi di uguale costo nella tabella di routing e consenta all'inoltro ECMP (EqualCostMultiPath) di CEF di gestire la spinta dei pacchetti e la distribuzione dei flussi attraverso l'insieme dei collegamenti disponibili. CEF / ECMP utilizza una logica di condivisione del carico diversa rispetto a Port-Channel e può gestire numeri irregolari di collegamenti molto meglio rispetto a Port-Channel. Vedi il post sul blog di Ivan Pepelniak come riferimento.

• usa i port-channel L3: sposta l'IP e la configurazione del routing su un oggetto port-channel (che non ha il comando "switchport") e unisce le interfacce fornite a quell'oggetto. Consenti alla logica di distribuzione del carico Port-Channel di gestire la distribuzione dei flussi.

L'idea proposta è più orientata a L3 / routing, ma il ridimensionamento potrebbe presentare alcuni problemi: utilizzerai molti / 30 o / 31s. Puoi ridimensionare in numeri dispari, ma dovrai configurare un nuovo collegamento e possibilmente una sottorete per ogni passaggio (o andare ip unnumbered). Il lato positivo è che i singoli collegamenti con la propria sottorete sono più facili da risolvere: il ping su un singolo collegamento "viene naturale".

D'altro canto, i port-channel L3 non necessitano di più subnet IP e non toccano la logica di configurazione del routing fornita. Port-Channel è un po 'più "stile Nexus", poiché l'intera storia degli switch Nexus si basa sul concetto VPC (che non si applica qui, lo ammetto). Il ridimensionamento di collegamenti aggiuntivi è più semplice: basta aggiungerne altri due, senza toccare alcun IP o configurazione del routing. Tuttavia, si applicano le regole per i Port-Channel (ad es. Mantenere il numero di collegamenti in potenze di 2), mentre la risoluzione dei problemi dei singoli collegamenti di un Port-Channel è meno semplice (non è possibile eseguire il ping su un singolo collegamento senza rimuoverlo dal port-channel e riconfigurandolo)

ADDON-1: E oh sì, segui assolutamente i consigli di TDurden per configurare punto-punto sui collegamenti punto-punto ... ehm .. (gioco di parole davvero pessimo, lo ammetto)

CAVEAT-1: quando si utilizzano i port-channel, assicurarsi di selezionare una strategia di bilanciamento del carico che si adatti ai modelli di comunicazione previsti per il collegamento specificato. Quando si collega un router a un router (essenzialmente solo due indirizzi MAC sul collegamento), "Src / Dst MAC" potrebbe non ottenere i risultati desiderati ... Per riferimento, consultare la Guida alla configurazione delle interfacce NX-OS Cisco Nexus serie 9000, Versione 9.2 (x)

ADDON-2: Su Nexus 9000, con ECMP / CEF, l'algoritmo di condivisione del carico può essere configurato per includere le proprietà L4: ip load-sharing address source-destination port source-destinationVedi Configurazione della condivisione del carico in FIB Unicast dalla configurazione di routing Unicast.

CAVEAT-2 Quando si usano i canali L3-Port, tenere d'occhio la proprietà "larghezza di banda" dell'interfaccia port-channel quando un collegamento membro si interrompe. A seconda della piattaforma hardware / software, la larghezza di banda dell'interfaccia port-channel potrebbe ridursi di conseguenza e OSPF potrebbe reagire a ciò aumentando il costo del collegamento dato. Ciò potrebbe avere conseguenze (non) intenzionali per la topologia.