Capitolo 6 Prove Sperimentali

(1)

Capitolo 6

Prove Sperimentali

(2)

Manager può utilizzare per controllare i nodi della rete. In questo capitolo, forniremo quindi una spiegazione più dettagliata del software utilizzato ed andremo a descrivere il trial su cui faremo alcune prove di traffico. Infine nell’ultima parte di questo capitolo presenteremo alcuni grafici rappresentati l’attività di monitoring della rete DiffServ.

6.1 IBM Tivoli Netview NMC

Netview NMC (Netview Management Console) [17] è un programma molto completo per il network management di una rete, permette sia un’analisi in tempo reale dello stato della rete, sia la possibilità di generare dei report periodici. Questo software ha una console di comando con un’interfaccia grafica che consente di controllare l’andamento e lo stato, sia di una LAN che di una rete geografica WAN, grazie ad una mappa che rappresenta fedelmente tutti i nodi della rete e i collegamenti tra questi. Agendo direttamente su un nodo sulla mappa si possono avere informazioni sulla sua configurazione e sullo stato delle sue interfacce ed inoltre è possibile avere informazioni sulle MIB tramite un browser MIB integrato nella console di comando, il quale può essere utilizzato per inviare query SNMP. Una volta installato, il programma lancia automaticamente una discovery per costruirsi la topologia della rete su cui deve lavorare. Questa operazione si appoggia su un File di testo (detto file seed) nel quale il network manager ha elencato gli indirizzi IP degli apparati di rete che possono fornire informazioni importanti per la costruzione della topologia di rete, in sostanza in questo file ci sono gli indirizzi dei router e degli switch.

NMC comincia dunque ad interrogare tramite query SNMP le macchine identificate dall’IP address che possiamo trovare nel file di testo.

(3)

Tramite queste query riesce ad ottenere le tabelle di routing e le tabelle ARP degli switch, scoprendo l’esistenza di nuove reti, quindi per ogni nuova rete, tramite messaggi di ICMP request (PING), verifica la presenza di nodi. A questo punto, per ogni nodo scoperto sulle nuove reti verifica la presenza attiva dell’agent SNMP e nell’eventualità che ci sia, lo interroga per avere ulteriori informazioni sul nodo stesso e sulle altre reti a lui collegate.

(4)

Infatti, sono evidenziati in verde gli host che non hanno inviato nessun tipo di allarme, di giallo quelli che hanno mandato qualche allarme e di rosso i nodi che sono inattivi. Inoltre è comunque possibile visualizzare tutti gli allarmi generati e filtrarli in base all’indirizzo IP di un host oppure in base alla gravità dell’allarme.

Selezionando un allarme è possibile associargli un’azione, come spedire una E-mail, un messaggio di pop-up, ecc….

Come ogni applicazione, NMC è dotato di una serie di report standard attraverso i quali è possibile avere una rappresentazione tabulare degli eventi “under investigation”. Tali collezioni sono conservate all’interno di un database proprietario che, come tale, non può essere acceduto se non da NMC stesso. E’ anche vero però che NMC ha un modulo di esportazione dei propri dati in un datawarehouse collocato in un server SQL (MS SQL Server o Oracle) [18].

Netview contiene inoltre un Tool Graph, che permette di osservare e graficare il traffico real time, ed ogni tipo di dato SNMP (Fig 6.2). Questo tool ci permette, per esempio, di poter rappresentare sotto forma di grafico, le informazioni relative al traffico delle varie classi di servizio una volta lanciato il sub-agent implementato, in maniera tale da poter osservare con estrema semplicità l’evolversi del comportamento della rete DS. In particolare possiamo generare grafici, che vadano a rappresentare il numero di pacchetti trasmessi, con un tempo di campionamento (interrogazione SNMP) che può essere scelto dal manager della rete. Inoltre è possibile memorizzare i dati campionati, in maniera tale da poter costruire gli indici prestazionali descritti nel capitolo precedente.

