Il QoS di ZeroShell di Renato Morano ®GPL3 1 Analisi del QoS di ZeroShell mediante il generatore di traffico Ostinato Premessa Il seguente documento presenta le mie considerazioni sul QoS utilizzato da ZeroShell. Le prove sono state effettuate con un generatore di traffico software ( www.ostinato.org ). Effettuerò più prove cambiando le condizioni iniziali di traffico entrante e le configurazioni di ZeroShell per verificare come il QoS influisce sul traffico uscente. Il documenti di riferimento sono: LARC How To e “HTB Linux queuing discipline manual - user guide ”. In genere non vi è nessun motivo per un flusso di dati di ricevere un trattamento differente rispetto ad un altro nell’attraversamento di una interfaccia di rete. L’unica condizione che ne può cambiare il comportamento è il flusso per unità di tempo. Le tipologie di traffico con una portata maggiore in ingresso verranno riportate in uscita in maniera proporzionale. Questo comportamento lo ritroviamo anche nel QoS di ZeroShell quando non vi è nessuna impostazione di “banda massima” e di “banda assegnata”, sino a quando la banda totale in ingresso non supera la Global assegnata. Superata la Global dal traffico in ingresso il QoS comincerà ad eseguire il drop dei pacchetti per mantenere il traffico sotto la soglia imposta dalla Global. Le verifiche sono effettuate sempre – a meno di eccezioni volute - in condizione di saturazione della portata massima. Il flusso in ingresso è sempre maggiore o uguale al valore di banda massima configurato tramite GUI di ZeroShell. Per avere un’idea della differenza tra il traffico generato da Ostinato e quello misurato dalle statistiche di ZeroShell, riportate in seguito, effettuiamo una prima serie di test. Definiamo su ZeroShell una banda massima, una classe di traffico oltre a quella di default. A questo punto generiamo con Ostinato un volume di traffico al di sotto della banda massima e vediamo come questo traffico imposto venga registrato dalle statistiche di ZeroShell.
Transcript
Il QoS di ZeroShell di Renato Morano ®GPL3 1
Analisi del QoS di ZeroShell mediante il generatore di trafficoOstinatoPremessaIl seguente documento presenta le mie considerazioni sul QoS utilizzato da ZeroShell. Le provesono state effettuate con un generatore di traffico software (www.ostinato.org). Effettuerò più provecambiando le condizioni iniziali di traffico entrante e le configurazioni di ZeroShell per verificarecome il QoS influisce sul traffico uscente. Il documenti di riferimento sono: LARC How To e“HTB Linux queuing discipline manual - user guide”.
In genere non vi è nessun motivo per un flusso di dati di ricevere un trattamento differente rispettoad un altro nell’attraversamento di una interfaccia di rete. L’unica condizione che ne può cambiareil comportamento è il flusso per unità di tempo. Le tipologie di traffico con una portata maggiore iningresso verranno riportate in uscita in maniera proporzionale. Questo comportamento loritroviamo anche nel QoS di ZeroShell quando non vi è nessuna impostazione di “banda massima”e di “banda assegnata”, sino a quando la banda totale in ingresso non supera la Globalassegnata. Superata la Global dal traffico in ingresso il QoS comincerà ad eseguire il drop deipacchetti per mantenere il traffico sotto la soglia imposta dalla Global.
Le verifiche sono effettuate sempre – a meno di eccezioni volute - in condizione di saturazionedella portata massima. Il flusso in ingresso è sempre maggiore o uguale al valore di banda massimaconfigurato tramite GUI di ZeroShell.
Per avere un’idea della differenza tra il traffico generato da Ostinato e quello misurato dallestatistiche di ZeroShell, riportate in seguito, effettuiamo una prima serie di test. Definiamo suZeroShell una banda massima, una classe di traffico oltre a quella di default. A questo puntogeneriamo con Ostinato un volume di traffico al di sotto della banda massima e vediamo comequesto traffico imposto venga registrato dalle statistiche di ZeroShell.
Classe Default Classe RDP Traffico complessivo (Kbps)
Traffico generato 1024 Kbps 1024 Kbps 2048
Traffico misurato 977376 bps 978872 bps 1956
Differenza 92
Potremmo ipotizzare questa differenza di 100 Kbps come un errore introdotto dalle varieapprossimazioni tra bit e Kbit tra i vari strumenti (tc, ZeroShell, Ostinato, Task Manager). Per avereun’idea di misura considereremo questa differenza come un errore da introdurre nelle misure.Considererò un errore nelle misure pari al 5% del valore del traffico in ingresso.
Il task manager di Windows dove è installato Ostinato riporta un flusso complessivo di 2,1 Mbps.
Le statistiche grafiche di ZeroShell, così come il risultato del comando tc, riportano un ratemisurato complessivo differente pari a di 1956 Kbps per il comando tc e 1962 Kbit per le statistichegrafiche.
La tabella precedente la possiamo riformulare indicando il numero di pacchetti per secondo, inquesto modo osserviamo che il numero di pacchetti complessivo è proprio pari alla somma deipacchetti per secondo della classe default con la classe RDP
Classe Default Classe RDP Traffico complessivo
Traffico generato 1024 Kbps 1024 Kbps 2048 Kbps
Traffico misurato 2036 pps 2036 pps 4072 pps
Come ulteriore esempio raddoppiamo il traffico generato entrante per entrambe le tipologie ditraffico
Illustration 1: QoS Statistics
Il QoS di ZeroShell di Renato Morano ®GPL3 4
Il traffico misurato dal Task Manager di Windows indica un valore di 4,2 Mbps,
Il QoS di ZeroShell di Renato Morano ®GPL3 5
Il comando tc restituisce come valore complessivo un rate di 2926 Kbps, direttamente connesso alvalore limite della banda globale, e le singole classi registrano un flusso identico pari a 1463 Kbit
Con questi primi esempi abbiamo la conferma che il traffico si suddivide in proporzione al flussoentrante e che il valore della banda massima viene rispettata.
Il QoS di ZeroShell di Renato Morano ®GPL3 6
Traffico con stessa priorità
Generiamo per ogni classe a pari priorità la stessa quantità di traffico circa - 768 Kbps - tale dasaturare la massima banda consentita (768*4=3072Kbps). Il traffico è generato tramite il softwareOstinato (www.ostinato.org) che è presente su di un server Windows.
Le statistiche riportano come il traffico si ripartisce.
Maggiori dettagli li ritroviamo attraverso il comando tc eseguito direttamente su una shell di “ZeroShell”. In evidenza i campi che consentono l’interpretazione dei risultati del QoS.
class htb : HTB - Hierarchy Token Bucketprio: In the round-robin process, classes with the lowest priority field are tried for packets first. rate : Maximum rate this class and all its children are guaranteedceil : Maximum rate at which a class can send, if its parent has bandwidth to spare. Defaults to the configured rate, which implies no borrowing.pps: pacchetti per secondodropped: numero di pacchetti eliminati
Il QoS di ZeroShell di Renato Morano ®GPL3 8
La suddivisione gerarchica delle classi è riportata nel grafico seguente.
La classe root rappresenta l’interfaccia virtuale su cui viene fissata la banda globale massima e al di sotto le varie classi di traffico che condividono la banda messa a disposizione dalla classe root.
Il traffico viene suddiviso in parti uguali. Il numero di pacchetti per secondo - pps - di ciascunaclasse è confrontabile ed inoltre, la loro somma, coincide con il valore conteggiato dalla “ rootclass”. Il comando tc “fotografa” il traffico nel momento in cui viene eseguito il comando stesso.
Traffico con la stessa priorità ma con valori di flusso differenti
Raddoppiamo il traffico generato da una classe e vediamo come questa cresce rispetto alle altre. Generiamo 1536 Kbps di traffico RDP mantenendo invariata la priorità High e il traffico generato sulle altre classi ( DEFAULT=LPR=SMB 768Kbps)
Vediamo che la classe RDP è solo leggermente in vantaggio rispetto alle altre. Dobbiamoconsiderare che il volume di traffico è tale da saturare il limite di banda imposto all’interfaccia
Il QoS di ZeroShell di Renato Morano ®GPL3 10
ETH00 dal QoS. Il dettaglio lo si scorge osservando il valore di pacchetti “ dropped” nella classe1:28 corrispondente al traffico RDP.
le classi che compongono il traffico concorrono alla pari al raggiungimento della banda massimama in maniera proporzionale al loro flusso nell’unità di tempo. Raggiunta la banda massima iltraffico in uscita sarà regolato dal QoS che scarterà i pacchetti in eccesso per mantenere il flussocostante e in proporzione scarterà i pacchetti che sono più numerosi.
Il QoS di ZeroShell di Renato Morano ®GPL3 12
Traffico con priorità differenti
Eseguiamo una prova di traffico mantenendo lo stesso traffico iniziale - 768Kbps - per ciascunaclasse ma con la priorità diverse. Per la DEFAULT e LPR imponiamo un valore Low e per RDP eSMB un valore High. Ci aspettiamo che le classi a più alta priorità si contendano la maggior partedel traffico in parti uguali. Questo perché avendo una priorità più alta vengono servite prima dalQoS rispetto alle classi a bassa priorità. Il risultato sarà visibile nel throughput delle classi.
I valori ottenuti riportano scostamenti molto piccoli e non apprezzabili da un traffico generato di768Kbps. Le due classi a bassa priorità registrano un rate che oscilla tra 715 Kbps e 720 Kbpsmentre quelle ad alta priorità presentano valori leggermente superiori – 722Kbps - ed un un casopari a quello a bassa priorità – 715 Kbps -.Per rendere evidente il comportamento del QoS aumentiamo per tutte le classi il valore del trafficoprodotto da Ostinato a 868 Kbps ed osserviamo i valori che si ottengono.
Questi valori possono essere compresi se prendiamo in considerazione il dettaglio fornito dalcomando tc. Dove le classi ad alta priorià (prio 0) non presentano nessun packetto “dropped” alcontrario delle classi a bassa priorità (prio 2).
La spiegazione che mi sono dato è la seguente:i pacchetti a bassa priorità entrando – o meglio uscendo - della coda per ultimi vengono“dropped” dal QoS per mantenere il valore della banda pari ai 3 Mbps.
hbt 1:10 p2
htb 1:30 p2
htb 1:26 p0
htb 1:28 p0
0 100 200 300 400 500 600 700 800 900 1000
rate in
rate out
Il QoS di ZeroShell di Renato Morano ®GPL3 15
Ora enfatizziamo il traffico ad alta priorità raddoppiandolo e riportando il flusso delle altre due classi a 768 Kbps:
- rate RDP è pari al rate SMB con un valore di 1536Kbps- rate DEFAULT è pari al rate LPR con un valore di 768 Kbps
Il traffico complessivo a monte generato è ora di 4.7Mbps
CLASSE Rate in priorità Descrizione pps dropped Rate out Rate out (Kbit)
htb 1:1 4.7 Mbps ROOT 6108 2982 Kbit
htb 1:10 768 Kbps 2 DEFAULT 44 914149 21776 21,27
htb 1:28 1536 Kbps 0 RDP 2966 25473 1473 Kbit
htb 1:30 768 Kbps 2 LPR 45 912091 21736 21,23
htb 1:26 1536 Kbps 0 SMB 3053 0 1465 Kbit
Il QoS di ZeroShell di Renato Morano ®GPL3 16
Osserviamo un valore elevato di pacchetti “dropped” per le classi a bassa priorità e con rate basso mentre un valore di pacchetti “dropped” inferiore per le classi ad alta priorità e con un rate tale da saturare la banda disponibile.
Nelle stesse condizioni di traffico, RDP=SMB 1536Kbps e DEFAULT=LPR a 768 Kbps , cambiamo in “Medium” la priorità della classe SMB e vediamo i risultati nelle statistiche.
In questo caso la classe RDP con priorità massima mantiene un rate - 1529 Kbps - pari a quellogenerato, poi segue la classe SMB con priorità Medium e con un rate paragonabile a quellogenerato. Infine a seguire le due classi a priorità più bassa che presentano un elevato valore dipacchetti “dropped” che vanno a saturare la banda resa disponibile dalle altre due classi.
L’interpretazione attraverso il numero di pacchetti per secondo (pps) mette in evidenza la relazionepriorità e flusso che attraversa la ETH00
CLASSE Rate in priorità Descrizione pps Rate
htb 1:1 4.7 Mbps ROOT 6035 2982 Kbit
htb 1:10 768 Kbps 2 DEFAUT 8 21320 bit
htb 1:28 1536 Kbps 0 RDP 3045 1529 Kbit
htb 1:30 768 Kbps 2 LPR 43 20664 bit
htb 1:26 1536Kbps 1 SMB 2939 1411 Kbit
Il QoS di ZeroShell di Renato Morano ®GPL3 22
Infine ridistribuiamo banda e priorità delle classi come segue:
- aumentiamo il traffico LPR a bassa priorità raddoppiandolo- riduciamo il flusso della classe SMB con priorità Medium- manteniamo invariato il flusso della classe RDP.
CLASSE Rate in input
priorità
Descrizione pps Rate in output Rate out in Kbit
htb 1:1 4.7 Mbps ROOT 6179 2981Kbit
htb 1:10 768 Kbps 2 DEFAUT 795 388448 379,34
htb 1:28 1536 Kbps 0 RDP 3053 1473 Kbit
htb 1:30 1536 Kbps 2 LPR 808 388048 378,95
htb 1:26 768 Kbps 1 SMB 1523 730928 713,8
Il traffico complessivo a monte generato da Ostinato è di 4.7 Mbps
Esaminiamo nel dettaglio: La presenza del QoS risulta evidente, a fronte di un traffico doppio della classe LPR –1536 Kbps- la differenza di priorità fa in modo che il flusso SMB uscente sia paragonabile a quello generato daOstinato.
CLASSE Rate in input priorità Descrizione pps Rate in output
Il flusso del traffico con priorità inferiore LPR risulta minore di quello generato da Ostinato (1536 Kbps) e presenta un numero elevato di pacchetti “dropped”
CLASSE Rate in input priorità Descrizione pps Rate in output
Uno dei valori aggiunti del QoS e anche quello più ricercato è quello di assicurare un valore dibanda garantita ad una determinata classe. Per come può essere configurato il QoS medianteZeroShell e a meno di una mia cattiva interpretazione, la parola garantita è da intendere in questamaniera:
fissando un valore di banda garantita per una classe questa viene ad essere imposta (Assigned) dalQoS quando si verificano le seguenti condizioni:
- Il flusso che attraversa la classe garantita deve essere maggiore o uguale a quella imposta comegarantita
- Le altre classi devono essere a loro volta attraversate da un flusso di traffico maggiore o uguale diquello assegnato e/o garantito
- Il valore complessivo del traffico deve essere maggiore o uguale a quello massimo assegnato allaclasse ROOT
Se queste condizioni vengono tutte rispettate ritroveremo la parola “ garantita” rispondente all’ideache questa ci suggerisce: il traffico per ciascuna classe sarà garantita e pari a quella assegnata.
Quando le condizioni precedenti non sono tutte rispettate e in particolare quando non tutte le classihanno una banda assegnata, la banda in eccesso viene suddivisa tra le altre classi che ne fannorichiesta.
La domanda è come questa banda in eccesso viene suddivisa.
Il QoS di ZeroShell di Renato Morano ®GPL3 28
Primo scenario:
Ad una classe assegniamo un valore di banda garantita che è minore di quella che è generataattraverso Ostinato. Generiamo inoltre traffico per un’altra classe che non ha valorizzato ilparametro garantito e il traffico generato, ma tale da saturare la banda massima. Nota: se non vienevalorizzato il parametro di banda garantita, attraverso la GUI di ZeroShell, il comando tc riporta ilvalore di 8bps per il rate “assegnato”. Eseguiamo un test aumentando di volta in volta il trafficogenerato sino ad un valore quattro volte superiore e ne prendiamo i dati. Concentriamo l’attenzionesolo su due classi di traffico.
In tabella riportiamo i valori che compongono il flussi. In particolare il rate in input così comeprodotto da Ostinato e i valori di rate in output come registrato dalle statistiche del comando tc
CLASSEx1
Rate in input priorità Descrizione Ceil Rate banda garantita
Nel primo caso il traffico entrante è minore di quello garantito e la banda in eccesso, 2700 - (500 – 250), viene messa a disposizione delle altre classi ma solo la DEFAULT ne può usufruire perché la RDP non ha un flusso entrante sufficiente.
Nel secondo caso il traffico è maggiore di quello garantito. La banda che abbiamo a disposizione è quella che si ottiene come differenza tra la massima (ceil) e quella assegnata alla classe RDP:2700 – 500 = 2200questa sarà suddivisa tra le classi in maniera proporzionale al traffico entrante. Mediante unaproporzione troviamo le percentuali di traffico che si possono suddividere le classi a patto cherichiedano la banda disponibile. Per la classe di default le percentuali sono
le percentuali per RDP saranno il complemento a 100.
Il QoS di ZeroShell di Renato Morano ®GPL3 36
% del flusso ditraffico a disposizione
della classe default
Banda adisposizionedella classe
default
Banda adisposizione della
classe rdp
Banda ingenerata per RDP
Bandaassegnata per RDP
Banda outmisurataper RDP
Banda outmisurata
perDEFAULT
92 2024 176 250 500 235 2443
80 1760 440 750 500 700 1967
75 1650 550 1024 500 1037 1647
Di seguito il grafico che mostra come al crescere del traffico RDP in ingresso il valore del rate di DEFAULT diminuisce.
rate in RDP rate out RDP rate out DEFAULT0
500
1000
1500
2000
2500
3000
Il QoS di ZeroShell di Renato Morano ®GPL3 37
La crescita del flusso di una classe (RDP) si ripercuote sull’altra (DEFAULT). Il valore totale del flusso in uscita è quello imposto dalla banda massima.
Assegniamo anche all’altra classe un valore di banda garantita e vediamo i cambiamenti indotti dal QoS.
Alla classe default assegniamo 1024Kbit nelle stesse condizioni di traffico generato precedenti. CLASSE Rate in input priorità Descrizione Ceil Rate banda
La banda che abbiamo a disposizione è quella che si ottiene come differenza tra la massima (ceil) e quella assegnata alle classi RDP e DEFAULT : 2700 – (1024+500) = 1176La banda di 1176 Kbit sarà suddivisa tra le classi in maniera proporzionale al traffico entrante. Mediante una proporzione troviamo le percentuali di traffico che si possono suddividere le classi a patto che richiedano questa banda disponibile. Per la default le percentuali sono
(3072+1024):3072=100:x1 , x1= 100*3072/4096=75%
% del flusso ditraffico a disposizione
della classe default
Banda adisposizionedella classe
default
Banda adisposizione della
classe rdp
Banda ingenerata per RDP
Bandaassegnata per RDP
Banda outmisurataper RDP
Banda outmisurata
perDEFAULT
75 882 294 1024 500 957 1704
Il grafico riporta come la banda viene ripartita fra le classi
1024 Kbps
500Kbps
500+294
1024+882
Il QoS di ZeroShell di Renato Morano ®GPL3 40
Aggiungiamo un’altra classe con banda garantita: la classe LPR con una banda garantita pari a 500 Kbps
CLASSE Rate in input priorità Descrizione Ceil Rate banda garantita
La banda in eccesso che abbiamo a disposizione è quella che si ottiene come differenza tra la massima (ceil) e quella assegnata alle classi RDP, DEFAULT, LPR : 2700 – (1024+500+500) = 652La banda di 652 Kbit sarà suddivisa tra le classi in maniera proporzionale al traffico entrante. Mediante una proporzione troviamo le percentuali di traffico che si possono suddividere le classi a patto che richiedano la banda disponibile. Per la classe di default la percentuali è
4096:2048=100:x1 , x1= 100*2048/4096 pari al 50% il restante 50% è suddiviso tra RDP e LPR
CLASSE % del flussodi traffico adisposizionedella classe
Aggiungiamo l’ultima classe con banda garantita: la classe SMB con una banda garantita pari a 500 Kbps
CLASSE Rate in input priorità Descrizione Ceil Rate banda garantita
Rate misurato
htb 1:1 5,1 Mbps ROOT 2700 2684Kbit
htb 1:10 2 Mbps 0 DEFAULT 2700 1024Kbit 1704Kbit
htb 1:28 1024 Kbps 0 RDP 2700 500 Kbps 957Kbit
htb 1:30 1024 Kbps 0 LPR 2700 500 Kbps
htb 1:26 1024 Kbps 0 SMB 2700 500 Kbps
La banda in eccesso che abbiamo a disposizione è quella che si ottiene come differenza tra la massima (ceil) e quella assegnata alle classi RDP, DEFAULT, LPR e SMB: 2700 – (1024+500+500+500)= 176La banda di 176 Kbit sarà suddivisa tra le classi in maniera proporzionale al traffico entrante. Mediante una proporzione troviamo le percentuali di traffico che si possono suddividere le classi a patto che richiedano la banda disponibile. Per la classe default la percentuale è
Il QoS di ZeroShell di Renato Morano ®GPL3 43
5120:2048=100:x1, x1= 100*2048/5120 apri al 40%, il restante 60% è suddiviso tra RDP, LPR e SMB in parti uguali perché hanno priorità uguale
CLASSE % del flussodi traffico adisposizionedella classe
Osserviamo che solo in questo caso il valore misurato del flusso delle varie classi di traffico è minore del valore assegnato.
Secondo scenario:
La classe di default è attraversata da un flusso di 1 Mbps e la classe RDP attraversata da una flusso di 3.2 Mb Assegniamo come banda garantita alla classe RDP tutta la banda
CLASSE Rate in input priorità Descrizione Ceil Rate banda garantita
Rate misurato
htb 1:1 4,2 Mbps ROOT 2700 2683 Kbit
htb 1:10 1 Mbps 0 DEFAULT 2700 null 1,05 Kbit
htb 1:28 3 Mbps 0 RDP 2700 3 Mbps 2683 Kbit
verifichiamo in due istanti diversi i valori delle statistiche
I risultati confermano come il QoS assegni tutta la banda alla classe RDP e consente alla default il solo traffico di “sopravvivenza” anche in presenza di un suo flusso consistente in ingresso. Rendiamo pari i due flussi in ingresso e vediamo che la proporzionalità ora non viene più ad essere rispettata nel traffico di uscita e proprio per merito del QoS.
CLASSE Rate in input priorità Descrizione Ceil Rate banda garantita
Anche in questo caso a fronte di un traffico in ingresso dei due flussi uguali solo il traffico “garantito” vien ritrovato in uscita.
I grafici riportano i valori delle due tabelle precedenti.
hbt 1:10 hbt 1:280
500
1000
1500
2000
2500
3000
3500
rate in
rate assegnato
rate out
Il QoS di ZeroShell di Renato Morano ®GPL3 52
hbt 1:10 hbt 1:280
500
1000
1500
2000
2500
3000
3500
rate in
rate assegnato
rate out
Il QoS di ZeroShell di Renato Morano ®GPL3 53
Banda garantita e priorità
Il cambio di priorità ad una classe ci dà la possibilità di assegnare attraverso il QoS la banda ineccesso seguendo questo criterio. Ci è utile nel momento in cui vogliamo privilegiare una classe chenon ha abbastanza traffico in ingresso e che quindi beneficerebbe della banda in eccesso soloproporzionalmente al suo traffico in ingresso.
La prova la facciamo nelle condizioni riportate in tabella
Ripetiamo le prove di traffico e riassumiamo i risultati nelle tabelle seguenti.
CLASSE Rate in input priorità Descrizione Ceil Rate banda garantita
Il cambiamento di priorità implica un aumento di più 60 Kbit di traffico RDP grazie all’eccesso di banda ripartito. In percentuale l’aumento di banda a seguito della priorità maggiore è del 16,4%
htb 1:28 p2 htb 1:28 p00
100
200
300
400
500
600
rate in
rate assigned
rate out
Il QoS di ZeroShell di Renato Morano ®GPL3 59
Banda garantita e banda massima
La possibilità di assegnare una banda massima all’interno del QoS è utile nelle condizioni in cuivogliamo che una determinata classe non abbia la possibilità di “divorare” tutta la banda disponibilenon assegnata ad altre classi. In questo modo la crescita di una classe è limitata nell’uso della bandanon assegnata o non utilizzata dalle altre classi .
Un caso particolare
Abbiamo la necessità di “tutelare” il traffico di un’applicazione RDP che ha un traffico incapsulatoin un tunnel vpn. Assumiamo il traffico suddiviso nelle classi default ed rdp. Inoltre la quantità dibanda richiesta dall’applicazione in rdp è molto minore di quella richiesta dalla classe default.
Le classi si contendono la banda disponibile sino a saturare la banda a disposizione. Il QoS puòintervenire in questa situazione attraverso il cambio della priorità tra le due classi. Per assicurare altraffico vpn una “riserva” di banda tale da assicurare un canale privilegiato dobbiamo imporre allaclasse di default un limite massimo. In questo modo anche in assenza di traffico vpn la banda usatadalla default non potrà superare il limite imposto. Potremmo stimare questo limite da asseganre inpercentuale alla banda massima. Per esempio fissando al 80% della banda globale massima il valoredella massima banda consentita alla classe di default. In questo modo abbiamo a disposizione per laclasse rdp un valore di banda disponibile che non potrà mai essere minore di quella lasciata liberadalla classe di default. Le condizioni migliorano quanto più si riesce a categorizzare il traffico conle classi. Il vantaggio di avere più classi di traffico è la selettività: il poter decidere su qualetipologia di traffico effettuare il taglio di banda.
Il questo scenario come gestire la banda garantita ?
internet dc
client
default vpn
Il QoS di ZeroShell di Renato Morano ®GPL3 60
Assegnare una banda garantita alla classe vpn non ha un grande vantaggio se non nella previsionedi una saturazione della banda in cui il traffico viene imposto dal QoS. Poichè il traffico rdp è digran lunga inferiore al resto del traffico di default e l’assegnare una grande banda al vpn non haeffetto. Di questa banda assegnata la classe VPN ne richiederà solo una parte e la non utilizzataverrà comunque ripartita anche alla default. La configurazione ottimale è quella che prevede unlimite nella banda massima della default e assegnare alla VPN una banda pari alla massimapossibile, in modo che in caso di saturazione abbiamo un valore imposto dal QoS. Più il trafficosarà “categorizzato” attraverso le classi di traffico, più sarà possibile effettuare un taglio selettivodella banda a vantaggio della categoria di traffico da privilegiare.
Il QoS di ZeroShell di Renato Morano ®GPL3 61
QoS e traffico di uploadTutti gli esempi precedenti si riferiscono ad una configurazione in cui il traffico su cui è abilitato ilQoS è l’interfaccia EH00 di download. La configurazione può essere applicata anche ad un trafficodi upload attraverso una configurazione di ZeroShell in bridge tra ETH00 ed ETH01,configurazione che rimando alla documentazione di Fulvio Ricciardi. Valgono le stesseconsiderazioni fatte per il traffico di download.
Il QoS di ZeroShell di Renato Morano ®GPL3 62
Table of ContentsAnalisi del QoS di ZeroShell mediante il generatore di traffico Ostinato............................................1
Premessa.......................................................................................................................................... 1Traffico con stessa priorità...............................................................................................................6Traffico con la stessa priorità ma con valori di flusso differenti..................................................... 9Traffico con priorità differenti....................................................................................................... 12Banda garantita.............................................................................................................................. 27Banda garantita e priorità...............................................................................................................53Banda garantita e banda massima..................................................................................................59QoS e traffico di upload.................................................................................................................61
