SD-WAN Control Traffic Overhead Benutzerhandbuch

Einleitung

In diesem Dokument wird beschrieben, wie Sie den Overhead für den Steuerungsdatenverkehr in einer SD-WAN-Overlay-Bereitstellung berechnen. Bitte beachten Sie, dass der folgende Artikel für Viptela-Code unter 20.10.x und IOS-XE SD-WAN 17.10.x und darunter verwendet werden sollte (ab 20.10.x /17.10.x hat Cisco ein Push-Modell für die Datenerfassung implementiert). 

Problem

Eine häufig gestellte Frage, die zum Zeitpunkt der Entwurfsphase von einem Benutzer gestellt wird, lautet: "Wie hoch ist der Aufwand, den die SD-WAN-Lösung für unseren Zweigstromkreis verursachen würde?" Die Antwort ist, dass es von ein paar Variablen abhängt.

Lösung

Diese Fallstudie hilft Ihnen, diese Antwort zu finden. Bei den meisten Benutzern, die eine Zweigstellenrolle ausüben, kann der Internetanschluss bereitgestellt werden. Wenn sie einen haben, würde er normalerweise wie in Abbildung 1 aussehen.

Abbildung 1: SD-WAN-Außenstelle mit Internet- und Multiprotocol Label Switching (MPLS)-Schaltung.

Dies mag nicht immer der Fall sein, einige Benutzer würden es vorziehen, mit minimalen Änderungen und der Einführung neuer Schaltkreise auf SD-WAN zu migrieren, da die Hinzufügung von Schaltkreisen möglicherweise für eine spätere Phase geplant ist, was wie in Abbildung 2. ohne einen Internet-Schaltkreis wäre.

Abbildung 2. SD-WAN-Außenstelle mit nur einem MPLS-Schaltkreis.

Wenn Sie 100 Zweigstellen mit 2 Headends und einer vorgeschlagenen Full-Mesh-Topologie zwischen Zweigstellen und Head Ends haben und der Benutzer über einen strengen QoS-Standard mit 20 % Zuweisung zu Low Latency Queue (LLQ) für Sprache verfügt, können Sie so die Weichen stellen.

Welche Gemeinkosten wären bei einer Migration auf das SD-WAN für diese Zweigstellen zu berücksichtigen, falls ja, welche? Sehen wir uns das genauer an.

Anmerkung: Diese Berechnungen sind bei einem normalen Betriebsbedarf einschließlich Spitzenbedarf zu berücksichtigen. Aber berücksichtigen Sie nicht alle möglichen Szenarien.

Diese Zahlen wurden aus dem Labortest abgeleitet, der mit 1vManage-, 1vBond- und 1vSmart- sowie 255 BFD-Sitzungen durchgeführt wurde. 

Tabelle 1. Bandbreite pro Sitzung.

1 BFD-Sitzung/Nachbar	2 x 132 x 8 = 2,2 Kbit/s 2: In einer Sekunde werden bis zu 2 BFD-Pakete gesendet und empfangen. 132: BFD-Paketgröße in B
DTLS zu vSmart	bis zu 80 Kbit/s*
vPolling für Daten verwalten	bis zu 1,2 Mbit/s**
Aktivieren von DPI	200 Kbit/s

Kbit/s = Kilobit pro Sekunde

B = Byte

Mbit/s = Megabit pro Sekunde

* Abhängig von der Richtlinie und den Routen; diese Berechnung ist nur zum Zeitpunkt des ersten Austauschs erforderlich und der stabile Zustand ist viel niedriger/minimal um 200 B.

** Keine vom Benutzer ausgelösten Aktivitäten wie das Ausführen von Remote-Befehlen oder Admin-Technologie berücksichtigt; 1,2 Mbit/s erreichen Spitzenwerte.

Betrachtet man nun alle 100 Full-Mesh-Standorte mit 200 BFD-Sitzungen (2 Router pro Zweigstelle, 2 TLOCs pro Router mit eingeschränkter Farbe), würde die zuvor erwähnte Tabelle zu .x.

Tabelle 2. Queue0-Bandbreite für 200 BFD-Sitzungen [100 Standorte] mit vSmart und vManage Polling.