(5)

L’implementazione di strumenti per l’analisi di rete DiffServ/MPLS, viene utilizzata su di un trial sperimentale che utilizza contemporaneamente la tecnologia MPLS [19](Multiple Label Switching Protocol) e quella DiffServ (Fig 6.3).

La soluzione utilizzata nel trial è rappresentata dall’architettura MAID [20] (Multiple Access Inter-Domain), che punta a mettere a disposizione dei Network Operators i meccanismi di configurazione di QoS-aware LSPs.

L’architettura di rete MAID si basa sullo sviluppo di due principali elementi di rete: • Il Multiple Access Label Edge Router DiffServ (MA-LER-DS)

• Il Bandwidth Broker (BB)

Un router MA-LER-DS, fonde insieme le funzionalità di MPLS Label Edge Router (LER) e quelle di un DiffServ Border Router (BR).

Questo elemento di rete infatti, implementa tutte le funzionalità di un BR, quali il metering, la classificazione dei pacchetti, il marking, lo shaping, ed inoltre, tutte le funzionalità di un LER.

Il Bandwidth Broker è l’apparato di rete responsabile della gestione della configurazione di ogni LSP che viene instaurato nel dominio MPLS.

Il Trial che andiamo ad analizzare (Fig 6.3), implementa un’architettura di rete MAID, composta da router prototipali basati su piattaforme IA32(PC) Linux OS, configurate con la versione del Kernel Linux 2.4.20 che include i moduli per la gestione delle risorse MPLS, e come detto più volte il modulo del Traffico Control.

(6)

Figura 6.3: Trial sperimentale DiffServ/MPLS

• MPLS-DS-BB (i.e Hertz), gestisce dinamicamente le risorse di rete sotto il suo controllo.

• MA/LER-DS (i.e Postel e Fourier), si comporta a tutti gli effetti come un router DiffServ over MPLS.

• LSD-DS (i.e Etabeta), si comporta come un core router DS, classificando i pacchetti sulla base del DSCP.

In particolare è opportuno segnalare, che il MIB Module che abbiamo costruito, permette di poter interrogare i vari router DS tramite query SNMP, ottenendo diverse informazioni relative alle classi di servizio.

Come possiamo vedere dalla figura 6.3, abbiamo installato sull’host avente indirizzo IP 192.168.50.5, il software per l’analisi di rete Neview NMC.

Tramite il MIB browser di Netview, possiamo interrogare i router Linux attivi nella rete, ottenendo informazioni relative al ramo DiffServ MIB. Per quanto riguarda i due PC (IP

(7)

192.168.40.4, 192.168.50.6), sono utilizzati in questa configurazione, per generare artificialmente del traffico all’interno della rete.

Il funzionamento base dell’architettura MPLS consiste nel classificare e marcare i pacchetti IP in ingresso al dominio con una label di lunghezza fissa, in modo che i router interni possano adottare opportune decisioni di forwarding a seguito di semplici operazioni su tale label.

Il percorso seguito dai pacchetti all’interno di un dominio MPLS è perciò contraddistinto da una sequenza di label, ognuna delle quali è significativa per il router ricevente.

Tale sequenza di etichette, che va da un router di ingresso ad un router di uscita del dominio, identifica un Label Switched Path (LSP), ovvero un percorso unidirezionale seguito dai pacchetti cui verrà riservato un certo trattamento.

In particolare, l’header MPLS, presenta un campo EXP di 3 bit, previsto per usi sperimentali, che nel nostro Trial viene utilizzato per indicare il PHB. Nei casi in cui si voglia utilizzare il DiffServ su reti MPLS è prevista una nuova tipologia di LSP detti Label-only-inferred-PSC, o L-LSP. Tali LSP trasportano un singolo Ordered Aggregate e la relativa PHB Scheduling Class viene implicitamente codificata nella label, mentre la drop precedence è indicata nel campo EXP dell’header (Fig 6.4). Nel caso di classe EF o BE, la sola label è già sufficiente ad individuare il corrispondente PHB.

