QoS regole di configurazione classification marking and scheduling con cisco e juniper example config

Home » Blog » Application » QoS » QoS teoria » QoS regole di configurazione classification marking and scheduling con cisco e juniper example config

QoS regole di configurazione classification marking and scheduling con cisco e juniper example config

26.11 2019 | by massimiliano

Le regole di configurazione seguono steps quali la classificazione del traffico, la marcatura o colorazione ed infine lo scheduling applicato  […]


https://www.ingegnerianetworking.com/wp-content/uploads/2019/11/classifier-qos-fbf.png

Le regole di configurazione seguono steps quali la classificazione del traffico, la marcatura o colorazione ed infine lo scheduling applicato 

 Il traffico può essere classificato per mezzo di un classificatore che si basa principalmente sul contenuto dell’intestazione IP oppure TCP/UDP del pacchetto; vi sono due tipi di classificatori di cui uno conosciuto come BA (Behaviour Aggregate) che rileva il contenuto del solo campo ToS e l’altro come MF (Multi-Field) dove va a verificare diversi campi nell’header del pacchetto.

La classificazione si applica generalmente presso i nodi edge di un dominio QoS.

 

classifier qos

 

 

Il modello Integrated Services (Int-Serv) assegna a ciascun micro-flusso una determinata banda trasmissiva su base delle classe di servizio, il profilo del traffico ed una conseguente prenotazione (reservation resource) di banda grazie al protocollo do segnalazione RSVP.

RSVP è responsabile di riservare risorse quali bandwidth, buffer, CPU cycles (cioè il tempo per un nodo di rete di processare un pacchetto) e richiedere ai nodi di rete di mantenere le informazioni di ogni path monodirezionale percorso dal flusso di traffico (questo però non permette una grande scalabilità di reti di grandi dimensioni)

Oltre al protocollo di segnalazione si prevedono operazioni quali la classificazione dei pacchetti a cui garantire QoS, accettazione di questi con la verifica se tutti i nodi del dominio di rete hanno banda sufficiente per il flusso, il policing per identificare il traffico non conforme al profilo concordato in fase di segnalazione, lo scheduling per assegnare la banda richiesta attraverso opportuni algoritmi (LLQ, WFQ) ed infine lo shaping che è una funzionalità atta a sagomare il traffico in modo conforme per renderlo compatibile in un determinato profilo.

 

Il modello Differentiated Services (Diff-Serv) migliora in termini di scalabilità su reti di grandi dimensioni ed invece di assegnare risorse per ogni flusso di traffico, colloca le risorse su base delle classi di traffico assegnate a determinati flussi (in altre parole i flussi di traffico che appartengono tutti alla stessa classe vengono trattati con le stesse regole di QoS)

La classificazione è codificata all’interno del marking (colorazione) attraverso diverse metodologie legate al layer di comunicazione:

 

  • – Layer 3 (IPv4 o IPv6 ToS):
  • DSCP (6 bit)
  • IP-Precedence (3 bit)

 

– Layer 2:

Frame Relay DE (1 bit)

802.1Q CoS (3 bit)

MPLS EXP (3 bit)

 

NOTA: da evidenziare che il modello Diff-Serv MPLS introduce due tipi di LSP (Label Switch Path) che si differenziano per le loro funzionalità in termini di QoS:

 

– E-LSP (EXP inferred-class): supporta la trasmissione simultanea di più classi di traffico all’interno di un tunnel (path) MPLS ed al suo interno possiamo avere traffici classificati come EF + AF1 + AF2 + …….

 

– L-LSP (Label inferred-class): trasporta una sola classe di traffico all’interno del tunnel (path) MPLS classificato come EF, AFxy, ……..

 

Si riporta solo a titolo esemplificativo alcuni step di configurazione sia con tecnologia Cisco che Juniper

 

QoS con Cisco (MQC):

 

La classificazione del traffico è gestita via class-map alle quali si possono usare diverse condizioni (match); il traffico (pacchetti) che non rientrano nei criteri di nessuna classe sono implicitamente assegnati alla classe di default che è referenziata come class-default

 

class-map < name-class >

match access-group { value | name | ipv4 | ipv6 }  # numero o nome di una access-list