200 Sitzungen am nächsten Arbeitstag	440 Kbit/s 2,2 x 200
DTLS zu vSmart	bis zu 80 Kbit/s*
vPolls verwalten	bis zu 1,2 Mbit/s**
Gesamt	1.72 MBit/s

* Abhängig von der Richtlinie und den Routen; diese Berechnung ist nur zum Zeitpunkt des ersten Austauschs erforderlich und der stabile Zustand ist viel niedriger/minimal um 200 B.

** Keine vom Benutzer ausgelösten Aktivitäten wie das Ausführen von Remote-Befehlen oder Admin-Technologie berücksichtigt; 1,2 Mbit/s erreichen Spitzenwerte.

Denken Sie daran, dass all dieser Datenverkehr Queue0 LLQ erreicht. Diese Kontrolldatenverkehr erhalten immer Vorrang für Bürger erster Klasse, d. h. sie sind die letzte, die auf einer LLQ überwacht wird.

Häufig wird zum Zeitpunkt des QoS-Designs Sprachdatenverkehr in die Warteschlange 0 (Queue0, LLQ) gestellt, wobei 1,72 Mbit/s für 100 Zweigstellen mit vollständiger Vermaschung mit Tloc für SD-WAN erforderlich sind. Bei LLQ mit Zweigstellen mit niedriger Bandbreite wird Richtlinien/Drop angezeigt.

Nun, wenn Sie den Tloc-Erweiterungs-Overhead betrachten, der nicht zur Queue0 beiträgt, aber die Gesamtkapazitätsanforderung darstellt.

Tabelle 3. Allgemeine Bandbreitenanforderung, nachdem Sie überlegt haben, wie der Datenverkehr über die Tloc-Erweiterung gesteuert werden soll.

Queue0 erforderlich	1.72 MBit/s
200 BFD Session for Tloc Extension [Encrypted] (verschlüsselt), keine Warteschlange0	520 Kbit/s [440 + 80*]                [BFD + DTLS]
Gesamt	2.24 MBit/s

* Abhängig von der Richtlinie und den Routen; diese Berechnung ist nur zum Zeitpunkt des ersten Austauschs erforderlich und der stabile Zustand ist viel niedriger/minimal um 200 B.

Pro 100 Zweig voll vermascht mit TLOC-Erweiterungen mit Farbbegrenzung betrachten eine Kapazitätsplanung von ~2,5 Mbps auf eine extreme Anforderung, wieder können Sie Echtzeit-Befehle sammeln, Admin-Technologie wird in der oben genannten Berechnung nicht berücksichtigt, betrachten Sie dies in einer normalen Betriebssituation. 

Szenario 1.

Wenn Sie die Datenverkehrskontrollanforderungen an Queue0 anpassen müssen und eine Außenstelle nur über eine 10-Mbit/s-Leitung verfügt, muss diese mit einer QoS-Richtlinie von nur 20 % LLQ für Sprach- und Steuerungsdatenverkehr in das SD-WAN-Overlay integriert werden. Sie können sich eine verschlechterte Umgebung zum Zeitpunkt der Spitzenabfrage von vManage ansehen. Eine Hub-and-Spoke-Lösung ist in diesem Fall möglicherweise nicht hilfreich, da sie immer noch etwa 1,28 Mbit/s benötigt.

Tabelle 4. Hub-and-Spoke-Warteschlange0 - Bandbreitenanforderung.

4 BFD-Sitzungen mit Headends	8,8 Kbit/s [2,2 x 4]
DTLS zu vSmart	bis zu 80 Kbit/s*
vPolls verwalten	bis zu 1,2 Mbit/s**
Gesamt	1.28 MBit/s

* Abhängig von der Richtlinie und den Routen; diese Berechnung ist nur zum Zeitpunkt des ersten Austauschs erforderlich und der stabile Zustand ist viel niedriger/minimal um 200 B.

** Keine vom Benutzer ausgelösten Aktivitäten wie das Ausführen von Remote-Befehlen oder Admin-Technologie berücksichtigt; 1,2 Mbit/s erreichen Spitzenwerte.

Szenario 2.

