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

Giuseppe De Marco demarcog83 a gmail.com
Dom 26 Gen 2014 11:33:06 UTC


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

caruccio, ok.



>
> 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.
>

... però isola tutti i nodi sprovvisti di OLSR, tutti i nodi in test. AL
cosa imbarazzante è che la client isolation è stata attivata mentre la
sezione ARI Cosenza stava facendo il contest internazionale sfruttando la
connettività offerta da Verde Binario.
Praticamente gli abbiamo staccato internet per circa mezz'ora mentre questi
partecipavano ad un contest mondiale !
Vabè, serve da esperienza ma non dimentichiamoci le nostre responsabilità
nei confronti della rete.


> Ma il problema dei link inesistenti verso le altre isole è ancora un bug
> aperto.
>

Ah però !


>
> 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
> }
>

Perchè Rohan annuncia 192.168.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.
>

Male minore, non di certo "andiamo" a roma tutti i giorni :)


>
> * 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.
>

Forse sarebbe più umano avere giusto i gateway verso classi di rete a 16
bit e non 3mila reti a 24bit.


>
> 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.
>



> AirVPN durante alcuni test instradava pacchetti per Ninux su sè stessa.
> Da tenere d'occhio anche questa.
>

Temo che AirVPN sia un servizio esclusivo di Hacklab per pochi eletti
pertanto se sene parla in lista sarebbe il caso di condividerlo in rete,
altrimenti meglio non parlarne proprio, suona mortificante.


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.
>

Idea: non possiamo fare un parse del file prodotto da OLSR in maniera tale
da filtrare la topologia così da fornirla al mapserver come desideriamo ?
Non dovremmo fare altro che rimuovere i duplicati e forzare quello che
vogliamo esportare all'interno del contenuto del file. Se è solo un file di
testo possiamo farci fuochi d'artificio.

La rete deve cambiare intorno al software romano, oppure vogliamo fare
qualcosa di innovativo ?
Se possibile condividiamo i due file esportati, quello "sbagliato" e quello
"ideale", perlomeno fammici dare n'occhiata.


> 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
>

Se lo dobbiamo autoaggiornare con crontab lo possiamo anche auto
"processare" come desideriamo noi, senza forzare la client isolation e
imporre OLSR a tutti i nodi, anche quelli foglia o dei quali il mesh non
interessa, perlomeno in questa prima loro fase.

Se mi condividete i due file scrivo la procedura in tempi record,
consideratelo già fatto.

Stè complimenti per il report, vai forte.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.ninux.org/pipermail/calabria/attachments/20140126/f994a083/attachment.htm>


Maggiori informazioni sulla lista Calabria