match precedence < list >  # lista di valori ip-precedence

match dscp < list >  # lista di valori DSCP

match mpls experimental topmost < list >  # lista di valori EXP MPLS

match packet lenght { min | max }  # indica un IP packet size (incluso l’header IP)

match protocol < protocol >  # lista di protocolli (ad esempio ipv4, ipv6, TCP, RTP, etc…)

match vlan < vlan range >  # lista di inner vlan-id per pacchetti con doppio vlan encapsulation

match cos < list >  # lista di ethernet 802.1q user priority value

!

 

Il marking (colorazione) del traffico si basa su valori di IP-Precedence, DSCP oppure EXP configurato all’interno di una policy-map che referenzia la class-map, il comando set supporta un’ampia gamma di criteri sia L2 che L3

 

policy-map < name-policy >  # identifica il nome di una policy-map che colora il traffico sulla base delle classi 

class < name-class >  # referenzia e classifica una specifica classe di traffico

set precedence < value >  # assegna un valore di IP-Preced

set precedence tunnel < value >   # assegna un valore di IP-Preced da essere usato attraverso un IP tunnel header

set dscp < value >  # assegna un valore DSCP

set dscp tunnel < value >  # assegna un valore DSCP da essere usato attraverso un IP tunnel header

set mpls experimental imposition < value >  # assegna un valore EXP da essere usato attraverso operazioni di push

set mpls experimental topmost < value >  # assegna un valore di EXP nell’header MPLS on top dello stack label

set cos < value >  # assegna un valore di ethernet 802.1q user priority

set atm-clp  # assegna il bit ATM CLP

set fr-de      # assegna i bir frame-relay DE

!

 

L’applicazione della policy-map è configurata su base interfaccia di ingresso (oppure di uscita)

 

interface x/y

service-policy imput | output < name-policy-map >

!

 

Esempio pratico di configurazione Cisco:

 

Classificazione del traffico per mezzi di access-list, referenziate successivamente da class-map:

 

access-list 110 remark VOCE

access-list 110 permit ip 10.10.10.0 0.0.0.255 172.16.1.0 0.0.0.255

access-list 110 permit ip 10.10.20 0 0.0.0.255 172.16.1.0 0.0.0.255

access-list 110 permit ip 10.10.30.0 0.0.0.255 172.16.1.0 0.0.0.255

!

access-list 120 remark VIDEO

access-list 120 permit ip 10.1.1.0 0.0.0.255 any

access-list 120 permit ip 10.2.2.0 0.0.0.255 any

access-list 120 permit ip 10.3.3.0 0.0.0.255 any

!

access-list 130 remark DATI

access-list 130 permit ip 10.10.10.0 0.0.0.255 172.16.1.0 0.0.0.255

access-list 130 permit ip 10.10.20.0 0.0.0.255 172.16.1.0 0.0.0.255

access-list 130 permit ip 10.10.30.0 0.0.0.255 172.16.1.0 0.0.0.255

access-list 130 permit ip 10.10.10.0 0.0.0.255 any

access-list 130 permit ip 10.10.20.0 0.0.0.255 any

access-list 130 permit ip 10.10.30.0 0.0.0.255 any

!

class-map VOCE

match access-group 110

class-map VIDEO

match access-group 120

class-map DATI

match access-group 130

 

 

Colorazione del traffico: la marcatura dei pacchetti avviene in questo esempio su base IP-Precedence nel campo ToS dell’header IP configurata su nodi di rete edge e definita da valori numerici dal più alto con significato a maggiore priorità e zero con significato di best-effort

 

policy-map QoS

class VOCE

set ip precedence 4

!

class VIDEO

set ip precedence 2

!

class DATI

set ip precedence 0

!

 

Il passo conclusivo è quello di applicare la policy-map sulla interfaccia di ingresso raccolta del traffico:

 

interface x/y

service-policy input QoS

!

 

qos config1

 

 

Bisogna prevedere uniformità QoS end-to-end garantita per tutto il path percorso dal flusso di traffico compreso il cloud MPLS; pertanto il router PE appartenente alla rete backbone MPLS deve essere configurato per garantire lo stessa qualità di servizio applicata in ingresso al nodo CE ed assegnare la corretta banda attraverso algoritmi di scheduling:

 