Wenn Sie die QoS-Richtlinie umgestalten, um die zusätzliche Bandbreite von ~2 Mbit/s zu ermöglichen, können Sie die QoS LLQ von 20 % auf 40 % erhöhen. Dies hätte jedoch negative Auswirkungen auf Schaltungen mit höherer Bandbreite.

Abbildung 3: Typische 20 % Queue0-Zuweisung für QoS.

Für einen Schaltkreis mit 10 Mbit/s erhält Queue0 2 Mbit/s bei 20 %. Angenommen, dies ist ein typischer QoS-Standard für ein Unternehmen. Die SD-WAN-Übernahme erfordert eine Vollvermaschung. Sie müssen also die Zuweisung von Queue0 erhöhen, um 2 Mbit/s Overhead für Queue0 zu ermöglichen, wenn der Benutzer beschließt, die QoS-Zuweisung auf 40 % zu erhöhen, wie im Bild gezeigt.

Stellen Sie fest, dass eine enorme Menge von Queue0 für einen Schaltkreis die Ressourcen für die andere Warteschlange aufhebt. Der Unterschied liegt jedoch eher bei einem Schaltkreis mit größerer Bandbreite.

Idealerweise benötigen Sie die LLQ, um über eine feste Zuweisung für den Steuerungsdatenverkehr und eine weitere Warteschlange für Sprachdatenverkehr zu verfügen, aber beide benötigen eine Prioritätswarteschlange. Cisco Router unterstützen eine Prioritätswarteschlange mit zwei Ebenen, die als geteilte LLQ bezeichnet wird. Auch hier wird ein Problem mit der erforderlichen Mindestbandbreite nicht gelöst, sobald eine Mindestanforderung erfüllt wird. Ein geteilter LLQ wäre ein bevorzugtes QoS-Design.

LLQ aufteilen:

 

 

Mit Split LLQ fügen Sie der Warteschlange die erforderliche Bandbreite hinzu und behalten die Prioritätswarteschlange bei.

Die Split-LLQ unterstützt derzeit nur Addon-CLI. Split-LLQ kann zwei Ebenen der Prioritätswarteschlange aufweisen. Eine Beispielkonfiguration ist hier dargestellt. Die Konfiguration kann mit Variablen angepasst werden. Dieser Snippet reserviert 4 Mbit/s für den Steuerungsdatenverkehr und den Rest der Warteschlange als zugewiesenen Bandbreitenprozentsatz.

Beispiel für eine geteilte Warteschlange:

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

  !

!

!

Hinweis: Diese Konfigurationen werden auf ISR/ASR mit 17.3.x und Controllern mit 20.3.x getestet.

Allgemeine Richtlinie für die Gemeinkostenberechnung

Diese Tabelle hilft Ihnen bei der Kapazitätsplanung pro Stromkreis für einen SD-WAN-Steuerungsaufwand.

Tabelle 5. Generische Richtlinienkalkulation (vorausgesetzt, Sie haben Farbgrenzen).

Beispiel für die Gemeinkostenberechnung

Wenn Sie den Overhead des MPLS-Schaltkreises für 100 Standorte ähnlich dem hier gezeigten berechnen müssen, können Sie davon ausgehen, dass für jede Farbe die Grenzwerte aktiviert sind.

Anzahl der Standorte = 100

Anzahl der BFDs zu einem Standort von WAN-Standort = 2.

Tabelle 6. Berechnen des MPLS-Overheads für die Bereitstellung von 100 Standorten

Protokoll/Sitzung	Erforderliche Bandbreite
Warteschlange0	2,2 x [100 x 2] + 80 + 1200 BFD-Größe x [Anzahl der Standorte x Anzahl der BFDs zu einem Standort von WAN-Standort] + DTLS + vManage = 1,72 Mbit/s
Kontrolle des Datenverkehrs über TLOC	2,2 x [100 x 2] + 80 BFD-Größe x [Standorte x TLOC/pro Router] + DTLS = 520 Kbit/s
Gesamt	1720 Kbit/s + 520 Kbit/s = 2,24 Mbit/s

Der Queue0-Overhead von 1,72 Mbit/s und der gesamte Overhead von 2,24 Mbit/s.