Il requisito di 2 n numero di porte per EtherChannel è un requisito critico o solo una raccomandazione per garantire, forse, un bilanciamento uniforme del carico?
In particolare, se impostiamo un gruppo EtherChannel con 8 porte, ma una di queste va in crash. Le restanti 7 porte sarebbero ancora funzionali ma con un bilanciamento del carico irregolare o 3 porte sarebbero costrette in standalone per garantire una potenza di due gruppi?
È trattato in modo simile sia per PAgP che per LACP?
Risposte:
La potenza di 2 requisiti varia a seconda del fornitore / hardware / software. Cisco aveva (ha) un cattivo stigma contro di loro con molti dei precedenti catalizzatori in grado di 10G. Il problema nasce dal modo in cui il software esegue l'hashing (o "equilibra") i dati sulle porte multiple nel port-channel (questo è agnostico di PAgP o LACP).
Questo post fa un ottimo lavoro nel semplificare il problema nei minimi dettagli. Questo è meno rilevante oggi con miglioramenti hardware / software, ma di nuovo varia - quindi basta controllare i requisiti hardware e assicurarsi di non acquistare hardware più vecchio che è vittima di questo problema.
http://www.packetmischief.ca/2012/07/24/doing-etherchannel-over-3-5-6-and-7-link-bundles/
Il requisito di 2n numero di porte per EtherChannel è un requisito critico o solo una raccomandazione per garantire, forse, un bilanciamento uniforme del carico?
La maggior parte dei fornitori non ha tale requisito. Questa è una convenzione spesso discussa in base ai limiti di un hash a tre bit durante il bilanciamento del carico. Personalmente non sono d'accordo con questa posizione, ma ci riuscirò dopo aver risposto alle tue domande.
In particolare, se impostiamo un gruppo EtherChannel con 8 porte, ma una di queste va in crash. Le restanti 7 porte sarebbero ancora funzionali ma con un bilanciamento del carico irregolare o 3 porte sarebbero costrette in standalone per garantire una potenza di due gruppi?
In genere, se si dispone di 8 porte in un gruppo di aggregazione dei collegamenti e una scende, le altre sette rimarranno attive. Sì, il carico sarà un po 'sbilanciato in un certo senso, ma di nuovo, ci riuscirò tra un minuto.
È trattato in modo simile sia per PAgP che per LACP?
Sì, e lo stesso con un gruppo LAG statico.
Ora dal mio punto di vista il motivo per cui non mi attengo personalmente alla potenza di due "regole empiriche" quando si tratta di aggregazione dei collegamenti.
Per iniziare, è necessario comprendere che nessuna aggregazione di collegamenti equilibra mai l'utilizzo dei collegamenti nel GAL . Chiaramente ci sono differenze nel metodo di bilanciamento del carico scelto, e alcuni sono migliori di altri (anche se nessuno è il migliore in ogni circostanza).
Il metodo di bilanciamento del carico non equilibra il traffico, ma bilancia ciò che è possibile considerare "flussi". In base alla piattaforma, sono disponibili opzioni per utilizzare i valori di origine e / o destinazione che possono includere indirizzo MAC, indirizzi IP, numeri di porta, ecc. Questi valori vengono quindi sottoposti a hash per determinare quale collegamento è selezionato per quel determinato flusso. I frame con lo stesso set di valori riceveranno sempre lo stesso hash e saranno assegnati allo stesso link.
Non tutti i flussi sono uguali e ciò significa che non è possibile bilanciare l'utilizzo del collegamento con questi mezzi. Non togliere il valore del GAL, poiché spesso fa un buon lavoro nel bilanciare anche l'utilizzo, ma è necessario comprendere i limiti.
È possibile che uno o più di questi flussi utilizzino il loro intero collegamento nel GAL e muoiano di fame altri flussi assegnati allo stesso collegamento. Nel frattempo gli altri link sono sotto utilizzati.
Quando la maggior parte delle persone guarda grafici come quelli in questo post sul blog o in questo documento Cisco , vede che il traffico è sbilanciato. Nel senso che alcuni collegamenti ricevono più flussi di altri, questo è vero.
La mia visione di queste tabelle è leggermente diversa. In primo luogo, anche con la distribuzione sbilanciata, quando si aggiungono collegamenti non c'è mai alcun punto in cui la percentuale di flussi assegnati su un collegamento aumenta; piuttosto nella maggior parte dei casi la percentuale diminuisce. Detto in altro modo, in nessun momento ci sono meno opportunità per un flusso di avere accesso alla larghezza di banda e, in molti casi, avrà più opportunità.
In secondo luogo, se dovessi guardare questo grafico per decidere tra due o tre collegamenti in un GAL, nella mia mente vedo questo come segue:
Infine, considera cosa succede se perdi un collegamento nel GAL. Considerati due collegamenti per iniziare, ciò ridurrebbe il mio GAL a un collegamento. Se inizio con tre, ne rimarranno ancora due.
Certo, i flussi equilibrati fanno appello alle parti ossessive compulsive della mia personalità, ma questo non riflette ancora il traffico equilibrato. A parte questo, più collegamenti sono migliori in ogni modo.
Cosa posso ricordare (correggimi):
Etherchannel non carica l'equilibrio per dire, è distribuzione del carico. Una EC con un numero dispari di collegamenti non distribuirà il carico tra i collegamenti in modo uniforme: i collegamenti con numeri inferiori ricevono più traffico. Il traffico continuerà a scorrere se i collegamenti fisici sono interrotti.
Il traffico è bilanciato dall'indirizzo mac di destinazione (per impostazione predefinita). A seconda della topologia, ciò può comportare schemi di traffico indesiderati:
Se si dispone di un server di posta su uno switch con un EC tra switch, tutte le stazioni di lavoro sullo switch sull'altro lato dell'Etherchannel utilizzeranno lo stesso collegamento per raggiungere il server di posta .... se la maggior parte del traffico è destinata il server di posta, questo non fornisce bilanciamento del carico e per il server di posta viene utilizzato un solo collegamento nell'Etherchannel.
Questo può essere d'aiuto: https://supportforums.cisco.com/blog/150511/how-do-etherchannel-hash-algorithm-works-and-load-distribution-happen