PE router scheduling:

 

class-map match-any VOCE

match ip precedence 4 6

match mpls experimental 4 6

!

class-map match-any VIDEO

match ip precedence 2

match mpls experimental 2

!

class-map match-any DATI

match ip precedence 0

match mpls experimental 0

!

policy-map QoS-End-to-End

class VOCE

policy cir percent 35

priority

class VIDEO

bandwidth percent 10

class DATI

bandwidth percent 50

 

 

NOTA:

E’ importante ricordare il significato del math-any e match-all presenti nelle class-map:

match-any si comporta come un operatore booleano OR

match-all si comporta come un operatore booleano AND

 

NOTA:

police command ha un grande numero di opzioni e flessibilità: include sempre un profilo di traffico su base rate e burst ed un gruppo di azioni che possono essere implicitamente o esplicitamente specificate.

 

CIR = la quantità/percentuale/velocità (RATE) di traffico trasmesso attraverso un link o virtual circuit (VC) misurato in bps (Committed Information Rate su base di un contratto SLA);

 

  • Bc = numero di bit che può essere trasmesso (su base CIR) per ogni intervallo di tempo Tc; indica di quanto il CIR può essere superato o su base bit-rate o su base tempo;
  • Be = numero di bit in eccesso trasmessi (cioè oltre il numero di bit permessi del Bc) per un determinato periodo di inattività (Burst excess); indica di quanto il PIR può essere superato o su base bit-rate o su base di tempo;
  • Tc = è un intervallo di tempo settato per “modellare” la quantità di traffico richiesto su base SLA da configurare (Committed Rate Measurement Interval);
  • PIR = Peak Information Rate ed è specificato come bit-rate oppure come percentuale di un link-rate

police rate percent value [burst value ms [peak-burst value ms]]

police cir e policy rate sono sintassi equivalenti;

rate e burst sono equivalenti a cir e bc.

 

NOTA:

La classe VOCE implementa una coda (queue) di tipo LLQ low-latency queue e raccoglie il traffico con vincoli più stringenti e di maggiore importanza; tramite il comando priority a tale classe viene riservata una coda assolutamente prioritaria rispetto alle altre, ossia i pacchetti che transitano su tale coda hanno la precedenza rispetto alle altre classi.

Il valore numerico che segue il comando priority definisce la banda massima da assegnare alla coda nel caso di presenza di congestione e si rende necessario per evitare che il traffico di tale coda possa monopolizzare l’intera banda dell’interfaccia.

P.S. si ricorda che la banda assegnata ad una interfaccia non è fruibile al 100% ma circa al 75% per consentire il trasporto di traffico di controllo (routing, segnalazione, etc..) ugualmente importante per il corretto funzionamento del nodo di rete

 

Per le classi VIDEO e DATI è stato assegnata una classe di tipo CB-WFQ (Class Based Weighted Fair Queue), cioè a ciascuna classe di traffico viene riservata una coda a cui è possibile associare particolari caratteristiche, come ad esempio la banda oppure il numero di pacchetti; con il comando bandwidth, seguito dal valore di banda in Kb/sec, si definisce la banda garantita alle differenti classi e quindi associa un peso ad esse dove in caso di congestione le classi vengono servite in proporzione ai pesi di ciascuna, ossia in base alla proporzione alla banda configurata (ad una banda maggiore corrisponde un peso maggiore)

 

In caso di vincoli di banda su accordi di tipo SLA occorre fare ricorso alla funzionalità di shaping

Con il Traffic Shaping si intende il controllo del flusso di traffico uscente da una interfaccia in modo tale da garantire che sia compatibile con quello che l’interfaccia del router remoto si aspetta di ricevere.

Qualora questa compatibilità non sia rispettata si rende necessario sagomarlo in modo opportuno; da notare che l’operazione di shaping non comporta la perdita di traffico, ma qualora il traffico ecceda il limite consentito, tale traffico viene bufferizzato in modo da essere trasmesso in momenti di basso carico.

