[Ninux-Calabria] Link disegnati NinuCS - Diario di bordo

[Stefano De Carlo]

Ciao a tutti,

negli ultimi 2 giorni mi sono addentrato nella questione dei link
cosentini mancanti sul map server. È una questione estremamente
eterogenea: il map server si è tirato dentro le VPN, che si tirano
dietro i protocolli di routing, che si tirano dietro l'architettura di
NinuCS (vedi post di Spax).

Come vengono disegnati i link dal mapserver?
Codice:
https://github.com/ninuxorg/nodeshot/blob/master/nodeshot/scripts/read_topology_hna.py

Il mapserver, ogni 5 minuti (crontab), esamina la topologia di OLSR [1],
che essendo un protocollo link state la contiene tutta. Se un
collegamento è riportato all'interno della topologia, il link è
disegnato. Altrimenti no. Semplice.
La topologia è ovviamente inclusa in qualsiasi nodo faccia girare il
demone OLSR, ma il map server per consultarla ha bisogno di estrarla in
un formato comprensibile. Questo formato è il "textinfo plugin", un file
di testo che contiene varie tabelle come Links, Routes, HNA, Topology e
colonne come Costo/ETX, Link Quality, Neighbor Link Quality, ecc. Ne
trovate un esempio in produzione qui: http://topology.ninux.l0g.in/ipv4/
Questo file viene prodotto dal plugin textinfo di OLSR, uno di quelli
inclusi di default. Il nostro primo errore è stato di non caricare e
attivare questo plugin nella configurazione di OLSR che gira su Rohan
(il nostro nodo VPN Isole). A questo abbiamo ovviato: porta 2006,
accetta connessioni da ogni IP.

Perché era un errore? Per capirlo bisogna fare un passo indietro e
ripercorrere le varie VPN Isole disponibili in Ninux.

VPN Norimberga: http://wiki.ninux.org/TincVPNItaliano
L'abbiamo usata a Cosenza prima del patatrac OldSPIG, ed è tuttora in
uso a Reggio Calabria. È essenzialmente un "prolungamento" di OLSR,
fatto girare dentro ad un tunnel tinc. Girandoci OLSR, le info sulla
topologia vengono trasportate di isola in isola e pertanto, al map
server, basta consultare il textinfo di un qualsiasi nodo (in realtà il
map server stesso è un nodo, pertanto l'estrazione avviene su
localhost:2006) per conoscerla e disegnare i link di conseguenza. Ecco
perché Dario, una volta settato tinc, non ha dovuto più fare null'altro.
È ormai deprecata in favore della VPN con babel, a causa delle
prestazioni tremende di tutto il pressoché inutile traffico olsr che
viaggiava sul tunnel.

VPN Babeld: http://wiki.ninux.org/IsoleVPN
Attiva da qualche mese, è la VPN che stiamo implementando adesso a
Cosenza. La differenza è che le rotte vengono scambiate sul tunnel
(sempre realizzato con tinc) non più con OLSR ma con Babel. L'ovvio
vantaggio sono le prestazioni, rinunciando a tutto il traffico di hello
OLSR. Le rotte apprese tramite babel devono poi, agli endpoint della
VPN, essere "iniettate" dentro OLSR. Come avviene questa punturina?
Attraverso il plugin proto_rc3 sviluppato da quelli di Ninux. Le rotte
apprese compaiono, all'OLSR di un estremo della VPN, come subnet HNA4
dell'altro estremo. Il problema di quest'approccio che in questo momento
ci interessa è che così facendo le informazioni topologiche
indispensabili al map server vengono perdute, "appiattite" da Babel. Per
ovviare a tutto ciò le isole che usano questa VPN devono fornire un
indirizzo ad un file in formato textinfo che descrive la topologia
interna all'isola, originale, intatta, non edulcorata, da inserire nelle
OLSR_URLS o BATMAN_URLS che il map server controllerà.

VPN BGP: http://pad.lilik.it/p/bgp
L'approccio VPN con babeld, per quanto elegante, ha dei problemi a lungo
termine: il plugin unofficial proto è bacato, non molto manutenuto, e
soprattutto non supporta IPv6 (orrore e raccapriccio). Senza contare
che, per questo routing da bordo, esiste BGP apposta. Sicuramente
sperimenteremo anche questa VPN per assicurarci il futuro, ma al momento
non è il nostro focus, soprattutto perché anche con questa la topologia
e la sua esposizione tramite textinfo devono essere corrette,
esattamente alla stessa maniera della VPN babeld.

Dunque una volta compreso che bisognava esporre la nostra topologia, ho
comunicato a Nemesis l'indirizzo Ninux da quale estrarla:
http://172.17.87.2:2006/all
http://10.0.5.6:2006/all

