Guide de l'utilisateur de surcharge du trafic de contrôle SD-WAN

Introduction

Ce document décrit comment calculer la surcharge du trafic de contrôle sur un déploiement de superposition SD-WAN. Veuillez noter que les conseils d'article suivants doivent être utilisés sur le code viptela inférieur à 20.10.x et IOS-XE SD-WAN 17.10.x et inférieur (à partir de 20.10.x /17.10.x, Cisco a mis en oeuvre un modèle push pour la collecte de données). 

Problème

Lors de la phase de conception, un utilisateur se pose souvent la question suivante : « Quelle surcharge la solution SD-WAN entraînerait-elle pour notre circuit de filiale ? » La réponse est que cela dépend de quelques variables.

Solution

Cette étude de cas vous aide à trouver cette réponse. La plupart des utilisateurs au moment d'un rôle de filiale peuvent ou ne peuvent pas avoir le circuit Internet mis en service. S'ils en ont un, il ressemblerait généralement à la Figure 1.

Figure 1 : SD-WAN Branch avec Internet et circuit MPLS (Multiprotocol Label Switching).

Cela pourrait ne pas être toujours le cas, certains utilisateurs préféreraient pour la plupart migrer vers SD-WAN avec un changement minimal et l'introduction d'un nouveau circuit, l'ajout d'un circuit peut-être prévu pour une phase ultérieure, qui serait comme la Figure 2. sans circuit Internet.

Figure 2. SD-WAN Branch avec circuit MPLS uniquement.

Afin de préparer le terrain, si vous avez 100 branches avec 2 têtes de réseau, et une topologie à maillage global proposée entre les branches et les têtes de réseau, et que l'utilisateur a une norme QOS stricte avec une allocation de 20 % à la file d'attente à faible latence (LLQ) pour la voix.

Avec la migration vers le SD-WAN, quelle serait notre surcharge à prendre en compte pour ces filiales, le cas échéant. Nous allons creuser plus profondément.

Note : Ces calculs doivent être considérés à une exigence opérationnelle normale incluant l'exigence maximale. Cependant, n'envisagez pas tous les scénarios possibles.

Ces chiffres proviennent du test de TP effectué avec les sessions 1vManage, 1vBond et 1vSmart, 255 BFD. 

Tableau 1 . Bande passante par session.

1 session BFD/Voisin	2 x 132 x 8 = 2,2 Kbits/s 2 : En une seconde, vous envoyez et recevez jusqu'à 2 paquets BFD 132 : Taille des paquets BFD en B
DTLS vers vSmart	jusqu'à 80 Kbits/s*
vManage interrogation des données	jusqu'à 1,2 Mbit/s**
Activation de DPI	200 Kbps

Kbits/s = kilobits par seconde

B = Octets

Mbits/s = Mégabits par seconde

* Dépend de la politique et des routes ; ce calcul est nécessaire seulement au moment de l'échange initial et l'état stable est beaucoup plus faible/minimal autour de 200 B.

** Ne tient pas compte d'une activité déclenchée par l'utilisateur, telle que l'exécution de commandes à distance ou la technologie d'administration ; 1,2 Mbit/s est au pic.

Maintenant, si vous considérez tous les 100 sites à maillage global qui sont 200 sessions BFD (2 routeurs par branche, 2 TLOC par routeur avec restrict en couleur), le tableau précédemment mentionné deviendrait.x.

Tableau 2 . Queue0 Bande passante pour 200 sessions BFD [100 sites] qui inclut les interrogations vSmart et vManage.

200 sessions BFD	440 Kbps [2,2 x 200]
DTLS vers vSmart	jusqu'à 80 Kbits/s*
vManage sondages	jusqu'à 1,2 Mbit/s**
Total	1.72 Mbit/s

* Dépend de la politique et des routes ; ce calcul est nécessaire seulement au moment de l'échange initial et l'état stable est beaucoup plus faible/minimal autour de 200 B.

** Ne tient pas compte d'une activité déclenchée par l'utilisateur, telle que l'exécution de commandes à distance ou la technologie d'administration ; 1,2 Mbit/s est au pic.

Gardez cela à l'esprit tout ce trafic atteint Queue0 LLQ, ce trafic de contrôle est toujours donné priorité citoyen de première classe ce qui signifie qu'ils sont le dernier à être réglementé sur une LLQ.

Souvent, au moment de la conception de la QoS, le trafic voix est placé dans la file d'attente LLQ (Queue0), avec une exigence de 1,72 Mbits/s pour 100 branches maillées avec Tloc pour SD-WAN, vous pouvez voir la réglementation/suppression sur LLQ avec des branches de circuit à faible bande passante.

Maintenant, si vous considérez la surcharge d'extension Tloc qui ne contribuera pas à Queue0 mais constitue l'exigence de capacité globale.

Tableau 3 . Besoin global en bande passante après avoir examiné comment contrôler le trafic sur l'extension Tloc.

Queue0 requise	1.72 Mbit/s
200 sessions BFD pour extension Tloc [chiffrée] non Queue0	520 Kbits/s [440 + 80*]                [BFD + DTLS]
Total	2.24 Mbit/s

* Dépend de la politique et des routes ; ce calcul est nécessaire seulement au moment de l'échange initial et l'état stable est beaucoup plus faible/minimal autour de 200 B.

