⇤ ← Versione 1 del 2015-01-01 12:33:39
Dimensione: 1623
Commento:
|
Dimensione: 2567
Commento:
|
Le cancellazioni sono segnalate in questo modo. | Le aggiunte sono segnalate in questo modo. |
Linea 3: | Linea 3: |
Con il 2015 finirà il supporto per OLSR V1, il protocollo attualmente in produzione nell'isola romana. La presente pagina vuole essere una base comune per organizzare la sperimentazione della versione 2 di olsr attualmente in versione alpha. | Con il 2015 finirà il supporto per OLSR V1, il protocollo attualmente in produzione nell'isola romana. La presente pagina vuole essere una base comune per organizzare la sperimentazione della versiTheNetworkone 2 di olsr attualmente in versione alpha. |
Linea 12: | Linea 12: |
* Regole di Policy Routing atte effettuare l'interoperabilità | * Regole di Policy Routing atte ad effettuare l'interoperabilità |
Linea 29: | Linea 29: |
La rete OLSRv2 utilizzerà per Roma lo spazio 10.100.0.0/14 così assegnata: Si immagina una X su roma centrata su "Stazione Termini" dividendo Roma in 4 quadranti: Nord,Est,Sud,Ovest. * 10.100.0.0/16: Nord * 10.101.0.0/16: Est * 10.102.0.0/16: Sud * 10.103.0.0/16: Ovest Il motivo è quello del routing dei privati verso le isole. Al momento il BGP isole è solo in un punto ma se dovesse essercene un altro la divisione geografica potrebbe aiutare il bilanciamento del traffico in ingresso. Per lo stesso motivo, ovvero bilanciamento del traffico in ingresso e simmetrizzazione dello stesso, va fatto per IPV6 dove già ci sono 2 punti di traffico in uscita ma solo uno è utilizzato per l'ingresso. Data l'estensione dello spazio di indirizzi si potrebbe usare un nibble più significativo dell'indirizzo per settare il proprio punto in ingresso del traffico (scalabile fino a 16 BGP in IPv6) TODO: Le policy == Regole Policy Routing == |
|
Linea 31: | Linea 44: |
== Regole Policy Routing == TODO |
RFC Sperimentazione OLSR V2 a Roma
Con il 2015 finirà il supporto per OLSR V1, il protocollo attualmente in produzione nell'isola romana. La presente pagina vuole essere una base comune per organizzare la sperimentazione della versiTheNetworkone 2 di olsr attualmente in versione alpha.
Roadmap
OLSRv2 non è compatibile e non interoperabile nativamente con la versione precedente quindi occorre un approccio simile a quello adottato per l'IPV6 a livello mondiale, ovvero avere entrambi ed entrambi operativi. Per ottenere questa migrazione ci sarà bisogno:
- Di un FW per routing in antenne (airOS e Openwrt)
- Di un FW per il routing a terra (Openwrt)
- Spazio di indirizzamento IPv6 e IPv4 disgiunti dall'attuale indirizzamento.
- Regole di Policy Routing atte ad effettuare l'interoperabilità
Firmware per il routing sulle antenne (airOS)
Per la vesione modicata di AIROS (nome in codice Sburratone) si avranno le seguenti versioni:
SburratoneV2.x : con OLSR v1 e v2 interoperanti
SburratoneV3.x : con solo OLSR v2
Firmware OpenWRT
Per la versione Openwrt si potrebbe convergere sul progetto LibreMash facendo:
- Plugin per OLSR V1
- Plugin per OLSR V2
in questo modo si ottimizzano gli sforzi con un progetto comune.
Spazio di indirizzamento
La rete OLSRv2 utilizzerà per Roma lo spazio 10.100.0.0/14 così assegnata: Si immagina una X su roma centrata su "Stazione Termini" dividendo Roma in 4 quadranti: Nord,Est,Sud,Ovest.
- 10.100.0.0/16: Nord
- 10.101.0.0/16: Est
- 10.102.0.0/16: Sud
- 10.103.0.0/16: Ovest
Il motivo è quello del routing dei privati verso le isole. Al momento il BGP isole è solo in un punto ma se dovesse essercene un altro la divisione geografica potrebbe aiutare il bilanciamento del traffico in ingresso. Per lo stesso motivo, ovvero bilanciamento del traffico in ingresso e simmetrizzazione dello stesso, va fatto per IPV6 dove già ci sono 2 punti di traffico in uscita ma solo uno è utilizzato per l'ingresso. Data l'estensione dello spazio di indirizzi si potrebbe usare un nibble più significativo dell'indirizzo per settare il proprio punto in ingresso del traffico (scalabile fino a 16 BGP in IPv6) TODO: Le policy
Regole Policy Routing
TODO
Altre features
Approfitttando dell'aggiornamento del fw sarebbe il caso di inserire le seguenti features:
- Metodo per aggiungere in modo dinamico gli IP pubblici
- Attivare di default il supporto per MLDv2
- Monitoring utilizzando Munin