Il meccanismo di funzionamento è il seguente:
- Quagga prende le rotte locali e le annuncia al peer
- Quagga prende le rotte apprese dall'istanza locale di olsr e le manda al peer
- Quagga prende le rotte apprese dal peer e dall'istanza locale di OLSR e le scrive nella tabella di routing del kernel
bgpd.conf
questo file si trova in /etc/quagga
hostname bgpLAMIACITTA password lamiapassword1 enable password lamiapassword2 ! access-list vty permit 127.0.0.0/8 access-list vty deny any ! line vty access-class vty ! router bgp IL_MIO_AS_NUMBER bgp router-id IL_MIO_IP redistribute connected redistribute olsr neighbor 10.150.254.4 remote-as 64512 neighbor 10.150.254.4 description BGP Roma neighbor 10.150.254.4 route-map FILTERIN in neighbor 10.150.254.4 route-map FILTEROUT out ! ip prefix-list FILIN seq 10 deny 10.11.12.0/25 le 32 ip prefix-list FILIN seq 20 deny 150.217.0.0/16 le 32 ip prefix-list FILIN seq 30 deny 176.62.53.0/24 le 32 ip prefix-list FILIN seq 41 deny 10.150.254.0/24 le 32 ip prefix-list FILIN seq 42 deny 10.X.X.X/16 le 32 ip prefix-list FILIN seq 43 deny 172.16.X.X/24 le 32 ip prefix-list FILIN seq 70 permit any ! ip prefix-list FILOUT seq 41 deny 10.150.254.0/24 le 32 ip prefix-list FILOUT seq 70 permit any ! route-map FILTERIN permit 10 match ip address prefix-list FILIN ! route-map FILTEROUT permit 10 match ip address prefix-list FILOUT ! route-map FILTER deny 50 !
Le informazioni di AS number e Ip presi da gestione indirizzi sono utilizzati in questo file. Le direttive "redistribute" non fanno altro che mandare al peer le rotte locali (connected) e quelle apprese via olsr (olsr). La prima serve perchè l'hna annunciato localmente non viene preso in considerazione. Quando si parla di rotte locali in un sistema multitable si intende quelle presenti nella tabella main (ip r s t main).
Se nella nostra tabella abbiamo delle rotte che non annunciamo il olsr e non vogliamo che vadano in giro per le isole le inseriamo nella lista FILOUT. Questo è il caso dalla 10.150.254.0/24 che è la sottorete della VPN e non ha senso annunciare anzi può essere dannosa in quanto una volta arrivata potrebbe far cadere la connessione vpn che l'ha trasportata (autodistruzione).
Stesso discorso per le reti che si "apprendono" dall'esterno. In questo caso decide di filtrare in ingresso:
- 10.11.12.0/25 che è la sottorete anycast romana
- 150.217.0.0/16 non lo so
- 176.62.53.0/24 gli indirizzi pubblici di Roma, essendo pubblici è inutile routarli via VPN
- 10.150.254.0/24 la sottorete della vpn
- 10.X.X.X/16 la classe di ip che sono stati assegnati alla mia isola
- 172.16.X.X/24 la classe di ip che sono stati assegnati alla mia isola
Per ottimizzare il le tabelle di routing conviene aggregare le tabelle di routing. (Parte da spiegare meglio)
! aggregato backbone network 172.16.xx.0/24 !aggregato lan aggregate-address 10.xx.0.0/16 ! filtra tutte le /32 ip prefix-list FILOUT seq 22 deny 0.0.0.0/0 ge 32
zebra.conf
questo file si trova in /etc/quagga
password lamiapassword1 table 111 ! access-list vty permit 127.0.0.0/8 access-list vty deny any ! line vty access-class vty! ! route-map NINUX_PRIVATE permit 10 set src 10.x.x.x ip protocol bgp route-map NINUX_PRIVATE
Unica cosa interessante di questo file è che diciamo in che tabella del kernel mettere le rotte apprese, ovvero la 111.
Il set src 10.x.x.x mettere l'ip privato della router in modo tale che gli indirizzi in tabella non abbiano l'indirizzo dellla VPN la cui barra viene filtrata.