Analisi del problema

Per effettuare una simulazione che potesse offrire dei risultati apprezzabili, sui quali si potessero investigare gli effetti concreti dell'algoritmo del route flap dampening (RFD), è stata svolta una fase preliminare di studio della materia, facendo riferimento a risorse pubblicamente accessibili su Internet, che vengono citate nel documento.

2. Preparazione dell'ambiente di simulazione

Gli strumenti e risorse utilizzate nella simulazione sono state:

• Netkit modificato (cfr. Homework n°1 “Nesting UML”)

• Uno script Bash per l'avvio delle macchine virtuali e la loro inizializzazione nella configurazione scelta per l'esperimento (cfr. file allegato clique.sh)

• Uno script Python (cfr. file allegato telnet.py) che a istanti di tempo prefissati (circa 15 secondi) si occupa di prelevare il contenuto della BGP routing table (show ip bgp) e le flap statistics (show ip bgp flap-statistics e show ip bgp <beacon-prefix>) del router BGP su cui lo script viene eseguito. Era stata preso in considerazione l'utilizzo di uno script in linguaggio Expect con circa le stesse funzionalità, fornito ed usato da Oregon Route Views

• I log zebra del demone bgpd. Il contenuto di questi log è stato “incrociato” con quello fornito dall'esecuzione dello script Python

Analisi del problema

Per effettuare una simulazione che potesse offrire dei risultati apprezzabili, sui quali si potessero investigare gli effetti concreti dell'algoritmo del route flap dampening (RFD), è stata svolta una fase preliminare di studio della materia, facendo riferimento a risorse pubblicamente accessibili su Internet, che vengono citate nel documento.

2. Preparazione dell'ambiente di simulazione

Gli strumenti e risorse utilizzate nella simulazione sono state:

• Netkit modificato (cfr. Homework n°1 “Nesting UML”)

• Uno script Bash per l'avvio delle macchine virtuali e la loro inizializzazione nella configurazione scelta per l'esperimento (cfr. file allegato clique.sh)

• Uno script Python (cfr. file allegato telnet.py) che a istanti di tempo prefissati (circa 15 secondi) si occupa di prelevare il contenuto della BGP routing table (show ip bgp) e le flap statistics (show ip bgp flap-statistics e show ip bgp <beacon-prefix>) del router BGP su cui lo script viene eseguito. Era stata preso in considerazione l'utilizzo di uno script in linguaggio Expect con circa le stesse funzionalità, fornito ed usato da Oregon Route Views

• I log zebra del demone bgpd. Il contenuto di questi log è stato “incrociato” con quello fornito dall'esecuzione dello script Python

3. La configurazione utilizzata

L'intento della simulazione è stato quello di analizzare il comportamento dell'algoritmo di dampening. A tale scopo abbiamo scelto una configurazione di rete osservabile nella figura sottostante.

Per l'analisi richiesta è stata utilizzata la tecnica denominata BGP Beacon: un singolo prefisso (nella nostra simulazione: 200.0.1.0/24), viene annunciato e ritirato ad istanti di tempo programmati, e vengono esaminate le reazioni in punti differenti della rete.

Per illustrare tali effetti abbiamo scelto di usare una clique di 5 AS (ognuna con un solo border gateway), e un AS (AS2, nella figura è posizionato in alto a destra) collegato ad uno dei nodi della clique diverso dalla sorgente del beacon (che è AS10, nella figura collocato a sinistra).

Per agevolare l'analisi dei log prodotti, nella figura sono stati evidenziati i domini di collisione di ciascuna interfaccia disponibile per ogni border gateway componente la clique.

Le configurazioni del demone bgpd hanno i valori di default sia per quel che riguarda le policy di routing (ovvero ogni router non filtra e non applica preferenze a ciò che invia o riceve), sia per i parametri dell'algoritmo di dampening.

C'è da sottolineare che l'implementazione Zebra del dampening non aderisce alle indicazioni del RIPE per la scelta dei valori dei parametri (cfr. “RipeRouting-WG Reccomentations For Coordinated Route Flap Damping Parameters” – October 2001, document id: ripe-229). Dagli esperimenti svolti e grazie agli effetti riscontrati e alla rapida visione del codice sorgente di bgp_damp.c, è stata desunta la seguente tabella, che pertanto allinea Zebra ai valori utilizzati da CISCO:

Viene considerato route flap:

• ogni withdrawal

• ogni announcement consecutivo successivo al primo, per uno stesso prefisso, da parte dello stesso peerer.

Zebra non consente di effetture damping in modo diverso per prefissi di lunghezza diversa, ma impone un'unica damping policy, come invece suggerito dal RIPE (vedi tabella)

Infine, Zebra non rispetta il suggerimento di adottare un MRAI timer di 30 secondi: ciò è stato verificato osservando un router annunciare a un vicino lo stesso prefisso (ma con path diverso) a distanza di meno di 30 secondi.

4. La simulazione

La simulazione si è svolta nelle seguenti fasi principali:

1. Lancio dello script per avviare tutte le macchine virtuali coinvolte nella simulazione

2. Attesa del raggiungimento della convergenza delle rotte bgp

3. Withdrawal esplicito del prefisso beacon (200.0.1.0/24) da parte dell'AS10

4. Attesa del raggiungimento della nuova configurazione stabile della rete

