Introduzione
Questo documento descrive come calcolare il sovraccarico del traffico di controllo su una distribuzione di overlay SD-WAN. Il seguente articolo guida deve essere utilizzato sul codice viptela inferiore a 20.10.x e IOS-XE SD-WAN 17.10.x e inferiore (dal 20.10.x /17.10.x Cisco ha implementato il modello push per la raccolta dei dati).
Problema
Una domanda comune che viene ricevuta da un utente al momento della fase di progettazione è "Quanto sovraccarico comporterebbe la soluzione SD-WAN per il nostro circuito derivato"? La risposta è che dipende da poche variabili.
Soluzione
Questo case study ti aiuta a trovare la risposta. La maggior parte degli utenti al momento dell'uscita di un ruolo di filiale può o non può avere il provisioning del circuito Internet. Se ce l'hanno, di solito assomiglia alla Figura 1.
Figura 1. Filiale SD-WAN con circuito Internet e Multiprotocol Label Switching (MPLS).
Questo potrebbe non essere sempre il caso, alcuni utenti preferirebbero migrare a SD-WAN con modifiche minime e introduzione di un nuovo circuito, l'aggiunta di circuito probabilmente pianificato per una fase successiva, che sarebbe come Figura 2. senza un circuito Internet.
Figura 2. Branch SD-WAN con solo circuito MPLS.
Per impostare la fase, se si dispone di 100 diramazioni con 2 headend e di una topologia a maglia completa proposta tra diramazioni e headend, l'utente dispone di uno standard QOS rigoroso con il 20% allocato a Low Latency Queue (LLQ) per la voce.
Con la migrazione a SD-WAN, quale sarebbe il nostro sovraccarico da prendere in considerazione per queste filiali, se così fosse. Scaviamo più a fondo.
Nota: questi calcoli devono essere considerati a un normale requisito operativo comprensivo del fabbisogno di picco. Tuttavia, non considerare tutti gli scenari possibili.
Questi numeri sono derivati dal test di laboratorio eseguito con 1vManage, 1vBond e 1vSmart, 255 sessioni BFD.
Tabella 1. Larghezza di banda per sessione.
1 sessione BFD/router adiacente |
2 x 132 x 8 = 2,2 Kbps 2: In un secondo si inviano e si ricevono fino a 2 pacchetti BFD 132: dimensioni del pacchetto BFD in B |
Da DTLS a vSmart |
fino a 80 Kbps* |
vManage - polling dei dati |
fino a 1,2 Mbps** |
Abilitazione DPI |
200 Kbps |
Kbps = kilobit al secondo
B = Byte
Mbps = Megabit al secondo
* Dipende dalla politica e dai percorsi; questo calcolo è necessario solo al momento dello scambio iniziale e lo stato stabile è molto più basso/minimo intorno a 200 B.
** Non prende in considerazione un'attività avviata dall'utente come l'esecuzione di comandi remoti o admin tech; 1,2 Mbps è al picco massimo.
Ora, se si considerano tutti i 100 siti a maglia piena che sono 200 sessioni BFD (2 router per filiale, 2 TLOC per router con restrizioni di colore), la tabella sopra riportata diventerebbe .x.
Tabella 2. Larghezza di banda della coda0 per 200 sessioni BFD [100 siti] che includono il polling vSmart e vManage.
Sessione 200 BFD |
440 Kbps [2,2 x 200] |
Da DTLS a vSmart |
fino a 80 Kbps* |
vManage - sondaggi |
fino a 1,2 Mbps** |
Totale |
1.72 Mbps |
* Dipende dalla politica e dai percorsi; questo calcolo è necessario solo al momento dello scambio iniziale e lo stato stabile è molto più basso/minimo intorno a 200 B.
** Non prende in considerazione un'attività avviata dall'utente come l'esecuzione di comandi remoti o admin tech; 1,2 Mbps è al picco massimo.
Tenete presente che tutti questi traffici raggiungono Queue0 LLQ, questo traffico di controllo è sempre data priorità cittadino di prima classe, il che significa che sono l'ultimo ad essere sorvegliato su un LLQ.
Spesso, al momento della progettazione QoS, il traffico vocale viene posizionato in Queue0 (LLQ), con un requisito di 1,72 Mbps per 100 rami full mesh con Tloc per SD-WAN, è possibile vedere policing/drop su LLQ con rami di circuito a bassa larghezza di banda.
Ora, se si considera il sovraccarico dell'estensione Tloc che non contribuirà alla Coda0 ma costituisce il requisito di capacità complessiva.
Tabella 3. Requisiti generali di larghezza di banda dopo aver considerato come controllare il traffico sull'estensione Tloc.
Requisito coda0 |
1.72 Mbps |
200 BFD Session per estensione Tloc [Encrypted] Non Queue0 |
520 Kbps [440 + 80*] [BFD + DTLS] |
Totale |
2.24 Mbps |
* Dipende dalla politica e dai percorsi; questo calcolo è necessario solo al momento dello scambio iniziale e lo stato stabile è molto più basso/minimo intorno a 200 B.
Per 100 filiali full meshed con estensioni TLOC con restrizioni di colore considerare una pianificazione di capacità di circa 2,5 Mbps su un requisito estremo, ancora una volta è possibile raccogliere comandi in tempo reale, admin tech non è considerato nel calcolo precedente, considerare questo in una normale situazione di funzionamento.
Scenario 1.
Se è necessario adattare i requisiti di controllo del traffico alla Coda0 e se una diramazione ha solo un circuito a 10 Mbps, deve essere integrata in SD-WAN overlay con una policy QoS di solo il 20% LLQ per il traffico voce e di controllo. È possibile osservare un'esperienza degradata al momento del polling di picco da vManage. Una soluzione Hub and Spoke potrebbe non essere di aiuto in questo caso, in quanto consuma ancora circa 1,28 Mbps.
Tabella 4. Requisiti di larghezza di banda per la coda hub e spoke0.
4 BFD in sessione con headend |
8,8 Kbps [2,2 x 4] |
Da DTLS a vSmart |
fino a 80 Kbps* |
vManage - sondaggi |
fino a 1,2 Mbps** |
Totale |
1.28 Mbps |
* Dipende dalla politica e dai percorsi; questo calcolo è necessario solo al momento dello scambio iniziale e lo stato stabile è molto più basso/minimo intorno a 200 B.
** Non prende in considerazione un'attività avviata dall'utente come l'esecuzione di comandi remoti o admin tech; 1,2 Mbps è al picco massimo.
Scenario 2.
Se si decide di riprogettare la regola QoS, per soddisfare i requisiti di larghezza di banda aggiuntiva di circa 2 Mbps, è possibile aumentare la quantità di dati LLQ QoS dal 20% al 40%. Tuttavia, questo avrebbe un effetto negativo sui circuiti di larghezza di banda più ampia.
Figura 3. Allocazione tipica Coda0 del 20% per QoS.
Per un circuito a 10 Mbps, la coda 0 ottiene 2 Mbps al 20%. Si supponga che si tratti di un tipico standard QoS per un'azienda. L'adozione di SD-WAN richiede una mesh completa, quindi è necessario aumentare l'allocazione di Queue0 per supportare un sovraccarico di 2 Mbps per Queue0 se l'utente decide di aumentare l'allocazione QoS al 40%, come mostrato nell'immagine.
Si noti che un'enorme quantità di Queue0 per un circuito sottrae risorse all'altra coda. Tuttavia, la differenza è maggiore in un circuito con larghezza di banda maggiore.
È preferibile che LLQ disponga di un'allocazione fissa per il traffico di controllo e di un'altra coda per il traffico vocale, ma entrambe richiedono una coda di priorità. I router Cisco supportano una coda di priorità con due livelli noti come split LLQ; anche in questo caso, non è possibile risolvere un problema di larghezza di banda minima una volta soddisfatto un requisito minimo. Un split LLQ è il progetto QoS preferito
Dividi LLQ:
Con Split LLQ, si aggiunge la larghezza di banda necessaria alla coda e si mantiene la coda di priorità.
L'LLQ diviso attualmente supporta solo con CLI aggiuntivo, con LLQ diviso potrebbe avere due livelli della coda di priorità, una configurazione di esempio sarebbe come mostrato di seguito. La configurazione può essere personalizzata con variabili, questo frammento riserva 4 Mbps per il traffico di controllo e il resto della coda come percentuale di larghezza di banda assegnata.
Esempio di coda divisa:
policy-map GBL_edges_qosmap_rev1
class Queue0
priority level 1
police cir 2000000 bc 250000
conform-action transmit
exceed-action drop
!
!
class Queue1
bandwidth remaining ratio 16
random-detect precedence-based
!
class class-default
bandwidth remaining ratio 8
random-detect precedence-based
!
class Queue3
bandwidth remaining ratio 16
random-detect precedence-based
!
class Queue4
bandwidth remaining ratio 32
random-detect precedence-based
!
class Queue5
bandwidth remaining ratio 8
random-detect precedence-based
!
class Queue6
priority level 2
police rate percent 20
!
!
!
Nota: queste configurazioni sono testate su ISR/ASR con versione 17.3.x e su Controller con versione 20.3.x.
Linee guida generali per il calcolo dei costi comuni
Questa tabella può aiutare a pianificare la capacità per circuito per un sovraccarico di controllo SD-WAN.
Tabella 5. Calcolo delle linee guida generiche (si presume che il colore sia limitato).
|
Larghezza di banda richiesta
|
|
2.2 x [ n. di siti x n. di BFD su un sito da WAN Tloc] + 80 + 1200
Dimensione BFD x [ n. di siti x n. di BFD in un sito da WAN Tloc] + DTLS +vManage
|
Controllo del traffico su TLOC
|
2,2 x [n. di siti x Tloc/per router] + 80
Dimensione BFD x [Siti x TLOC/per router] + DTLS
= Allocazione_Tloc
|
|
Coda0_Allocazione + Allocazione_tloc
|
Esempio di calcolo dei costi comuni
Se è necessario calcolare il sovraccarico del circuito MPLS per 100 siti in modo simile a quello mostrato di seguito, si può supporre che per ciascun colore sia abilitata la limitazione.
N. di siti = 100
Nr. di DCF su un sito da WAN Tloc = 2.
Tabella 6. Calcolare il sovraccarico MPLS per l'implementazione di 100 siti.
|
Larghezza di banda richiesta
|
|
2,2 x [100 x 2] + 80 + 1200
Dimensione BFD x [ n. di siti x n. di BFD in un sito da WAN Tloc] + DTLS +vManage
|
Controllo del traffico su TLOC
|
Dimensione BFD x [Siti x TLOC/per router] + DTLS
= 520 Kbps
|
|
1720 Kbps + 520 Kbps
= 2,24 Mbps
|
Coda0 di 1,72 Mbps e sovraccarico totale di 2,24 Mbps.