SD-WAN Control Traffic Overhead Gebruikershandleiding

Inleiding

Dit document beschrijft hoe u de overheadkosten voor controleverkeer op een SD-WAN overlay-implementatie kunt berekenen. Let op dat het volgende artikel richtlijnen moet worden gebruikt op viptela code onder 20.10.x en IOS-XE SD-WAN 17.10.x en hieronder (vanaf 20.10.x /17.10.x heeft Cisco push-model voor gegevensverzameling geïmplementeerd). 

Probleem

Een veel gestelde vraag die wordt ontvangen op het moment van de ontwerpfase van een gebruiker is ‘Hoeveel overhead de SD-WAN oplossing zou maken naar ons filiaal circuit’? Het antwoord is dat het afhangt van een paar variabelen.

Oplossing

Deze casestudy helpt je bij het vinden van dat antwoord. De meeste gebruikers op het moment van een aftakking rol uit kunnen of kunnen niet het Internet circuit voorzien hebben. Als ze er een hebben zou het er typisch iets als figuur 1 uitzien.

Afbeelding 1. SD-WAN Branch met zowel internet- als Multiprotocol Label Switching (MPLS)-circuit.

Dit is misschien niet altijd het geval, sommige gebruikers zouden meestal liever migreren naar SD-WAN met minimale verandering en nieuwe circuit introductie, de toevoeging van circuit mogelijk gepland voor een latere fase, die zou zijn als Figuur 2. zonder een Internet circuit.

Afbeelding 2. SD-WAN Branch met alleen MPLS-circuit.

Om het stadium te bepalen, als u 100 takken met 2 HoofdEnden hebt, en een voorgestelde volledig-maastopologie tussen takken en HoofdEnden, en de gebruiker heeft een strikte QOS norm met 20% toewijzing aan Lage Latency Queue (LLQ) voor stem.

Met de migratie naar SD-WAN wat onze overheadkosten zijn om te overwegen voor deze takken, als zo. Laten we dieper graven.

NB: Deze berekeningen moeten worden beschouwd als zijnde van een normale bedrijfseis, met inbegrip van de piekvereisten. Neem echter niet alle mogelijke scenario's in overweging.

Deze getallen zijn afgeleid van de laboratoriumtest die is uitgevoerd met 1vManager, 1vBond en 1vSmart, 255 BFD-sessies. 

Tabel 1. Bandbreedte per sessie.

1 BFD-sessie/buur	2 x 132 x 8 = 2,2 Kbps 2: In een seconde verzend en ontvang je maximaal 2 BFD-pakketten 132: BFD-pakketgrootte in B
DTLS naar vSmart	tot 80 Kbps*
vManager-opiniepeiling voor gegevens	tot 1,2 Mbps**
DPI inschakelen	200 Kbps

Kbps = kilobits per seconde

B = bytes

Mbps = Megabits per seconde

* Afhankelijk van het beleid en de routes; deze berekening is alleen nodig op het moment van de eerste uitwisseling en de stabiele status is veel lager/minimaal rond 200 B.

** Overweegt geen door de gebruiker geactiveerde activiteit zoals het uitvoeren van externe opdrachten of admin-technologie; 1,2 Mbps is na een pieksnelheid.