Si tratta dello stesso nodo, rohan, sulle due interfacce (ninux e
isole-vpn rispettivamente).
La sorpresa è stata: "da Roma e Firenze non li vediamo, neanche li
pinghiamo".
La sopresa-bis: "quegli IP non li vediamo, ma tutto il resto di Cosenza si".
Praticamente il nodo che faceva girare la VPN non poteva comunicare in
VPN con Viterbo, Reggio, Pisa, Firenze, Roma, etc. Tutto il resto dei
nodi anche a 2 hop di distanza (Cerisanux, Capizzanux) invece sì.
Non aveva alcun senso, anche perché il tunnel funzionava correttamente,
e ricevevamo tutte le rotte in possesso delle altre isole.
Come al solito il diavolo è nei dettagli. Dopo prove infinite, ho
risolto con questa patch a /etc/babeld.conf

- redistribute local deny
+ redistribute local allow

Il deny annullava completamente l'effetto delle righe precedenti

redistribute ip 10.0.5.0/24 allow
redistribute ip 172.17.87.0/24 proto 157 allow
redistribute ip 10.87.0.0/16 proto 157 allow

facendo transitare sul tunnel le rotte calabresi in quelle sottoreti
(quindi Cerisano, Capizzanux, etc) TRANNE quelle direttamente collegate,
ovvero proprio... i link local: 172.17.87.2/24 e 10.0.5.6/24. Una volta
propagati anche questi chi prima non aveva modo di ritornarci i
pacchetti comincia a farlo e tutta Cosenza è accessibile da Roma,
Firenze, etc... più o meno.

Chi usa la nostra stessa VPN ci vede tranquillamente. Chi usa la
Norimberga, invece no. Sfortunatamente pare che il map server sia ancora
su Norimberga, e pertanto (visto che è una cosa che devono risolvere a
Roma, noi non possiamo far niente) forniamo a Nemesis un URL pubblico
dal quale ottenere la topologia NinuCS:
http://archive.hlcs.it/Ninux-Topology/topology.txt

DISASTRO.

I link vengono finalmente disegnati, ma:
* A Cosenza, tutti sono connessi direttamente con tutti.
* vengono disegnati dei link di 600+km che vanno dall'HPCC verso subnet
romane, pisane, fiorentine, ecc.

Qui insomma è dove ci accorgiamo che la topologia NinuCS è completamente
sballata.
Il primo punto è il problema della Client Isolation descritto da Spax
nell'altro thread. Un rapido test attivando la Client Isolation
ripristina immediatamente la topologia corretta all'interno di Cosenza.
Ma il problema dei link inesistenti verso le altre isole è ancora un bug
aperto.

A livello di rotte, la relazione tra NinuCS e resto di Ninux l'avevamo
impostata così:
* piuttosto che usare il plugin proto e inoltrare le rotte di tutte
Italia verso gli altri nodi di Cosenza, avevamo deciso per
un'aggregation: rohan annunciava il resto di Ninux come HNA4 ad essa
collegata

Hna4
{
    10.0.0.0    255.255.255.0    #HPCC
    10.11.12.13    255.255.255.255 #DNS
    # global ninux addresses
    10.0.0.0 255.0.0.0
    172.16.0.0 255.240.0.0
    192.168.0.0 255.255.0.0
}

Attualmente è impostata così. Il vantaggio è appunto la pulizia delle
tabelle di routing a Cosenza, lo svantaggio è che per scoprire che un
nodo è down devi far traffico e arrivare fino a Roma.

* Successivamente ho compilato il proto plugin, distinguendo le rotte
apprese con babel e olsr rispettivamente con ID 42 e 157. Una volta
attivato, Cerisanux, Capizzanux, etc, avevano tutta Italia nelle tabelle
di routing.

Il problema dei link infiniti non è scomparso con nessuna permutazione
dei due approcci (ammesso di non averne mancata qualcuna). Una volta
identificata la causa, se non ci saranno paletti di sorta dovuti ad
essa, decideremo assieme quale dei due approcci preferiamo.

Note a margine:
Nel processo di troubleshooting, ora godiamo di una configurazione
bleeding edge: sia babeld che olsrd sono compilati da git. Da verificare
che gli init.d funzionino anche così.
AirVPN durante alcuni test instradava pacchetti per Ninux su sè stessa.
Da tenere d'occhio anche questa.

Conclusioni:
Con Nemesis sono rimasto che, quando siamo pronti, lo ricontatteremo per
chiedergli di riaggiungere la OLSR URL di Cosenza al map server. Questo
può avvenire, chiaramente, solo una volta che sistemeremo la topologia
interna di NinuCS e la questione client isolation.
Una volta online la URL potremo debuggare i link chilometrici inopportuni.
Quando avremo risolto anche questa, perfezioneremo il tutto con un URL
pubblico definitivo per il fetching del topology.txt, rendendolo anche
autoaggiornante con un crontab.

Stefanauss.

[1] In realtà esamina topologie in generale, anche quelle di BATMAN.
Difatti le isole che lo usano fanno girare un plugin per BATMAN che
estrae la topologia in un formato identico al textinfo di OLSR, cosa che
garantisce la compatibilità col map server.

-------------- parte successiva --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://ml.ninux.org/pipermail/calabria/attachments/20140126/79c412cc/attachment-0001.pgp>