[Ninux-Wireless] Bisognerebbe fare attenzione quando si lavora su gestione indirizzi

Alessio nolith a abisso.org
Ven 9 Maggio 2014 12:55:55 CEST


Ripondo per punti e alla fine propongo un metodo alternativo.

On 09/05/2014 10:42, Fabio Capriati wrote:
> Ieri sera abbiamo parlato della cosa e siamo venuti ad un po di linee guida.
> 
> * Algoritmo assegnazione IP Per l'isola Roma:
> 
>  1.  Calcolo la subnet con la regola del CAP.
>  2.  Se la Subnet non è libera allora vai al punto 4
>  3.  Se non c'è almeno una subnet nello spazio 10.CAP,0.0/16 allora vai
> al punto 4
>  4.  Prendo una subnet /24 nella prima subnet consecutiva libera (
> incrementando)
> 
> 
> In questo modo a Roma non occupiamo altre barre 16 della 10.0.0.0
> riempendo quelle già occupate e in questo modo ad una nuova isola si può
> allocare una /16 per il lato lan e /24 per il lato wireless.


Qui non ho capito una cosa.
Se dal CAP viene fuori una subnet libera al 100% la impegnate per Roma o
con subnet libera intendi una /24 all'interno di un /16 già in uso a Roma?


> Esempio Isola Trani:
> 
> 10.93.0.0/16 <http://10.93.0.0/16> : Subnet per Lan
> 172.16.93.0/24 <http://172.16.93.0/24>: Subnet backbone
> 
> Penso che  255 antenne e/o 255 Nodi siano sufficienti per una isola neonata.

Concordo, per esempio lo spazio preso per Firenze da questo punto di
vista è sovradimensionato. Non tanto per le LAN quanto per gli IP di
backbone.
Forse mi sbaglio ma mi pare che le altre isole (forse non tutte) abbiano
preso una /16 anche per la parte radio.

> 
> Rimane assodato che la gestione via wiki non scala .... metteremo su un
> servizio automatico di indirizzamento.

Concordo al 100% e si potrebbe pensare di mettere giù qualcosa durante
il battlemesh.

> 
> Per il futuro cerchiamo di non allocare "barre strane" ovvero:
> per un utente: /24
> per un'isola: /16
> quando si esaurisce se ne prende un'altra.
> 
> Ovviamente non è una decisione ma è una proposta ragionevole. Se ci
> vedete controindicazioni commentate, altrimenti evitate risposte tipo
> "OK", "Va bene", "+1".
> 
> I conflitti di IP tra Roma e Firenze sono stati risolti .... daje co sto
> peering!!
> 
> Bella


Proposta vagamente alternativa.

Mi piacerebbe provare a replicare il modello dei RIR (Regional Internet
Registries) che c'e in internet.
Il sistema garantirebbe coordinamento ed autonomia alle singole isole.

Sarei per creare dei gruppi di lavoro chiamati NAR (Ninux Address
Registries) uno per isola e poi avere un coordinamento intrasola più o
meno così:

* NAR    - Ninux Address Registry
* RONAR  - Roma Ninux Address Registry
* FINAR  - Firenze ...
* PINAR  - Pisa ...
* CANAR  - Calabria ...
* etc etc etc

Il primo gruppo è formato da membri misti e gestisce le allocazioni alle
singole isole, i vari NAR autonomamente possono disporre dello spazio
loro allocato come meglio preferiscono.

Si fa una ML per gruppo e via.
Io mi rendo disponibile sia come participazione per il NAR che per il FINAR

Contro:
* per avere gli IP per il proprio nodo bisogna chiedere che ci vengano
assegnati dal NAR di competenza
Pro:
* si evitano li errori di assegnamento perché nei NAR ci sono persone
che si dedicano alla questione con competenza
* chi vuole imparare come funzionano certe cose si può inserire nel
proprio NAR e approfondire tutte le tematiche
* un ottimo esercizio di cooperazione che di certo può scalare con la
crescita di NINUX






Maggiori informazioni sulla lista Wireless