Best practice per la combinazione di HSRP ed ECMP

La combinazione di ECMP (o altre cause di percorsi asimmetrici) e HSRP è rotta per impostazione predefinita in Cisco IOS; il comportamento predefinito con questo design inonda eccessivamente il traffico unicast.

Qual è la migliore pratica per l'utilizzo di HSRP con ECMP per prevenire inondazioni unicast sconosciute?

Dettagli / Sfondo

Abbiamo una topologia HSRP simile al primo diagramma seguente per molte delle nostre strutture. I nostri router Cisco WAN hanno rotte di uguale costo per tutti gli altri siti; quindi possiamo vedere sempre effetti di routing asimmetrici. Normalmente assegniamo R1 come primario HSRP, ma ECMP consente il traffico di ritorno tramite R1 o R2.

Il problema è che quando PC1 monta un'unità iSCSI remota attraverso la WAN, il traffico lascia il sito tramite R1, ma potrebbe tornare tramite R2. Finché il traffico iSCSI ritorna tramite R1, non ci sono problemi.

Il problema si verifica quando il traffico di PC1 ritorna tramite R2. Supponiamo che la sessione iSCSI inizi alle 8:00:00 e che entrambi i router e entrambi gli switch apprendano contemporaneamente il mac di PC1. Tra le 8:00:00 e le 8:00:05, non ci sono problemi di allagamento perché entrambi gli switch hanno ancora l'indirizzo MAC di PC1 nella loro tabella CAM.

Cinque minuti dopo l'avvio della sessione iSCSI, la voce CAM di S2 per Mac di PC1 scade dalla tabella CAM e S2 inonda il traffico di PC1 su tutte le porte (in questo caso verso Po1, Gi0 / 3 e Gi0 / 4). Se la sessione iSCSI di PC1 consuma molta larghezza di banda, questa inondazione unicast sconosciuta può assorbire capacità non banali dai collegamenti a PC3 e PC4.

Gli switch Cisco IOS hanno un timer CAM predefinito di 300 secondi ...

S2# show mac address-table aging-time
Vlan Aging Time
---- ----------
1    300
17   300

Tuttavia, il timer ARP dell'interfaccia predefinita di Cisco IOS è di 4 ore ...

R2# show interface gi0/0
GigabitEthernet0/0 is up, line protocol is up 
  Hardware is AmdP2, address is 000a.dead.beef (bia 000a.dead.beef)
  Internet address is 172.17.1.252/24
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00       <--------------

Pertanto, S2 inizia a inondare il traffico iSCSI di PC1 dopo cinque minuti.

La semplice risposta è rendere il timer CAM uguale o leggermente più lungo del corrispondente timer ARP dell'interfaccia , ma ci sono almeno tre diverse opzioni tra cui scegliere ...

Opzione 1: Abbassa tutti i timer ARP dell'interfaccia

Questa opzione funziona meglio se si dispone di una rete commutata layer2 di dimensioni decenti, un numero ragionevole di voci ARP e poche interfacce instradate. Questo metodo è preferibile anche se ti piace vedere rapidamente le voci del PC mac fuori dalla topologia.

• Su tutte le interfacce Ethernet IOS di fronte a uno switch Ethernet: arp timeout 240
• Su tutte le interfacce Ethernet IOS di fronte a uno switch ethernet: hold-queue 200 ine hold-queue 200 outper evitare di far cadere i pacchetti ARP durante gli aggiornamenti periodici di ARP (questi limiti potrebbero essere più alti o più bassi a seconda di quanti aggiornamenti ARP pensi di dover gestire contemporaneamente). Se stai regolando i valori di Scarto pacchetto selettivo , devi seguire le linee guida nel documento che ho collegato.

Ciò costringe Cisco IOS ad aggiornare la tabella ARP entro quattro minuti, se non è accaduto diversamente per una data voce ARP. L'ovvio svantaggio è che questo non si adatta bene se si hanno molte voci ARP ... i limiti variano in base alla piattaforma. L'ho usato con alcune centinaia di ARP per router su Catalyst 4500/6500 (le SVI Layer3) senza problemi.

Opzione 2: aumentare i timer CAM dell'interruttore

Questa opzione funziona al meglio se si dispone di un numero elevato di voci ARP (ad esempio migliaia, ad esempio un intenso ambiente VMWare potrebbe vedere).