(8)

Figura 6.4: Mappatura dei BA in un L-LSP

Un L-LSP viene settato nel seguente modo: l’ingress DS-LER invia un messaggio di richiesta della label, il “Label Request” (detto anche “Path Message” se il protocollo utilizzato è RSVP-TE), verso l’egress router, il quale restituisce un messaggio di “Label Mapping” (o “Resv message” per RSVP) instaurando il meccanismo di allocazione. In DS-MPLS è prevista la possibilità di specificare il percorso e definire quindi i nodi che formeranno il Label Switched Path.

I router prototipali, che andremo ad interrogare tramite SNMP, sono stati configurati in maniera tale da poter testare tutte le possibilità di una rete MAID, inoltre sono forniti di un agent SNMP (net-snmp versione 5.0.9), per permettere di utilizzare il MIB module descritto nei capitoli 3 e 4 di questa tesi.

(9)

6.3 Test prestazionali di traffico

6.3.1 Generazione di traffico CBR

Tramite il tools grafico di Netview, è possibile costruire dei grafici che rappresentano il risultato di interrogazioni SNMP effettuate ad istanti prefissati di campionamento. Quindi, una volta lanciato l’agent SNMP, che definisce le MIB diffServ, è possibile monitorare i router Linux, ed ottenere vari grafici di traffico relativi ad ogni classe di servizio configurata.

Inoltre, è possibile costruire tutti gli indici prestazionali di una rete DiffServ descritti nel capitolo precedente, in maniera tale da ricavare moltissime informazioni sullo stato della rete, come per esempio:

• La lunghezza media delle code degli scheduler.

• L’utilizzazione di ogni classe di servizio creata tramite un L-LSP. • La percentuale di pacchetti scartati dallo scheduler.

Per poter ottenere tali risultati è possibile, tramite l’utilizzo di un’interfaccia grafica, impostare la creazione di un L-LSP (Fig 6.5), che definisca una sorta di “Tunnel virtuale” tra il router Postel ed il router Fourier, che passi necessariamente dal router ETA-BETA.

(10)

Figura 6.5: Configurazione di un L-LSP

Come possiamo osservare dalla figura 6.5 quindi, viene instaurato un L-LSP che assegna alla classe EF il rate di 1Mbit/s, inoltre ha come indirizzo di destinazione quello del router Fourier e come indirizzo IP sorgente quello del router Postel.

Utilizzando il seguente comando:

tunnel –m –p udp –d 192.168.40.4 –l 2025

facciamo in modo che il traffico generato dall’indirizzo IP 192.168.40.4, venga mappato

con L-LSP creato ed in particolare sia quindi classificato come traffico Expedited Forwarding con rate assegnato 1Mbit/s.

(11)

Figura 6.6: creazione di un L-LSP

Per poter generare del traffico artificialmente abbiamo utilizzato un pacchetto software ad elevate prestazione, chiamato Brute, che ha il compito di generare traffico UDP di varie tipologie.

In questo caso è stato generato traffico a bit rate costante avente le seguenti proprietà, indicate nel file di configurazione di brute:

(12)

Con questa configurazione, andiamo ad analizzare il comportamento del router Postel, in seguito alla generazione del traffico costant bit rate e dopo aver inizializzato il sub-agent SNMP relativo alle MIB DiffServ.

• Test 1.A

Una volta instaurato L-LSP su EF a 1Mbit/sec, generiamo come detto il traffico CBR con rate 1,5Mbit/sec dall’host 192.168.50.5 verso l’host 192.168.40.4. Avendo configurato la coda in uscita dall’interfaccia del router Postel, con dimensione massima pari a 256 pacchetti, riportiamo dei grafici che ci permettano di determinare la lunghezza media della coda durante tutta la trasmissione del traffico artificiale. Tale grafico (Fig 6.8) è stato ottenuto in seguito al risultato di interrogazioni SNMP effettuate ad intervalli di tempo pari a 1sec, alla MIB diffSerCosEFif4Qlen e servendoci del Tool Graph di Netview NMC.