5. Riannuncio del prefisso beacon da parte di AS10 dopo un tempo di circa 11 minuti dall'ultimo ritiro. Con le transizioni che hanno portato dalla fase 3 alla fase 5 si è simulato il guasto e la momentanea riparazione dell'interfaccia sul dominio di collisione A (nb: non si è potuto disattivare l'interfaccia sulla macchina virtuale per ottenere lo stesso risultato per limiti di User Mode Linux)

6. Dopo circa 1-2 minuti il prefisso viene ritirato di nuovo da parte di AS10 (la riparazione non era stata completata)

7. Dopo altri 3-4 minuti AS10 riannuncia il prefisso beacon

8. Attesa della nuova convergenza delle rotte e verifica della soppressione del prefisso beacon sul router di AS2 (prefisso annunciato ad AS2 da AS30). Verifica anche, nei router AS20 AS30 AS40 AS50, di eventuali soppressioni di path “alternativi” (i non best path) verso il prefisso beacon.

9. Attesa del raggiungimento del reuse threshold da parte di AS2, dopo il quale esso può utilizzare di nuovo il path verso il prefisso beacon. Verifica di ristabilizzazione di rotte che erano state soppresse anche sugli altri nodi della clique (cfr. punto 8).

Al fine di osservare i vari cambiamenti nelle configurazione dei router componenti la nostra rete, sono stati usati e incrociati i log prodotti da zebra per il demone bgpd, e i log prodotti dal nostro script Python.

Per le tabelle di convergenza della simulazione effettuata fare riferimento al paragrafo dedicato, allegato in fondo al documento.

5. Note e conclusioni

Come già discusso, i guasti sono stati simulati solamente per mezzo di withdrawal espliciti del prefisso beacon, da parte dell'AS origine, per mezzo del comando bgp no network <prefix>. Infatti spegnere un'interfaccia di rete con il comando ifconfig ethx down non produce sempre i risultati aspettati, per limiti dovuti a User Mode Linux. Altrimenti si sarebbe dovuto crashare la virtual machine costituente un singolo router, e successivamente riavviarla, ma ciò avrebbe causato la simulazione del guasto di tutte le sue interfaccie di rete e non di una sola come voluto per la simulazione.

L'intento secondario della simulazione è stato quello di verificare i risultati esposti nell'articolo“Route Flap Damping Exarcebates Internet Routing Convergence” (Mao, Govindan, Varghese, Katz): un singolo withdrawal seguito da un reannouncement del prefisso avrebbe dovuto causare l'accumulo di penalità fino a superare il suppression threshold, oltre il quale il prefisso doveva essere soppresso per un certo periodo di tempo (un outage time fino a un'ora). I nostri risultati purtroppo non ci hanno permesso una tale verifica: nel nostro esperimento il numero di withdrawal seguiti da reannuncement che hanno portato alla soppressione di rotte sono stati due.

Tabelle di convergenza per ciascun border gateway coinvolto nella simulazione

Nomenclatura e simbologia:

• Tempo: l'istante di tempo di osservazione dello stato del router. Vengono presi in considerazione gli istanti di tempo più significati fra quelli campionati dallo script Python (che ha un tempo di campionamento di circa 15 secondi). Ciò implica che messaggi che nella realtà sono stati ricevuti fra due intervalli di campionamento consecutivi, vengono riportati tutti come avvenuti allo stesso istante di campionamento.

• A/W: Announcement/Withdrawal del prefisso beacon 200.0.1.0/24. Un '-' indica che si sta semplicemente osservando uno stato

• Peer: il vicino che ha inviato l'announcement o withdrawal

• AS Path: il cammino verso il prefisso beacon avente come next hop il Peer che l'ha annunciato o ritirato. Un '*' indica che il cammino è valido, un 'h' che il cammino è stato ritirato e fa parte solo della history, un '*d' che il cammino è valido ma è stato soppresso dall'algoritmo di dampening. Se il cammino annunciato da un Peer è evidenziato in grigio, questo presenta un ciclo: pertanto il router cancellerà dalla history il path annunciato dal Peer.

• Best Path: se presente, indica il miglior path verso il prefisso beacon. È indicato con '*>' per aderenza con gli output della console interattiva del demone zebra bgpd

• Penalty: se presente, indica la penalty associata dall'algoritmo di dampening al prefisso beacon annunciato/ritirato dal Peer

• Flaps: se presente, indica il numero di volte che il prefisso beacon ha “flappato” a causa di messaggi inviati dal Peer

• Duration: se presente, indica il tempo trascorso dal primo flap del prefisso beacon annunciato/ritirato dal Peer

• Reuse: se presente, indica che la rotta avente come next hop il Peer è stata soppressa, e per essere riammessa è necessario aspettare questo “reuse time”

Per dare maggiore evidenza alla soppressione di cammini, i record relativi a tali path sono stati evidenziati in rosso. La successiva riabilitazione di un cammino soppresso è evidenziata dal colore celeste.

Nel caso in cui vi siano n messaggi ricevuti allo stesso orario, per i primi n-1 nella colonna Best Path c'è l'indicazione transitorio, mentre a seguito dell'n-esimo viene indicato il best path scelto in base alla ricezione ed elaborazione degli n messaggi complessivi.

AS30 border gateway

AS2 border gateway

Osservare come AS30 faccia path exploration e causi due flap su AS2 nel giro di mezzo minuto (circa dalle 17:26:57 alle 17:27:28).

AS20 border gateway

AS40 border gateway

AS50 border gateway