Par 100 branche entièrement maillé avec extensions TLOC avec restriction de couleur envisager une planification de capacité de ~2,5 Mbits/s sur une exigence extrême, encore une fois, vous pouvez collecter des commandes en temps réel, admin tech n'est pas pris en compte dans le calcul mentionné précédemment, considérer cela dans une situation de fonctionnement normal. 

Scénario 1.

Si vous devez prendre en charge les exigences de trafic de contrôle vers Queue0 et si une filiale n'a qu'un circuit de 10 Mbits/s, cela doit être intégré dans la superposition SD-WAN avec une politique de QoS de seulement 20 % LLQ pour le trafic voix et le trafic de contrôle. Vous pouvez observer une dégradation de l'expérience au moment de l'interrogation de pointe à partir de vManage. Dans ce cas, une solution Hub and Spoke peut ne pas être utile, car elle consomme toujours environ 1,28 Mbit/s.

Tableau 4 . Bande passante requise pour Hub and Spoke Queue0.

4 sessions BFD vers les têtes de réseau	8,8 Kbps [2,2 x 4]
DTLS vers vSmart	jusqu'à 80 Kbits/s*
vManage sondages	jusqu'à 1,2 Mbit/s**
Total	1.28 Mbit/s

* Dépend de la politique et des routes ; ce calcul est nécessaire seulement au moment de l'échange initial et l'état stable est beaucoup plus faible/minimal autour de 200 B.

** Ne tient pas compte d'une activité déclenchée par l'utilisateur, telle que l'exécution de commandes à distance ou la technologie d'administration ; 1,2 Mbit/s est au pic.

Scénario 2.

Si vous décidez de reconcevoir la politique de QoS pour répondre aux besoins en bande passante supplémentaire d'environ 2 Mbits/s, vous pouvez augmenter la QL de QoS de 20 % à 40 %. Cependant, cela aurait un effet négatif sur les circuits à bande passante plus large.

Figure 3. Allocation type 20 % de file d'attente0 pour QoS.

Pour un circuit de 10 Mbits/s, Queue0 obtient 2 Mbits/s à 20 %. Supposons qu'il s'agisse d'une norme QoS standard pour une entreprise. L'adoption du SD-WAN nécessite un maillage global. Par conséquent, vous devez augmenter l'allocation de Queue0 pour prendre en charge une surcharge de 2 Mbits/s vers Queue0 si l'utilisateur décide d'augmenter l'allocation de QoS à 40 %, comme illustré dans l'image.

Notez qu'une quantité énorme de Queue0 pour un circuit enlève les ressources de l'autre file d'attente. Cependant, la différence est plus importante sur un circuit à bande passante plus large.

Idéalement, vous devez avoir la LLQ pour avoir une allocation fixe pour le trafic de contrôle et une autre file d'attente pour le trafic vocal, mais les deux nécessitent une file d'attente prioritaire. Les routeurs Cisco prennent en charge une file d'attente prioritaire avec deux niveaux appelés « split LLQ », ce qui ne résout pas le problème de bande passante minimale une fois qu'une exigence minimale est satisfaite. Une « split LLQ » serait une conception QoS préférée

Fractionner LLQ :

 

 

Avec Split LLQ, vous ajoutez la bande passante nécessaire à la file d'attente et conservez la file d'attente prioritaire.

Le split LLQ ne prend actuellement en charge qu'avec l'interface CLI supplémentaire, avec le split LLQ pourrait avoir deux niveaux de file d'attente prioritaire, un exemple de configuration serait comme illustré ici. La configuration peut être personnalisée avec des variables, cet extrait réserve 4 Mbits/s pour le trafic de contrôle et le reste de la file d'attente comme pourcentage de bande passante attribué.

Exemple de file d'attente fractionnée :

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

  !

!

!

Remarque : ces configurations sont testées sur ISR/ASR exécutant 17.3.x et les contrôleurs sur 20.3.x.

Ligne directrice générique pour le calcul des frais généraux

Ce tableau peut vous aider à planifier la capacité par circuit pour une surcharge de contrôle SD-WAN.

Tableau 5 . Calcul générique de la recommandation (suppose que vous avez une restriction de couleur).

Exemple de calcul des frais généraux

Si vous devez calculer le temps système du circuit MPLS pour 100 sites, comme celui illustré ici, vous pouvez supposer que la fonction de restriction est activée pour chaque couleur.

Nombre de sites = 100

Nbre de BFD vers un site à partir de l'emplacement WAN = 2.

Tableau 6 . Calculez la surcharge MPLS pour le déploiement de 100 sites.

Protocole/session	Bande passante requise
File0	2,2 x [100 x 2] + 80 + 1 200 Taille BFD x [ no.of Sites x no.of BFD vers un site à partir de l'horloge WAN] + DTLS + vManage = 1,72 Mbit/s
Contrôle du trafic sur TLOC	2,2 x [100 x 2] + 80 Taille BFD x [Sites x TLOC/par routeur] + DTLS = 520 Kbits/s
Total	1 720 Kbits/s + 520 Kbits/s = 2,24 Mbits/s

Surcharge de la file d'attente0 de 1,72 Mbits/s et surcharge totale de 2,24 Mbits/s.