Rete di 3 Autonomous Systems (AS)

Abbiamo definito un lab utilizzando Netkit, un software free realizzato dall'Università degli studi Roma Tre. Netkit consente di lanciare più Virtual Machines in un ambiente Linux, ciascuna delle quali rappresenta un apparato di rete. Viene utilizzato il demone Zebra per aggiornare il Data Plain sulla base delle tabelle costruite nel Control Plain (demoni di routing bgp, rip, ospf...)
Il lab è composto da tre AS: un AS HRR che fa da transito tra l’AS100 e l’AS200. Quindi l’AS HRR riceve e propaga la full routing table ai suoi vicini (l’unica rotta che non accetta è quella di default) e inoltra il traffico tra essi. Inoltre, dato che all’interno di un AS di transito possono esserci dei customer che vogliono connettersi ad Internet, abbiamo inserito nell’AS HRR due lan visibili dall’esterno e con connettività verso il resto di Internet. L’AS HRR è caratterizzato da una gerarchia di route-reflector a due livelli. I punti fondamentali sono i seguenti:

• I router di frontiera dell’AS HRR accettano tutte le rotte tranne quella di default e annunciano le lan interne e le DMZ.
• Tali router ridistribuiscono EBGP dentro RIP, evitando di ridistribuire IBGP grazie all’uso di una route-map che verifica che il next-hop di un annuncio sia il router di un neighbor e non un router interno. Ciò è necessario per evitare il formarsi di cicli interni di forwarding.
• C’è ridondanza nell’implementazione della gerarchia dei route-reflector: al primo livello ci sono due coppie di RR, ciascuna delle quali riguarda due cluster sovrapposti. Anche nel secondo livello i peering sono ridondati. Dato che i RR non hanno peering EBGP, non ridistribuiscono BGP dentro RIP.
• I collegamenti verso le lan interne sono ridondati.
• I customer AS100 e AS200 multi-homing nei confronti di AS HRR. Per i pacchetti in uscita un link viene usato come backup grazie alla modifica della local-preference degli annunci.

Una volta aver definito correttamente il lab, abbiamo realizzato i seguenti test:

• Connettività tra AS100 e AS200, tramite PING e TRACEROUTE.
• Connettività tra le due LAN interne all’AS HRR.
• Connettività tra le LAN interne all’AS HRR e l’AS100 e l’AS200.
• Fault su vari link dell’AS HRR (alcuni documentati nelle schede di test allegate) fino ad ottenere un unico cammino disponibile per fare transito tra AS100 e AS200. Abbiamo anche verificato la non connettività quando non esisteva più un cammino disponibile.
• Fault sui link che implementano peering EBGP per verificare l’uso dei link di backup.

Le conclusioni scaturite dalle prove effettuate sono le seguenti:

• Senza bloccare la redistribuzione IBGP in RIP si formano dei cicli interni, che causano assenza di connettività tra alcune parti dell’AS HRR.
• L’AS100 e l’AS200 usano correttamente per i pacchetti in uscita un solo link, sfruttando l’altro come backup, cioè solo quando il link principale è giù.
• La ridondanza generata nei vari livelli dei route-reflector e nella raggiungibilità delle LAN interne consente di supplire al fault di un link, mantenendo la connettività.
• Causando vari fault nei diversi livelli della gerarchia la connettività non si perde finché resta almeno un cammino disponibile. Abbiamo portato al limite questo comportamento, lasciando esattamente un cammino disponibile.
• Viene utilizzata tutta la gerarchia dei RR quando si fa da transito tra due AS.
• Abbiamo così evitato la full-mesh IBGP dei router di frontiera.

Ecco alcune schede di test che abbiamo realizzato: TEST