La configurazione di shaping prevede di definire una nuova policy-map la quale interpreta tutte le tipologie di traffico cui vengono applicate le policy di cui sopra (qui indicate dalla policy-map QoS-End-to-End) come una unica classe (class-default) ed a cui si applichi l’operazione di shaping per rientrare nei vincoli di banda previsti.

Il comando shape max-buffer 4096 innalza il numero massimo di buffer dal valore di default per evitare la pardita di pacchetti (esaurito il valore di buffer i pacchetti eccedenti verrebbero comunque scartati)

 

PE router shaping:

 

policy-map QoS-Sagoma

class class-default

shape average 40000000

shape max-buffer 4096

service-policy QoS-End-to-End

 

Il passo conclusivo è applicare la policy-map sulla interfaccia di uscita

 

interface gi0/0

service-policy output QoS-Sagoma

 

qos serpolicy

 

 

 

 

Esempio pratico di configurazione Juniper:

 

Nei router Juniper i servizi di QoS seguono il seguente schema:

 

qos meccanismo junos

 

La classificazione aggrega differenti tipi di traffico identificati all’interno di forwarding-class utilizzando valori quali IP-Precedence, DSCP, 802.1p, MPLS-EXP; dopo che una classe è assegnata ad una determinata coda esiste una corrispondenza uno a uno tra la coda e la classe.

 

Lo scheduler definisce parametri quali transmission-rate, buffer-size e priority assegnate infine alle interfacce; si riporta una schema generale:

 

qos general junos

 

 

Le code sono motivo di packet-loss e delay, pertanto un meccanismo di priorità delle code (policy queue) definisce come rilasciare o servire prima il traffico con più alta priorità (high) rispetto a quello definito a bassa priorità (low) ed il restante traffico trattato come best-effort.

Lo tecniche di scheduling dei pacchetti sono:

  • – FIFO (First In First Out): il primo pacchetto che entra nel router è quello rilasciato (forward) prima;
  • – PS (Priority Scheduling): le code sono assegnate a differenti valori di priorità e le code definite high sono servite prima di quelle definite low;
  • – WRR (Weighted Round Robin): alle code sono assegnate valori su base bandwidth percui se ad una coda viene assegnato un 40% della banda disponibile ed ad un’altra coda un 60% di banda disponibile, allora la seconda coda viene servita in un rapporto di 6/4 volte maggiore rispetto alla prima coda.

 

 

Il buffer management (memorizzazione) ha differenti modi di gestione:

 

  • – Push Out: i pacchetti associati alla priorità high possono eliminare quello a priorità low;
  • – Threshold: verranno scartati i pacchetti a bassa priorità (low) se il contenuto del buffer avràò raggiunto e superato una certa soglia

 

Esempio pratico di configurazione Juniper:

 

classifier {

dscp QoS-classifier {

forwarding-class expedited-forwarding {

loss-priority low code-points 101110;

}

forwarding-class assured-forwarding

loss-priority low code-points 001100;

}

forwarding-class best-effort {

loss-priority high code-points 000000;

}

forwarding-class network-control {

loss-priority low code-points 110000;

}

forwarding-classes {

queue 0 best-effort;

queue 1 expedited-forwarding;

queue 2 assured-forwarding;

queue 3 network-control;

}

scheduler-maps {

QoS-scheduler {

forwarding-class assured-forwarding scheduler VIDEO;

forwarding-class expedited-forwarding scheduler VOICE;

forwarding-class best-effort scheduler Other-Traffic;

forwarding-class network-control scheduler NETWORK;

}

schedulers {

VIDEO {

transmit-rate percent 20;

buffer-size percent 40;

priority high;

}

VOICE {

transmit-rate percent 5;

buffer-size percent 10;

priority high;

}

NETWORK {

transmit-rate percent 5;

buffer-size percent 5;

priority high;

}

Other-Traffic {

transmit-rate remainder;

buffer-size remainder;

priority low;

}

interface {

e3-0/0/1 {

scheduler-map QoS-scheduler;

unit 0 {

classifiers {

dscp QoS-classifier;

}

ge-1/4/0 {

scheduler-map QoS-scheduler;

unit 0;

classifiers {

dscp QoS-classifier;

}

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Torna in alto