Nu, als u alle 100 volledige maasplaatsen die 200 BFD-sessies (2 routers per tak, 2 TLOC's per router met beperking in kleur), de eerder genoemde tabel wordt.x.

Tabel 2. Queue0-bandbreedte voor 200 BFD-sessies [100 locaties] die polling met vSmart en vManager omvat.

200 BFD-sessie	440 Kbps [2,2 x 200]
DTLS naar vSmart	tot 80 Kbps*
vManager-peilingen	tot 1,2 Mbps**
Totaal	1.72 Mbps

* Afhankelijk van het beleid en de routes; deze berekening is alleen nodig op het moment van de eerste uitwisseling en de stabiele status is veel lager/minimaal rond 200 B.

** Overweegt geen door de gebruiker geactiveerde activiteit zoals het uitvoeren van externe opdrachten of admin-technologie; 1,2 Mbps is na een pieksnelheid.

Houd dit in gedachten al deze traffic hits Queue0 LLQ, deze controle verkeer krijgt altijd eerste-klas burger prioriteit wat betekent dat ze zijn de laatste die worden gecontroleerd op een LLQ.

Vaak op het tijdstip van het ontwerp QoS, wordt het stemverkeer geplaatst in Queue0 (LLQ), met een vereiste van 1.72 Mbps voor 100 takken volledig netwerk met Tloc voor SD-WAN, kunt u het controleren/laten vallen op LLQ met lage bandbreedte kringstakken zien.

Nu, als u de Tloc extensie overhead die niet zal bijdragen aan Queue0, maar vormt de totale capaciteit vereiste.

Tabel 3. Algehele bandbreedtevereiste nadat u hebt overwogen hoe u het verkeer via de Tloc-extensie kunt controleren.

Wachtrij0-vereiste	1.72 Mbps
200 BFD-sessie voor Tloc Extension [Encrypted] zonder wachtrij0	520 Kbps [440 + 80*]                [BFD + DTLS]
Totaal	2.24 Mbps

* Afhankelijk van het beleid en de routes; deze berekening is alleen nodig op het moment van de eerste uitwisseling en de stabiele status is veel lager/minimaal rond 200 B.

Per 100 tak volledig ingewisseld met TLOC-extensies met kleur beperken overwegen een capaciteitsplanning van ~2,5 Mbps op een extreme eis, opnieuw kunt u real-time opdrachten verzamelen, admin tech wordt niet overwogen in de eerder genoemde berekening, overwegen dit in een normale bedrijfssituatie. 

Scenario 1.

Als u de vereisten van het controleverkeer aan Queue0 moet aanpassen en als een tak slechts een kring 10 Mbps heeft, moet dat in SD-WAN overlay met een QoS-beleid van slechts 20% LLQ voor zowel spraak- als controleverkeer worden opgenomen. U kunt kijken naar een verslechterde ervaring op het moment van de peiling van vManager. Een hub and spoke-oplossing helpt in dit geval wellicht niet omdat deze nog steeds ongeveer 1,28 Mbps verbruikt.

Tabel 4. Vereiste hub en spraakwachtrij0-bandbreedte.

4 BFD-sessie naar head-ends	8,8 Kbps [2,2 x 4]
DTLS naar vSmart	Tot 80 Kbps*
vManager-peilingen	Tot 1,2 Mbps**
Totaal	1.28 Mbps

* Afhankelijk van het beleid en de routes; deze berekening is alleen nodig op het moment van de eerste uitwisseling en de stabiele status is veel lager/minimaal rond 200 B.

** Overweegt geen door de gebruiker geactiveerde activiteit zoals het uitvoeren van externe opdrachten of admin-technologie; 1,2 Mbps is na een pieksnelheid.

Scenario 2.

Als u besluit om het QoS-beleid te herontwerpen, om de ~2Mbps extra bandbreedte-vereiste aan te passen, kunt u de QoS LLQ verhogen van 20% naar 40%. Nochtans, zou dat een negatief effect op grotere bandbreedteschakelingen hebben.

Afbeelding 3. Standaard 20% wachtrij0-toewijzing voor QoS.

Voor een circuit van 10 Mbps krijgt Queue0 2 Mbps bij 20%. Stel dat dit een typische QoS-standaard is voor een bedrijf. SD-WAN adoptie vereist volledige mesh, dus u moet de toewijzing van Queue0 verhogen om 2 Mbps overhead aan Queue0 aan te passen als de gebruiker besluit om de QoS-toewijzing te verhogen naar 40% zoals in de afbeelding.

Zie dat een enorme hoeveelheid Queue0 voor een circuit de middelen voor de andere wachtrij wegneemt. Echter, het verschil is meer op een grotere bandbreedte circuit.

U moet idealiter LLQ hebben om een vaste toewijzing voor het controleverkeer en een andere rij voor spraakverkeer te hebben, maar beide vereisen een prioriteitswachtrij. Cisco-routers ondersteunen wel een prioriteitswachtrij met twee niveaus die gesplitste LLQ worden genoemd. Ook dit biedt geen oplossing voor een probleem met het minimale bandbreedtevereiste zodra aan een minimumvereiste is voldaan. Een gesplitste LLQ zou een voorkeur hebben voor een QoS-ontwerp

Splitsen LLQ:

 

 

Met Split LLQ voegt u de benodigde bandbreedte toe aan de wachtrij en houdt u nog steeds de prioriteitswachtrij.

De gesplitste LLQ ondersteunt momenteel alleen met addon CLI, waarbij gesplitste LLQ twee niveaus van de prioriteitswachtrij kan hebben, zou een voorbeeldconfiguratie zoals hier getoond zijn. De configuratie kan worden aangepast met variabelen, dit fragment reserveert 4 Mbps voor het controleverkeer en de rest van de wachtrij als toegewezen bandbreedtepercentage.

Voorbeeld van een splitsingswachtrij:

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

  !

!

!

Opmerking: deze configuraties zijn getest op ISR/ASR met 17.3.x en controllers op 20.3.x.

Generieke richtlijn voor overheadberekening

Deze tabel kan u helpen bij het plannen van de capaciteit per circuit voor een SD-WAN controle overhead.

Tabel 5. Berekening van de generieke richtlijn (ervan uitgaande dat u kleurbeperking hebt).

Voorbeeld van overheadberekening

Als u de overheadkosten van het MPLS-circuit voor 100 locaties moet berekenen, vergelijkbaar met de hier getoonde, kunt u ervan uitgaan dat elke kleur beperkingen heeft ingeschakeld.

Aantal locaties = 100

Aantal BFD's naar een site vanaf WAN Tloc = 2.

Tabel 6. Bereken de MPLS-overheadkosten voor de implementatie van 100 locaties.

Protocol/sessie	Vereiste bandbreedte
Wachtrij0	2,2 x [100 x 2] + 80 + 1200 BFD-grootte x [ no.of Sites x no.of BFD naar een site vanaf WAN Tloc] + DTLS +vManager = 1,72 Mbps
Beheer van verkeer via TLOC	2.2 x. [100 x 2] + 80 BFD-grootte x [Sites x TLOC/per router] + DTLS = 520 Kbps
Totaal	1720 Kbps + 520 Kbps = 2,24 Mbps

Queue0-overhead van 1,72 Mbps en totale overhead is 2,24 Mbps.