MPLS med Quality of Service, QoS

Quality of Service QoS med MPLS Jacob Zartmann Conscia

Det här inlägget kommer att titta på hur Quality of Service (QoS, garanterad tjänstekvalitet) fungerar i en MPLS-miljö. Standardbeteendet för MPLS QoS visas. Därefter förklarar och demonstrerar jag de tre MPLS QoS DiffServ-modellerna – Uniform, Pipe och Short Pipe. Som vanligt, förvänta dig både konfigurationsexempel och wireshark-captures. Förvänta dig dock inte några tjusiga QoS-policyer eftersom det här inläggets mål är att visa teknikbegreppen snarare än att fokusera på QoS i sig. Jag kommer därmed inte att diskutera hur policing, formandet eller köandet fungerar.

Denna topologi används genom hela inlägget:

QoS garanterad tjänstekvalitet med MPLS Jacob Zartmann CCIE Conscia

Eve-ng-fil finns här om du vill följa med: EVE-NG – MPLS QoS – zartmann

Standard QoS-beteende i MPLS-nätverk

Utan några policys någonstans, kan vi försöka skicka trafik från CE1 till CE2 med en markering av CS6. Vi kan använda telnet eller SSH eftersom IOS markerar denna trafik med CS6 som standard.

För att bättre se vad som är vad i våra wireshark captures, låt oss titta på MAC-adresserna för CE1 och CE2:

SP-routrarnas MAC-adresser har detta format:

Det kan lätt ses var paketet skickas från/till. Den första oktetten efter OUI innehåller routernumret och den sista oktetten gränssnittsidentifieraren där Gi1 == 0 och Gi2 == 1.

Låt oss SSH:a till CE2 från CE1:

Om vi ​​nu tittar på markeringarna av SSH-trafiken när den lämnar CE1 ser vi CS6 i IP-huvudet:

Och när trafiken tas emot på CE2:

Så utan några policyer någonstans behåller kunderna sina markeringar från ändpunkt till ändpunkt.

Vad sägs om markeringarna i SP-nätverket? För samma trafik, om vi tittar på ingress PE (PE3) när trafik skickas in i MPLS-core:

Eftersom detta är en L3VPN lägger vi på en etikettbunt med två etiketter. En (översta etiketten) för transport till egress PE (PE6) och botten (VPN-etikett) för att identifiera VRF, utgående gränssnitt och nästa hopp efter destinationen. Båda etiketterna innehåller EXP 6-värdet.

Så när vi sätter på etiketter är standardbeteendet att kopiera IP-precedensen eller de tre mest betydande (till vänster) bitarna av DiffServ-markeringarna från IP till MPLS EXP i ALLA pålagda etiketter.

Om vi ​​ändrar EXP-värdet för den översta etiketten vid utläggningen av PE3, vad händer då på PHP-routern där vi har implicit null (vi poppar den översta etiketten)? För att demonstrera detta skapar vi en enkel policy i PE3:

Låt oss nu SSH:a och titta på trafiken på PE3 när den lämnar Gi1 mot kärnan:

Vi ser att policyn fungerar eftersom den översta etiketten nu har EXP 3 för SSH-trafiken när den skickas till kärnan.

Och på vår PHP-router, P5, vad händer där när trafik skickas till egress PE (PE6) på Gi2? Vi tittar:

Den övre etiketten tas bort och botten (VPN-etiketten) lämnas som den är, vilket innebär att det bär det IP-mappade värdet i fältet EXP – EXP 6.

Om vi ​​vill behålla det förändrade EXP-värdet när trafik skickas till  PE-egressen måste vi göra ett etikettbyte och inte en pop. För att göra detta kan vi använda den explicita istället för den implicita nulletiketten. Detta signaleras via LDP av PE-egressen (PE6):

När vi nu SSH:ar till CE2 från CE1, vad händer på PHP-routern, P5?

Med den explicita nulletiketten kan vi fortsätta markeringarna i vår toppetikett.

 

Lärda beteenden i QoS

Med ovanstående scenarier vet vi nu detta om QoS för MPLS Networks:

  • Utan policys kopieras kundernas markeringar till alla pålagda etiketter
    • Kundens markeringar lämnas orörda
  • Vid etikettbyte behåller den översta etiketten det ändrade värdet
  • Vid PHP kopieras inte EXP-värdet till VPN-etikettens EXP-värde
  • Om explicit null används, överför PHP-routern toppetikettens EXP-värde till en EXP-nulletikett för att behålla markeringarna när trafik skickas till PE-egressen.

 

Uniform mode

