[Ninux Nodi-prenestini] [Tech] Subnet senza criterio

Fri May 29 14:58:01 CEST 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciao a tutti.
Concordo sul fatto che bisogna risistemare l'intera isola Prenestini
in modo da togliere eventuale buchi tra una subnet e l'altra. Ho
inserito questa situazione su Draft per i punti all'ordine del giorno,
consultabile qui: https://draftin.com/documents/668530

Il 29/05/2015 14:02, Jarko ha scritto:
> Salve.
> 
> Io non ho la competenza per dire la mia su come vanno gestiti gli 
> indirizzi, vorrei solo ricordare a tutti quanti due particolari,
> uno di validità universale, e l'altro di validità locale:
> 
> - il cosiddetto "effetto cacca", cioè una cosa del tipo "più la
> rigiri, più puzza", che di solito suggerisce di NON toccare
> qualcosa se non è NECESSARIO toccarla
> 
> - fare SEMPRE le cose in modo COMPATIBILE con Ninux, in modo da
> non essere perennemente un'isola, ma una penisola, collegata (o
> collegabile) al resto della rete
> 
> 
> Detto questo, sono a disposizione per quello che c'è da fare, e con
> chi e come (frase criptica, lo so, m'è venuta così)...
> 
> ;-)
> 
> Rà
> 
> 
> 
> 
> Il 29/05/2015 10:14, IZØXQQ Alessandro ha scritto:
>> Gubi ho visto il foglio excel, letta la mail e vorrei
>> rassicurarti che l'importante è la correttezza di dati
>> esistenti.
>> 
>> Non è pensabile avere effettiva collimazione tra le varie
>> tipologie di indirizzo tant'è che a Roma si iniziò pensando di
>> associare la regola del CAP agli ottetti degli indirizzi IP [^]
>> ma con l'avvento delle nuove isole la stessa regola è da
>> considerarsi deprecata. Quindi l'importante è far collimare il 3°
>> ottetto della subnet radio (172.16.X.Y/16) con il 2° ottetto
>> della subnet LAN assegnata al nodo (10.X.Y.0/24) dove Y sarà il
>> primo progressivo libero assegnabile.
>> 
>> Riguardo invece l'indirizzamento IPv6 l'unico problema è relativo
>> al *non* uscire su internet, la comunicazione sulla rete è
>> comunque assicurata dal protocollo OLSR, l'importante (come per
>> gli indirizzi IPv4) è la correttezza dei dati censiti
>> relativamente a quelli esistenti.
>> 
>> 
>> 
>> 
>> [^] ATTENZIONE ALLA REGOLA DEL CAP Da un certo punto a Roma
>> abbiamo cominciato ad utilizzare la regola del CAP per assegnarci
>> gli indirizzi IP. Era un modo mnemonico per capire dove era il
>> nodo ed era più difficile fare casini. Quindi le coppie di reti
>> 10.CAP.yy.zz e 172.16.CAP.aa andavano sempre a braccetto. Con
>> l'avvento di isole Ninux, ovvero pezzi di reti non interconnesse
>> direttamente via wireless ma via VPN, come si fa? Per poter
>> agevolare l'interconnessione conviene non avere IP duplicati 
>> nella rete e cercare di mantenere lo spazio di indirizzamento
>> compatto per potersi scambiare le rotte facilmente. Per fare
>> questo nel breve - medio termine conviene che a Roma non
>> occupiamo nuovi ottetti <CAP> ma cerchiamo di riempire i tanti
>> buchi nello spazio di indirizzamento. Per agevolare la cosa si
>> può usare il CAP più vicino al proprio se quello che si vuole
>> utilizzare non è libero.
>> 
>> Esempio Concreto se sei di Roma Il mio CAP è 00049. Vado su
>> gestione indirizzi e vedo che la 10.49.0.0 e la 172.16.49.0 è
>> libera quindi secondo la regola del cap potrei prendermi
>> l'indirizzo, invece quella la lascio ad una possibile isola e
>> prendo un indirizzo del cap più vicino ovvero il 48. In questo
>> modo ho contribuito a compattare lo spazio di indirizzamento ed
>> ho dato la possibiltà ad un isola ninux di fare peering con le
>> altre.
>> 
>> Esempio Concreto sei nuova isola Trovo xx tale che 10.xx.0.0/16 e
>> 172.16.xx.0/24 sono reti libere e le impegno scrivendolo sia su
>> questa pagina che su indirizzi.frm.ninux.org
>> <http://indirizzi.frm.ninux.org>. 
>> -------------------------------
>> 
>> 
>> 
>> /-- / /IZØXQQ Alessandro/
>> 
>> Il giorno 29 maggio 2015 01:23, Alessandro Gubitosi
>> <gubi.ale at iod.io <mailto:gubi.ale at iod.io>> ha scritto:
>> 
>> Ciao a tutti, analizzando un po' la situazione nella pagina del
>> wiki GestionIndirizzi <http://wiki.ninux.org/GestioneIndirizzi>,
>> posso dire con certezza che NonSiCapisceUnCa...o :D Il fatto è
>> che gli indirizzi IP delle subnet (10.x) spesso non corrispondono
>> a quelli radio (172.16.x), per non parlare degli IPv6... È tutto
>> incasinato, molte subnet col tempo si sono liberate e ci sono dei
>> bei vuoti che creano confusione.
>> 
>> Allora dato che per adesso siamo scollegati via IPv6 e anche dal 
>> resto di Ninux che ne dite di mettere un po' chiarezza su questa 
>> faccenda?
>> 
>> Ho creato un documento excel condiviso: https://goo.gl/x7uU7m Vi
>> va di metterci insieme a ragionare su come riassegnare gli IP 
>> senza fare troppi casini? Chiunque ha il link può commentare, ma
>> se volete libero i permessi in scrittura. Vi va? Gubi
>> 
>> 
>> _______________________________________________ Nodi-prenestini
>> mailing list Nodi-prenestini at ml.ninux.org
>> <mailto:Nodi-prenestini at ml.ninux.org> 
>> http://ml.ninux.org/mailman/listinfo/nodi-prenestini
>> 
>> 
>> 
>> 
>> _______________________________________________ Nodi-prenestini
>> mailing list Nodi-prenestini at ml.ninux.org 
>> http://ml.ninux.org/mailman/listinfo/nodi-prenestini
> 
> 
> 
> 
> ---- ZE-Light e ZE-Pro: servizi zimbra per caselle con dominio
> email.it, per tutti i dettagli clicca qui 
> <http://posta.email.it/caselle-di-posta-z-email-it/?utm_campaign=email
_Zimbra_102014=main_footer>
>
>  Sponsor: Idee regalo classiche o alternative? Trova l'offerta
> migliore in un click Clicca qui
> <http://adv.email.it/cgi-bin/foclick.cgi?mid=13327&d=29-5>
> 
> 
> 
> _______________________________________________ Nodi-prenestini
> mailing list Nodi-prenestini at ml.ninux.org 
> http://ml.ninux.org/mailman/listinfo/nodi-prenestini
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVaGJVAAoJEGlzPO2QkpATbH8H/2582r2hjdHI2/DQInh5r0V4
fdHlCjdZaGKlUmg8yKyEgRsvpmHB4bfJss5kK8/p6NogKdCW7LWtRDROYwYDRwz9
JiEkTANgYyV8pXgtY6tk8uVlUjgf9tXH8elcMZE8uPlLwkm2b53FwOgzongrPDih
eltnnw8txg+7ha6tygOtGMszYW+cvDXPphvpQZpiE3y/BNV4HQCfjAzd0vib5GOK
PCe+PcMtN5OlKPLKZfgw69ehaEkbspwcHSiAn8WA9LY7UV3ck9mnBhJvZV+b7baD
shdeJSUdcfp3Lsdy6wSSuF13qGldJcqYOhVJCaDOl39BXR7IRfQJzSgaqVoQqYM=
=eOdj
-----END PGP SIGNATURE-----