• Su tutti gli switch IOS: mac address-table aging-time 14400o mac address-table aging-time 14400 vlan <vlan-id>per qualsiasi Vlan che destano preoccupazione.

Questa modifica regola i timer che la maggior parte delle persone presume siano fissi a 300 secondi (su Cisco IOS), quindi assicurati di includerlo nei documenti di continuità. L'effetto collaterale di ciò è che le voci della tabella CAM persistono per 4 ore dopo la rimozione del PC (che può essere buono o cattivo, a seconda del tuo PoV). Se 4 ore sono troppo lunghe, vedi l'opzione successiva ...

Opzione 3: modificare sia i timer ARP di interfaccia sia i timer CAM di commutazione

Questa opzione evita i timer CAM orribilmente lunghi nell'opzione 2 a scapito di una maggiore configurazione. Puoi scegliere se hai bisogno di 900 secondi, 1800 secondi o qualsiasi altra cosa ... assicurati solo che i tuoi timer CAM e ARP corrispondano; pertanto, sarà necessario configurare sia l'opzione 1 che l'opzione 2 nelle topologie.

Per me, ECMP è il vero problema qui, quindi oltre ai passaggi precedenti per limitare l'inondazione unicast sconosciuta, puoi anche ottimizzare le metriche del percorso verso la WAN in modo che R1 sia preferito su R2 per il traffico di ritorno. Un modo per ottenere ciò è tramite la lista di distribuzione su R2 come segue: (EIGRP usato solo ad esempio, lo stesso può essere ottenuto con OSPF o BGP con altri comandi)

!
Elenco prefissi ip R1-PREFER seq 5 permesso 172.17.1.0/24
!
Mappa del percorso R1-PREFER-MAP permesso 10
 corrisponde a elenco indirizzi IP prefisso R1-PREFER
 imposta metrica 1 1 1 1 1
... (consenti tutti gli altri percorsi)
!
router eigrp 1
 ....
 distribuire-lista itinerario-mappa R1-PREFER-MAP fuori Ser1 / 0
 ....
!

Ciò comporterà che la WAN inoltra tutto il traffico da 172.17.1.0 a R1. Se R1 Se1 / 0 fallisce, il percorso verrà installato verso R2. È possibile ottimizzare ulteriormente queste metriche in modo che il percorso di backup su R2 sia in realtà un successore possibile per un failover più veloce. HSRP e tracking si occuperanno del traffico in uscita.

L'idea se non utilizzare ECMP se HSRP è in uso potrebbe essere valida per i server in cui il traffico in ingresso può essere superiore al traffico in uscita, in una situazione PC IN GENERALE il traffico in ingresso dalla WAN (risposte) è superiore al traffico in uscita (ingresso). Ci piace che la maggior parte delle persone imposti i timer ARP. puoi fare confusione con i timer CAM, MA se hai detto un MDF con lo switch di livello 3 e un IDF con 2 switch di raccolta e dici 5 switch di accesso, è molto più facile da configurare sull'LVI L3 rispetto a fare tutti gli switch di accesso.

Si potrebbe usare una pila di switch per mitigare questo problema di scadenza dell'indirizzo MAC nel secondo switch.

Ah, me lo ricordo. Settimane di divertimento hanno avuto a che fare con questo ritorno alcuni lavori fa. Una ruga è che gli eventi STP metteranno i vlan in modalità a invecchiamento rapido, quindi impostare il timer MAC più a lungo del timer ARP non aiuta

Ho risolto il problema costringendo l'ECMP a tornare dai server, creando due gateway HSRP mobili, con uno primario su ciascun router. Abbiamo quindi configurato entrambi i gateway su ciascun host. Forzando il traffico host verso R1 e R2 in questo modo, saremmo sicuri che R2 non invecchierebbe mai gli indirizzi MAC.

Idealmente, questo non sarebbe un problema se gli switch L2 / 3 eliminassero le voci ARP associate a indirizzi MAC obsoleti. Il pacchetto successivo all'IP provocherebbe quindi una nuova richiesta ARP, popolando sia la cache ARP che la tabella MAC. Penso che alla fine Cisco lo abbia implementato, ma non posso dirlo con certezza.

Riepilogo: MC-LAG o HSRP GARP