Det här läget är vanligt för kunder som har sitt eget MPLS-nätverk. Det viktiga här är att på PE-egressen kopierar vi MPLS EXP-värdet till IP-headern innan vi skickar trafik till CE. Med andra ord återspeglar vi MPLS-core markeringar till det omärkta IP-paketet. Det ger oss en enhetlig QoS-policy från ändpunkt till ändpunkt som vi vill ha när vi har kontroll på hela nätverket.

Med denna modell är  PE-egressens policy baserad på MPLS EXP-värden.

Låt oss titta på hur detta görs:

Om vi ​​implementerar policyn som visas ovan, bör vi se en CS3-märkning i IP-headern eftersom paketet skickas från PE6 till CE2.

Den första P4 har en policer som markerar EXP 6-trafik som överstiger 8 kbps till EXP 3. Vår egress PE, PE6, gör en explicit-null  för att ta emot det ändrade EXP-värdet på 3 från P5, vår PHP-router. För att kunna sprida EXP-värdet i IP-paketet innan det går ut mot CE2-routern behöver vi en platshållare. Det beror på att PE6 kommer att göra sin kontroll på den mottagna VPN-etiketten, exponera alla etiketter och vidarebefordra det omärkta IP-paketet Gi2 mot CE:n. Om vi ​​skulle konfigurera en policy som säger att vi ska kopiera EXP-värdet till IP-headern out Gi2, kan vi inte matcha EXP-värdet eftersom det inte finns några etiketter. Därför skapas ett internt värde eller en platshållare. Detta är vad en QoS Group gör. När trafiken tas emot matchar vi mot EXP 3 och ställer in QoS Group 3. När trafiken lämnar PE6 matchar vi mot QoS Group 3 och sätter IP prec 3. Det slutliga resultatet blir:

Nu har vi en enhetlig policy där markeringar i kärnan kopieras ner till IP-paketet när det skickas mot CE. Med enhetligt läge kopierar vi bara IP-markeringarna till EXP-värdet vid label imposition och ändrar därmed inget vid ingress i SP-nätverket. Naturligtvis är det upp till administratören vad som görs med markeringarna.

 

Pipe

Pipeläge är nästa QoS-modell som vi tittar på. Här rör inte SP kundens markeringar. Policyn baseras enbart på SP-markeringarna i SP-nätverket. Till och med policyn för edge mot kunden är baserad på EXP-bitarna precis som med enhetligt läge. Med pipeläge upprätthåller vi policy ingress på PE:n och ställer in ett EXP-värde – vanligtvis på alla pålagda etiketter. Kunden får veta hur han ska markera sin trafik och detta kommer sedan att kartläggas korrekt i de klasser som erbjuds av SP.

Meningen med pipeläge är att vi konfigurerar policyn vid egressen av SP-nätverket baserat på EXP-värden. Det innebär att vi måste se till att märkningen som är inställd på ingress överförs till egress PE. Återigen kan exp-null-etiketten användas.

zartman16 topology pipe

Policykonfigurationen:

Här markerar vi återigen kundens CS6-värde till EXP 3 vid ingress på PE3. Detta bör ge oss en etikettbunt där alla pålagda etiketter har EXP 3 uppsättning. Vid egress har vi fortfarande exp-null konfigurerat, även om detta varken kan vara standard-imp-null beroende på om vi ändrar det mest markerade EXP-värdet i SP-nätverkets core. Om vi ​​gör det, kommer vi sannolikt att vilja fortsätta denna förändring av egress PE för policys gentemot kunden. För att demonstrera detta har jag konfigurerat CBWFQ för att garantera 15% bandbredd för den här klassen, när trafik skickas till kunden på PE6. Observera att eftersom vi tar bort alla etiketter används QoS gruppen som platshållare. Alternativt kan vi också konfigurera en discard class för att undvika överbelastning.

Låt oss titta på vad som faktiskt händer i paketen. Vi börjar med att titta på vad paketets EXP-markeringar är när de lämnar ingress PE, PE3:

Quality of Service QoS med MPLS Jacob Zartmann CCIE Conscia

Båda etiketterna har EXP 3 som vi sa till routern att införa.

Vad händer då med egress PE? Låt oss titta på paketet eftersom det både kommer in i PE6 och lämnar PE6:

Quality of Service QoS med MPLS Jacob Zartmann CCIE Conscia

Här har vi både den explicita nolletiketten och VPN-etiketten. Båda med EXP 3 som vi sätter på ingressen PE. Och när vi skickar paketet mot CE2:

Quality of Service QoS med MPLS Jacob Zartmann CCIE Conscia

Kundens markering lämnas intakt, men QoS-policyn vid egressen är baserad på vår EXP-märkning.

 

