Inhoud

Inleiding

Probleem

Oplossing

Algemeen richtsnoer voor de berekening van de overheadkosten

Voorbeelden van de berekening van de bovenleiding

Inleiding

Dit document beschrijft hoe u de overheadkosten van het controleverkeer op een SD-WAN overlay implementatie kunt berekenen.

Probleem

Een veel voorkomende vraag die op het moment van de ontwerpfase van een gebruiker wordt ontvangen is 'Hoeveel overhead de SD-WAN oplossing voor ons stroomcircuit'? Het antwoord is dat het afhankelijk is van een paar variabelen.

Oplossing

Deze casestudy helpt u dat antwoord te vinden. De meeste gebruikers kunnen op het moment dat een filiaal buiten is, al dan niet een internetcircuit aanleveren. Als ze er een hebben, zou het er typisch uitzien als figuur 1.

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

Dit zou niet altijd het geval kunnen zijn, sommige gebruikers zouden meestal naar SD-WAN migreren met minimale verandering en nieuwe circuitintroductie, de toevoeging van circuit mogelijk gepland voor een latere fase, wat zou zijn zoals figuur 2. zonder een internetcircuit.

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

Om het stadium in te stellen, als u 100 takken met 2 Hoofdinstellingen hebt, en een voorgestelde topologie met volledige mazen tussen takken en Head-end, en de gebruiker heeft een strikte QOS standaard met 20% toewijzing aan Low Latency Queue (LLQ) voor spraak.

Wat zou, met de migratie naar SD-WAN, onze overhead zijn om rekening te houden met deze takken, als die er zijn. Laten we dieper graven.

Opmerking: Deze berekeningen dienen te worden beoordeeld op een normale operationele eis, inclusief een piekvereiste. Hierbij dient echter niet alle mogelijke scenario's in aanmerking te worden genomen.

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/buurman

2 x 132 x 8 = 2,2 Kbps

2: In een seconde ontvangt u tot 2 BFD-pakketten

132: BFD-pakketgrootte in B

DTLS naar vSmart

tot 80 Kbps*

vStelling beheren 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 ten tijde van de eerste uitwisseling en de stabiele staat is veel lager/minimaal rond 200 B.

** Beschouwt geen door de gebruiker veroorzaakte activiteit zoals het uitvoeren van opdrachten op afstand of beheerstechnologie; 1,2 Mbps is bij piekwaarde.