(13)

(14)

Il valor medio della coda è valutato intorno ai 172 pacchetti, ed è un valore attendibile (anche se affetto inevitabilmente da errore di campionamento) visto che la lunghezza massima del buffer è settata a 200 pacchetti. Inoltre, il traffico generato in ingresso al router Postel, è maggiore rispetto a quello che il router riesce a smaltire ogni secondo, per cui il buffer della coda resta praticamente sempre pieno.

Interrogando con lo stesso tempo di campionamento, la MIB diffSerCosEFif3TxedPkts

possiamo osservare che la funzione ottenuta è una retta che rappresenta il numero di pacchetti trasmessi, in uscita dal router Postel, in seguito alla generazione del traffico (Fig 6.9).

Figura 6.9: Traffico EF in uscita dal router Postel

La pendenza di questa retta, quindi, indica il numero medio di pacchetti trasmessi per secondo e cioè il rate, quindi 512pps oppure espresso in byte, 1Mbit.

Un altro grafico che possiamo ottenere tramite interrogazioni SNMP, è il numero di pacchetti scartati (Fig 6.10) durante la trasmissione di traffico a bit rate costante. Tali pacchetti saranno scartati qualora il buffer della coda, presente sull’interfaccia di uscita, sia completamente riempito.

(15)

Figura 6.10: pacchetti scartati per la classe EF in uscita dall’interfaccia 3 del router Postel durante il Test 1.A

Generando traffico CBR, ed avendo una disciplina di coda di tipo FIFO, è facile aspettarci che anche il grafico di figura 6.10 rappresenti una retta, la cui pendenza è il numero medio di pacchetti scartati al secondo.

Come possiamo osservare, durante la generazione di traffico a 1,5Mbs per 600sec, sono stati scartati circa 171123 pacchetti, pari circa a 320Mbit, quindi, la percentuale di pacchetti scartati, è elevata circa il 30% del traffico complessivamente trasmesso. Questo valore era attendibile visto che il rate assegnato alla classe Expedited Forwarding era

(16)

Percentuale di pacchetti scartati:

(diffServCosEFIf3dropsPkts / (diffServCosEFIf3dropsPkts +

diffServCosEFIf3TxedPkts))*100

Sostituendo i valori delle rispettive MIB, interrogate durante la trasmissione del traffico otteniamo:

diffServCosEFIf3dropsPkts = 171123 pacchetti diffServCosEFIf3TxedPkts = 289655 pacchetti (171123 / (171123+289655))*100 = 33,3 %

• Test 1.B

Mantenedo instaurato lo stesso L-LSP, e generando sempre traffico con rate 1Mbit, osserviamo che pur aumentando la lunghezza della coda configurata per la classe di servizio EF, non riduciamo in alcun modo la percentuale di pacchetti scartati a regime. Per completezza riportiamo il grafico che rappresenta l’andamento dei pacchetti all’interno di un buffer di dimensione massima pari a 600 pacchetti (Fig 6.11).

(17)

(18)

Il valor medio della coda è aumentato ed è di circa 580 pacchetti, ma generando traffico CBR non otteniamo miglioramenti in termini di percentuale di pacchetti scartati.

6.3.2 Generazione di traffico Poissoniano

Creando lo stesso metodo descritto precedentemente L-LSP che assegni alla classe di servizio EF un rate di 2Mbit/sec, osserviamo il comportamento delle code in uscita dallo scheduler, quando andiamo a generare un traffico poissoniano.

Le proprietà del file di configurazione utilizzato nella generazione di traffico artificiale sono:

• <poisson>: densità di probabilità dei tempi di interpartenza dei pacchetti generati di tipo esponenziale.

• <msec> 100000 sec: durata complessiva della generazione dei pacchetti misura in millisecondi