Kort pipe

Den sista varianten av QoS DiffServ-modeller för MPLS-nätverk som vi tittar på är en annan variant av pipemodellen som visas ovan. Med kort pipe, konfigurerar SP egress-policyn baserat på kundens markering, L3-markeringarna i IP-headern.  På grund av detta har vi inte längre något behov av att fortsätta toppetikettens EXP-markeringar mot egress PE och vi kan på ett säkert sätt inaktivera explicit null och bara använda standarden för implicit null, vilket betyder att vi har PHP aktiverat.

Quality of Service QoS med MPLS Jacob Zartmann CCIE Conscia

Lägg märke till i ovanstående topologi att vi nu bara har en VPN-etikett när vi skickar paketen till PE-egressen. Policyn är också baserad på kundens markeringar.

Quality of Service QoS med MPLS Jacob Zartmann CCIE Conscia

En något enklare policy utan QoS-grupp. Bara för att verifiera att imp-null är i bruk, kan vi titta på P5:

QoS garanterad tjänstekvalitet med MPLS Jacob Zartmann CCIE Conscia

Och om vi tittar på paketen när de kommer in i PE6, bör vi bara se en etikett – VPN-etiketten:

QoS garanterad tjänstekvalitet med MPLS Jacob Zartmann CCIE Conscia

Bara en etikett som förväntat. Vi kan titta på PE3 bara för att se om detta i själva verket var etiketten som infördes som den nedre etiketten:

QoS garanterad tjänstekvalitet MPLS Jacob Zartmann CCIE Conscia

Som förväntat är etikett 21 VPN-etiketten som införs av PE3.

 

Explicit Null

Om inga tjänster är konfigurerade, och du bara har etikettswitchade IP packet globalt till exempel, måste du konfigurera exp-null på  PE-egressen, om du inte kan konfigurera policys baserade på MPLS EXP vid egressen. Annars kommer ett inbyggt IP-paket att tas emot på PE-egressen.

 

Sammanfattning: MPLS med QoS

Detta avslutar QoS DiffServ-modellerna för MPLS-nätverk. Vi såg hur routerns standardbeteende är och hur de tre modellerna kan användas för att erhålla QoS-policyer i en SP-miljö. Den enhetliga modellen är vanligtvis baserad på kundens markeringar vid ingress och om markeringarna ändras var som helst på banan kopierar vi dessa nya värden till IP-paketet innan vi skickar det till CE. Pipemodellen är baserad på SP-markeringarna. Policys för  PE-egress gentemot kunden baseras också på SP:s EXP-märkning. Kundens markeringar hålls intakta för pipemodeller – inklusive kort pipe. Med kort pipe är policyn gentemot kunden baserad på kundens markeringar. Här kan vi ha implicit null eftersom vi inte behöver EXP-värden på PE-egressen för policyn.

Observera att mängder av dokumentation visar att toppetikettens EXP-värde kopieras till VPN-etiketten på PHP. Detta är överlägset vanligast. Ingenting händer automatiskt utom det som är angivet som standard-beteenden. Du kan kopiera värdet på den mest markerade etiketten ner till VPN-etiketten, men en policy måste konfigureras på PHP-routern för att detta ska ske. Och med uttrycklig nollkonfigurering på PE-egressen, skulle en sådan policy inte vara vettig.

Explicit null krävs för MPLS-växlade paket med bara en etikett, eftersom PHP annars skulle ta bort den enda etiketten, och därigenom bara ge PE-egressen möjlighet att göra QoS på markeringarna i IP-headern.

Som en sista kommentar angående DiffServ QoS, är alla policys baserade på administratörens konfigurerade PHB. Ingenting är magi. De tre modellerna som visas i det här inlägget är inte implementerade funktioner på någon plattform, vilket betyder att det inte är något du kan sätta på och få x modell som resultat. Du måste konfigurera manuellt vad som händer vid varje hopp. De tre modellerna finns där för att grovt referera till vilken policy du använder i ditt nätverk.

Ett alternativ till MPLS för allt fler verksamheter idag är SD-WAN. Läs vår SD-WAN Guide här eller se vårt SD-WAN seminarium!

 

Jacob Zartmann är en hängiven nätverksexpert med många års erfarenhet inom Ciscos nätverkslösningar, där han särskilt är intresserad av DNA Center med ett särskilt fokus på SD-Access. Jacob har en CCIE-certifiering inom Routing & Switching, som han utökar med en CCIE SP-certifiering. Privat slappnar han av med långa framfotslöpturer. Ovan inlägg är en godkänd översättning från Jacobs blogg.

 

 

Kontakta oss!
Svar inom 24h