|
Torna alla pagina dei progetti:
PROGETTI
Progetto di Impianti di Elaborazione
Descrizione del Progetto
Realizzazione, usando netkit, di una Clique di n AS in cui tutti hanno un peering con tutti, con diversi valori di n. Verifica dei
tempi di convergenza di bgp nei router che compongono la clique, anche simulando guasti delle linee e dei router.
Soluzione del Progetto
Introduzione
Il lavoro è stato organizzato nelle tre seguenti fasi:
-
1. Realizzazione degli script di configurazione delle tre clique (uno per clique)
Ogni singolo script avvia e configura le macchine virtuali della clique cui si riferisce. Non sono
state adottate politiche particolari (prefix-filtering, settaggio di local-preference, prepending…). In
tutti e tre i casi si è deciso di far annunciare le lan interne soltanto da AS1, AS2, AS3. Questo solo
per uniformità di esecuzione delle simulazioni.
-
Realizzazione degli script di simulazione dei danni
Stabilizzatasi la rete, viene simulato lo stesso danno per tutte le clique: viene interrotto il peering
tra R1 e R2, rispettivamente router di bordo dell’AS1 e dell’AS2. Dopo un certo intervallo di
tempo in cui la rete raggiunge la nuova configurazione, è ripristinato il peering.
-
Analisi dei risultati degli esperimenti
Per confrontare i tempi di convergenza delle varie clique, abbiamo scelto come metrica il numero
di pacchetti di update inviati dai router. L’analisi è stata fatta a partire dal file di log del demone
bgp di zebra su ogni router e dalle tabelle di routing BGP.
Simulazione
La simulazione si è svolta nelle seguenti fasi principali:
-
Lancio dello script per avviare tutte le macchine virtuali coinvolte
Vengono avviate e configurate le macchine virtuali. Memorizzazione nel file di configurazione di
zebra dei peer e delle rotte annunciate.
-
Attesa del raggiungimento della convergenza delle rotte bgp
Diversa a seconda del numero di AS della clique (vedere seguito).
-
Shutdown del peering tra l’AS1 e l’AS2
Attraverso la chiamata di un nuovo script (test_nX) viene interrotto il peering tra l’AS1 e l’AS2,
modificando il file di configurazione del router 1 attraverso il comando neighbor 111.1.1.2
shutdown ed il riavvio di zebra.
-
Attesa del raggiungimento della nuova configurazione stabile della rete
Diversa a seconda del numero di AS della clique (vedere seguito).
-
Ripristino del peering tra l’AS1 e l’AS2
Per ripristinare il peering viene modificato il file di configurazione del router 1 utilizzando il
comando no neighbor 111.1.1.2 shutdown e riavviando zebra.
-
Attesa del raggiungimento della nuova configurazione stabile della rete
Diversa a seconda del numero di AS della clique (vedere seguito).
Esecuzione degli script
Gli script che è possibile lanciare sono tre, uno per ogni clique (clique3.sh, clique4.sh, clique5.sh).
Per avviare le macchine virtuali, portarsi all’interno della directory homework2, quindi digitare
dalla shell il comando cliqueX.sh start (X=3, 4, 5).
Viene chiesto al momento dell’esecuzione se lanciare le macchine in parallelo, digitando no, oppure
in sequenza, digitando yes e premendo invio al termine dell’avvio di ogni macchina. Ogni script a
sua volta richiama automaticamente il relativo script che simula il guasto ed il ripristino del peering
(test_n3.sh, test_n 4.sh, test_n 5.sh).
Per effettuare il crash delle macchine, sempre nella stessa directory, digitare dalla shell il comando
cliqueCrashX.sh crash.
Per una corretta simulazione e per consentire alla rete di convergere nelle tre differenti fasi,
sono state inserite negli script di test delle istruzioni di sleep: è necessario attendere circa
sei minuti per il completamento del test.
Note per la lettura delle tabelle
Tutte le tabelle sono composte da sei campi:
- Tempo (ora dell’evento).
- Send/Receive (se il messaggio è stato inviato o ricevuto).
- Peer (AS adiacente con il quale è stato scambiato il messaggio).
- AS-path (il cammino che il pacchetto ha effettuato per arrivare a destinazione).
- Best Path (best attualmente memorizzato nella tabella bgp).
- Eventi (viene visualizzato se il pacchetto ricevuto o mandato scatena un evento degno di nota).
Il campo Eventi può assumere uno dei seguenti valori:
- Update bgp table: viene aggiornato il best con il path appena ricevuto.
- ASx unreachable: il router di bordo comunica al peer che l’ASx non è più raggiungibile.
- Denied(cycle): l’annuncio appena ricevuto viene scartato per la presenza nel path del proprio AS (ciclo).
- ASx withdrawn: il peer ha comunicato di non poter più raggiungere l’ASx.
- Duplicate ignored: l’annuncio appena ricevuto viene scartato poiché l’informazione in esso contenuta è già presente nella routing table;
- A: per i rimanenti tipi di annunci.
Per risaltarne l’importanza ad alcune righe sono stati assegnati dei colori:
Cambiamento di best del peering tra R1 e R2.
Shutdown del peering.
Riparazione del peering.
Avvenuto withdrawn tra l’AS1 e l’AS2.
Pacchetti "duplicati".
Le righe evidenziate in rosso ed in verde non sono da intendere in riferimento alle colonne ma
vanno lette come delle semplici frasi.
Studio della convergenza della clique
-
CLIQUE con tre AS
Architettura della clique
La clique è composta da tre AS, ciascuno dei quali ha un peering con gli altri due. Ogni AS ha un solo
router di frontiera che annuncia la lan interna all’AS al resto della clique.
La Simulazione
- Attesa del raggiungimento della convergenza delle rotte bgp
Per ottenere una configurazione bgp stabile ogni router di frontiera invia due pacchetti di
UPDATE a ciascun peer (e ovviamente ne riceve altrettanti). Complessivamente quindi nella
clique circolano 12 pacchetti di UPDATE. I primi due che vengono mandati (uno per peer)
annunciano la lan interna all’AS (path di lunghezza 1); dopo circa trenta secondi sono inviati gli
altri due pacchetti che annunciano le nuove lan raggiungibili tramite l’AS (path di lunghezza 2).
- Attesa del raggiungimento della nuova configurazione stabile della rete
Una volta riavviato il demone zebra del router 1, avendo "buttato giù" il peering, i router si
scambiano degli ulteriori pacchetti di UPDATE per aggiornare le proprie tabelle bgp. R1 comunica
ad R3 che l’AS2 non è più raggiungibile passando per l’AS1. La stessa cosa viene comunicata tra
R2 e R3. Di conseguenza, vengono modificate le tabelle eliminando i percorsi non più validi e
aggiornando i best. Ad esempio, per raggiungere l’AS2, l’AS1 dovrà passare obbligatoriamente
per l’AS3. Il restarting del demone di R1 causa anche il riannuncio della propria lan ad R3, che
però riconosce il pacchetto come duplicato e lo ignora. Il numero totale di pacchetti inviati è quindi 3.
- Attesa del raggiungimento della nuova configurazione stabile della rete
Avendo ripristinato il peering, i router di frontiera di AS1 e AS2 si scambiano tutte le rotte
conosciute. Questo comporta il riaggiornamento delle tabelle bgp e la possibilità di ricevere degli
UPDATE contenenti cicli (es R2 invia ad R1 il path 2 3 1); questi cammini sono naturalmente
scartati. A questo punto dopo circa 30 secondi R1 comunica ad R3 che è possibile raggiungere
l’AS2 passando attraverso il suo AS; stessa cosa viene comunicata da R2 ad R3. Il numero totale
di pacchetti inviati è quindi 8.
Tabelle di convergenza
-
CLIQUE con quattro AS
Architettura della clique
La clique è composta da quattro AS, ciascuno dei quali ha un peering con gli altri tre. Ogni AS ha un
solo router di frontiera; i soli router AS1, AS2, AS3 annunciano le proprie lan interne al resto della
clique.
La Simulazione
- Attesa del raggiungimento della convergenza delle rotte bgp
Per ottenere una configurazione bgp stabile anche in questo caso il tempo impiegato è di circa 33
secondi. A differenza della clique precedente i pacchetti inviati per la convergenza della rete sono
28, più del doppio. In particolare risulta differente la sequenza dei pacchetti scambiati, ad esempio
tra il router1 ed il router2 passano circa 9 secondi prima che vengano annunciate le rispettive lan
(path di lunghezza 1): questo comporta l’invio di un pacchetto contenente un path di lunghezza tre:
R2 manda ad R4 il path 2 3 1, non avendo ancora ricevuto "notizie" direttamente da R1; quindi il
suo attuale best per raggiungere AS1 è proprio 3 1.
-
Attesa del raggiungimento della nuova configurazione stabile della rete
Una volta riavviato il demone del router di bordo R1 questo reinvia ai peer la propria lan interna,
pacchetti che però vengono scartati da R3 e R4 poiché duplicati. Ed inoltre R1 manda a R3 un
messaggio con R2 unreachable e subito dopo, essendosi ricalcolato il best, comunica ad R4 il
nuovo path 1 3 2. In modo simmetrico R2 esegue quest’ultime operazioni (il path è 2 3 1). In
conclusione il tempo impiegato per il raggiungimento della convergenza è di circa 30 secondi ed il
numero di updates inviati è 6 ( il doppio della clique precedente).
- Attesa del raggiungimento della nuova configurazione stabile della rete
Non appena viene ripristinato il peering, il router di frontiera di AS2 invia tutte le rotte conosciute
all’AS1 che modifica la tabella di routing bgp aggiornando i best, e scarta (ciclo) il pacchetto
ricevuto riguardante la propria lan. R1 invia due pacchetti per ogni interfaccia (tra questi ci sono
anche dei duplicati), di conseguenza gli altri router aggiornano le loro tabelle di instradamento. Il
numero totale di pacchetti inviati è quindi 11.
Tabelle di convergenza
-
CLIQUE con cinque AS
Architettura della clique
La clique è composta da cinque AS, ciascuno dei quali ha un peering con gli altri quattro. Ogni AS ha un
solo router di frontiera; i soli router AS1, AS2, AS3 annunciano le proprie lan interne al resto della
clique.
La Simulazione
- Attesa del raggiungimento della convergenza delle rotte bgp
Per ottenere una configurazione bgp stabile anche in questo caso il tempo impegato è di circa 33
secondi. A differenza della clique precedente i pacchetti inviati per la convergenza della rete sono 49,
poco meno del doppio della clique con quattro AS. Osservando le tabelle riportate si possono
facilmente riscontrare analogie con i medesimi punti delle clique precedenti anche se naturalmente
la rete converge più lentamente.
- Attesa del raggiungimento della nuova configurazione stabile della rete
UUna volta riavviato il demone del router di bordo R1 questo reinvia ai peer la propria lan interna,
pacchetti che però vengono scartati da R3, R4 ed R5 poiché duplicati; R1 riannuncia al resto della
clique il nuovo best verso R2, che si comporta in maniera analoga. Il tempo impiegato per il
raggiungimento della convergenza è di circa 30 secondi ed il numero di updates inviati è 9.
- Attesa del raggiungimento della nuova configurazione stabile della rete
Il comportamento è esattamente lo stesso della clique precedente, naturalmente vengono inviati
anche i pacchetti all’AS5 che prima non esisteva. Il numero totale di pacchetti inviati è quindi 14.
Tabelle di convergenza
|
|