Nu, als u alle 100 volledige maaswijdten nadenkt die 200 BFD sessies (2 routers per tak, 2 TLOC's per router met beperkingen in kleur) zijn, zou de eerder genoemde tabel .x worden.

Tabel 2. Wachtrij0 Bandbreedte voor 200 BFD-sessies [100 locaties] met onder meer vSmart- en vManager-opiniepeilingen.

200 BFD-sessie

440 Kbps

[2,2 x 200]

DTLS naar vSmart

tot 80 Kbps*

Opiniepeilingen beheren

tot 1,2 Mbps**

Totaal

1,72 Mbps

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

** Beschouwt geen door de gebruiker veroorzaakte activiteit zoals het uitvoeren van opdrachten op afstand of beheerstechnologie; 1,2 Mbps is bij piekwaarde.

Houd dit in gedachten bij al deze verkeersopstoppingen in de Wachtrij0 LLQ, krijgt deze controle-handel altijd voorrang op eersteklas burgers, wat betekent dat ze de laatste zijn die op een LLQ worden gecontroleerd.

Vaak wordt op het moment van het QoS-ontwerp, spraakverkeer in Wachtrij0 (LLQ) geplaatst, met een vereisten van 1,72 Mbps voor 100 takken vol netwerk met TCP voor SD-WAN, kunt u controle/drop zien op LLQ met kleine bandbreedte-filialen.

Als je kijkt naar de verlenging van de Tloc, die niet zal bijdragen aan de wachtrij0, maar de totale capaciteitsbehoefte vormt.

Tabel 3. Algemene eis inzake bandbreedte nadat u hebt overwogen hoe u het verkeer via de Tloc-extensie kunt besturen.

Wachtrij0 vereist

1,72 Mbps

200 BFD-sessie voor TCP-uitbreiding [Versleuteld] niet-wachtrij0

520 Kbps [440 + 80*]

[BFD + DTLS]

Totaal

2,24 Mbps

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

Per 100 die volledig met TLOC extensies zijn verbonden met kleur beperken een capaciteitsplanning van ~2,5 Mbps aan een extreem vereiste, opnieuw kunt u realtime opdrachten verzamelen, is admin technologie niet in de eerder genoemde berekening meegenomen, bekijk dit in een normale bedrijfstoestand.

Scenario 1.

Als u controle verkeersvereisten naar Wachtrij0 moet aanpassen en als een tak slechts 10 Mbps heeft, moet dat in SD-WAN overlay worden gezet met een QoS-beleid van slechts 20% LLQ voor zowel spraak- als controle-verkeer. U kunt kijken naar een verminderde ervaring op het moment van de piek opiniepeiling van vManager. Een hub en een toespraak oplossing zou in dit geval niet kunnen helpen aangezien zij nog steeds ongeveer 1,28 Mbps verbruikt.

Tabel 4. Vereisten van hub en "Spoke Queue0".

4 BFD-sessie naar head-end

8,8 Kbps

[2,2 x 4]

DTLS naar vSmart

tot 80 Kbps*

Opiniepeilingen beheren

tot 1,2 Mbps**

Totaal

1,28 Mbps

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

** Beschouwt geen door de gebruiker veroorzaakte activiteit zoals het uitvoeren van opdrachten op afstand of beheerstechnologie; 1,2 Mbps is bij piekwaarde.

Scenario 2.

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

Afbeelding 3. Standaard 20% Wachtrij0 toewijzing voor QoS.

Voor een circuit van 10 Mbps krijgt Queue0 2 Mbps bij 20%. Stel dat dit een standaard QoS-standaard is voor een bedrijf. Voor SD-WAN adaptie is een volledig netwerk nodig, dus moet u de toewijzing van Queue0 uitbreiden om 2 Mbps overhead naar Wachtrij0 te ontvangen, als de gebruiker besluit de QoS-toewijzing te verhogen naar 40% zoals in de afbeelding weergegeven.

Zie dat een enorme hoeveelheid van Queue0 voor een circuit de middelen voor de andere wachtrij wegneemt. Maar het verschil is groter op een groter bandbreedtecircuit.

U moet idealiter de LLQ hebben om een vaste toewijzing te hebben voor het controleverkeer en een andere rij voor stemverkeer, maar beiden hebben een prioriteitswachtrij nodig. Cisco routers ondersteunen een prioriteitswachtrij met twee niveaus die bekend zijn als gesplitste LLQ, maar dit gaat opnieuw niet over een minimale bandbreedte-eis wanneer aan een gesplitste LLQ is voldaan, wat een geprefereerd QoS-ontwerp is

LLQ splitsen:

Met Split LLQ voegt u de gewenste bandbreedte toe aan de wachtrij en behoudt u de prioriteitswachtrij.

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

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 worden getest op ISR/ASR met 17.3.x en controllers op 20.3.x.

Algemeen richtsnoer voor de berekening van de overheadkosten

Deze tabel kan u helpen om capaciteit per circuit te plannen voor een SD-WAN control overhead.

Tabel 5. Berekening van algemene richtlijnen (aangenomen dat u kleur beperkt hebt).

Protocol/sessie

Bandbreedte vereist

Wachtrijen0

2.2 x [ geen locaties x nr. van BFD naar een site vanuit WAN-lokatie] + 80 + 1200

BFD formaat x [#siteSites x no.of BFD] naar een site vanuit WAN Tloc] + DTLS +vManager

= Wachtrij0_Toewijzing

Control-verkeer via TLOC

2,2 x [aantal locaties per router] + 80

BFD Size x [Sites x TLOC/per router] + DTLS

= Tloc_Allocation

Totaal

Wachtrij0_Allocatie + Tloc_allocatie

Voorbeelden van de berekening van de bovenleiding

Als u de overhead van het MPLS-circuit moet berekenen voor 100 locaties die lijken op de plek die hier wordt weergegeven, dan kunt u ervan uitgaan dat elke kleur de enabled-opties beperkt heeft.

Aantal locaties = 100

Aantal BFD op een site van WAN TLOC = 2.

Tabel 6. Bereken de MPLS-overhead voor de plaatsing van 100 locaties.

Protocol/sessie

Bandbreedte vereist

Wachtrijen0

2,2 x [100 x 2] + 80 + 1200

BFD formaat x [#siteSites x no.of BFD] naar een site vanuit WAN Tloc] + DTLS +vManager

= 1,72 Mbps

Control-verkeer via TLOC

2,2 x [100 x 2] + 80

BFD Size x [Sites x TLOC/per router] + DTLS

= 520 Kbps

Totaal

1720 Kbps + 520 Kbps

= 2,24 Mbps

Wachtrij0 overhead van 1,72 Mbps en de totale overhead is 2,24 Mbps.