• <saddr> 192.168.50.4 : indirizzo di sorgente dell’host che genera traffico a CBR. • <daddr> 192.168.40.4: indirizzo IP dell’host a cui è inviato il traffico.

• <lamda> λ=768: frequenza media di interpartenza espressa in pacchetti/sec. • <len> 350: lunghezza del frame Ethernet in byte.

Generiamo quindi mediamente un rate di 2Mbit/sec.

Il tempo di interarrivo dei pacchetti trasmessi in ingresso al interfaccia eth0 del router Postel, è distribuito secondo una densità di probabilità di tipo esponenziale negativo con valor medio 1 /λ.

Il processo che decrive la distribuzione dei pacchetti all’interno della coda in uscita dal router Postel è un processo di Poisson, con valor medio λt. In questo caso quindi, diventa molto importante valutare il numero medio dei pacchetti presenti nella coda, perché

(19)

modificando opportunamente la lunghezza assegnata al buffer di uscita, possiamo ridurre la percentuale di pacchetti scartati.

• Test 2.A

Interrogando la MIB relativa al numero di pacchetti trasmessi in uscita dal router Postel, possiamo dedurre il rate medio, che corrisponderà alla pendenza della retta (Fig 6.12).

Figura 6.11: Numero di Pacchetti trasmessi

(20)

Figura 6.12: Numero di pacchetti in coda, in seguito alla generazione di traffico poissoniano.

Come possiamo osservare dalla figura, l’andamento del numero dei pacchetti in coda non è regolare come nel caso di traffico CBR, ma presenta dei picchi dovuti al particolare processo di generazione del traffico di tipo poissoniano. Settando come lunghezza massima del buffer 20 pacchetti, osserviamo che il valor medio è circa 11 pacchetti.

Osservando inoltre il grafico di figura 6.12, possiamo facilmente capire che il grafico rappresentante il numero di pacchetti scartati, in questo caso, non avrà l’andamento di una retta (Fig 6.13).

(21)

Figura 6.13: Numero di pacchetti scartati nel Test 2.A

• Test 2.B

Per poter diminuire il numero medio di pacchetti scartati durante la generazione di traffico Poissoniano, aumentiamo la dimensione massima del buffer della coda, introducendo di conseguenza un ritardo maggiore nell’attraversamento della rete.

Osserviamo il grafico del numero dei pacchetti in coda aumentando il buffer fino a 150 pacchetti (Fig 6.14).

(22)

Figura 6.15: Numero di pacchetti scartati durante il Test 2.B

6.3.3 Calcolo dell’utilizzazione delle classi di

servizio

Per poter ottenere ulteriori informazioni sullo stato di funzionamento di una rete DiffServ, è molto importante conoscere l’utilizzazione media del throughput assegnato ad ogni classe di servizio.

In questa prova, andiamo ad instaurare un ulteriore L-LSP che assegni 10Mbit di rate al PSC AF11, mantenendo lo stesso percorso virtuale costruito per l’L-LSP relativo alla classe di servizio EF ad 1Mbit.

Successivamente, andiamo a generare del traffico artificiale di tipo poissoniano, ed osserviamo il numero di byte trasmessi in 100 secondi con PSC AF11, interrogando la MIB diffServCosAF1xIf3TxedBytes.

(23)

Figura 6.14: Numero di Mbyte trasmessi con PSC AF11

Il numero di byte complessivamente inviato è di 34,56MB, osservando la pendenza della retta possiamo calcolare il rate medio ottenuto durante la trasmissione di traffico in uscita dall’interfaccia 3 del router Postel, con PSC AF11. Tale rate, è 2,72 Mbit/sec.

Osservando la MIB diffServCosAF1xIf3Rate, è possibile avere la conoscenza del rate

assegnato alla classe di servizio AF1x.

diffServCosAF1xIf3Rate = 1310720 Byte/sec pari a 10 Mbit/sec

(24)