Non sono mai stato un fan dei tweaking timer. I timer sono impostati in un certo modo di solito per molte ragioni. Modificandoli:

• è potenzialmente operativamente intenso per mantenere lo stesso ovunque
• rende le cose più complicate e difficili da risolvere
• come ha mostrato un commentatore recente, può avere effetti collaterali imprevisti
• potrebbe non "giocare bene" con i futuri miglioramenti di Cisco

In alternativa:

1. Utilizzare MC-LAG (noto anche come "MEC" nella documentazione Cisco). Questa è l'opzione migliore, anche se è necessario comprendere gli scenari di distribuzione in cui MC-LAG può essere utilizzato (non è una soluzione universale e deve essere implementato solo dopo ricerche e test appropriati). Le varianti MC-LAG dipendono dall'hardware. Esempi sono:

   un. Stacking (Cat 3k)

   b. VSS (Cat4k / 6k)

   c. VPC (Nexus)

   d. Pseudo mLACP (ASR1k)

   e. MC-LAG (ASR9k)

   f. Clustering (ASA)

2. Abilita HSRP per inviare periodicamente pacchetti ARP gratuiti . Certo, è simile alla modifica dei timer, ma è un'alterazione molto più aggraziata rispetto alla manipolazione della tabella CAM e dei timer ARP. (Nota che questo dipende dalla combinazione hardware e software, non tutte le implementazioni HSRP offrono questo.)

   Per impostazione predefinita, HSRP invia 3 GARP, a 0, 2 e 4 secondi dopo che il router diventa il gateway di inoltro. Tuttavia, esiste un parametro di configurazione che consente di scegliere il numero di GARP (incluso "infinito") e l'intervallo.

Uso MC-LAG piuttosto ampiamente, in particolare VSS, VPC e Clustering (non sono un fan dello stacking).

Dove non posso usare MC-LAG o GLBP, questo è ciò che applico ai miei router di confine L2 / L3 del mio campus (ho un campus di 350 edifici quindi uso Cat6k piuttosto pesantemente):

Cat6k-v15(config)#interface vlan 100
Cat6k-v15(config-if)#standby arp ?
  gratuitous  Setup gratuitous ARP interval and count

Cat6k-v15(config-if)#standby arp gratuitous ?
  count     Set HSRP gratuitous ARP count
  interval  Set HSRP gratuitous ARP interval
  <cr>

Cat6k-v15(config-if)#standby arp gratuitous count ?
  <0-60>  Number of gratuitous ARPs to send after group is activated (0 for continuous)

Cat6k-v15(config-if)#standby arp gratuitous count 0 ?
  count     Set HSRP gratuitous ARP count
  interval  Set HSRP gratuitous ARP interval
  <cr>

Cat6k-v15(config-if)#standby arp gratuitous count 0 interval ?
  <3-1800>  Gratuitous ARP Interval (sec)

Cat6k-v15(config-if)#standby arp gratuitous count 0 interval 60 ?
  count     Set HSRP gratuitous ARP count
  interval  Set HSRP gratuitous ARP interval
  <cr>

Cat6k-v15(config-if)#standby arp gratuitous count 0 interval 60 

(Pubblicherei riferimenti a tutti questi, ma non ho una "reputazione" sufficientemente elevata su questo sito per pubblicare più di due URL.)

Ho appena realizzato che il mio commento originale è valido, ma tristemente incompleto. La raccomandazione di progettazione indipendente dal fornitore è quella di costruire triangoli, non rettangoli. Così:

1. Non solo MC-LAG, ma MC-LAG su entrambi i livelli. Quindi hai a che fare con una tabella CAM condivisa sia a livello di switch che a livello di router.

2. Se non riesci a farlo, MC-LAG o il router o lo switch e MC-LAG all'altro livello con un collegamento aggiuntivo (ovvero full-mesh tra router e switch). STP garantirà una topologia senza loop.

3. Se non riesci a farlo, metti in rete i router e gli switch. STP garantirà una topologia senza loop e le tabelle degli switch CAM conosceranno comunque tutte le regole di inoltro MAC appropriate. Il server invierà sempre il MAC e, se si configurano i GARP HSRP a intervalli di 1 minuto, anche gli switch non dimenticheranno il vMAC HSRP.

Le opzioni preferite sono in questo ordine. Ma almeno installa quella coppia extra di link.