QoS regole di configurazione classification marking and scheduling con cisco e juniper example config
26.11 2019 | by massimilianoLe 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.
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
!
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
Esempio pratico di configurazione Juniper:
Nei router Juniper i servizi di QoS seguono il seguente schema:
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:
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;
}