[Ninux-Calabria] NODO LAPPANUX

[Stefano De Carlo]

Il 01/06/2014 12:05, Giuseppe De Marco ha scritto:
>
> Non ti preoccupare che a Lappano si torna, se continui a leggere capisci.
>
>>>> Stefanauss.
>>> da dove lo fai il ping ?
>> Ndo cojo cojo.
>> In basso allegata trovi la passeggiata che mi son fatto.
>> La parte interessante è il fattore 8 nei riassunti ICMP, tipo:
> la risposta corretta è: sui router ninux, dalle workstation non
> abbiamo di questi problemi.

Chiaro che no. I pacchetti dalle workstation generano con src 10.87.x/24.
172.17.255.255 in quanto pacchetto di broadcast non è
forwardabile/forwardato.
Il problema di overhead e broadcasting però rimane.

>  Una nota:
>
> """
> ping will report duplicate and damaged packets. Duplicate packets
> should never occur, and seem to be caused by inappropriate link-level
> retransmissions. Duplicates may occur in many situations and are
> rarely (if ever) a good sign, although the presence of low levels of
> duplicates may not always be cause for alarm.
> """

"Low levels" mi sa che è inteso come gli occasionali duplicati.
Un fattore 8 in crescita con la rete "is rarely if ever a good sign" :)

> ri-postiamo il link:
> https://docs.google.com/document/d/1tEp4rFNDis4RAwwo4wwg6xDMdqeJKAi8FVYh_FsPEdk/edit#heading=h.e9ahlghv43rd
>
> che ognuno lo facesse,

Yes.
Per chi si approcciasse per la prima alla documentazione, se notate
imprecisioni o punti poco chiari fatecelo sapere. Li discutiamo e
integriamo.

>  non di certo posso configurare e installare i
> nodi per come ho fatto e sto facendo finora perchè c'è bisogno di
> singole volontà/responsabilità, e so che condividi. Scappare a
> Lappano, ieri, è stato un miracolo per come sono incasinato
> ultimamente ma prima di agosto spero di calendarizzare tutti insieme
> gli interventi migratori con tunnel e vlan.
>
> Se giovanni non avesse fatto le configurazioni a casa sua sarei stato
> in difficoltà coi tempi.
> Alla stessa maniera un contributo avremmo potuto darlo tutti in tal
> senso, parlando di supernodo, ma avremo tempo e modo.

Per chiarire: non è una precisa responsabilità di qualcuno. È
semplicemente un altro elemento della todo list. Chi si trova, lo prende
e lo spunta.
Nessuno è rimasto con le mani in mano :)

> Richiamo comunque ad un confronto sulla configurazione in bridge senza
> IP per il supernodo.
>
> Il router ha un ip e, ad esempio, 3 porte untaggate con questo 172.
> Le CPE sono tutte senza IP.
>
> Ogni pacchetto 172, se le CPE non avessero IP, verrebbe inviato a
> tutte le CPE, quindi propagato a sud anche quando la station di
> riferimento sarebbe a nord e viceversa, ovvero si perderebbe il
> vantaggio della configurazione a cella, ogni CPE invierebbe la
> medesima informazione perchè il router la scriverebbe su tutte e tre
> le porte, e non solo su quella dove l'hop del 172 corretto risiede.

Invece la scrive solo lì.
"Ogni pacchetto 172", i casi d'interesse sono che o si tratta di un
pacchetto broadcast o unicast.
OLSR aggiunge una /32 sulla precisa interfaccia-porta che conduce
"all'hop del 172 corretto".

Se il pacchetto, come è nella quasi totalità dei casi, è unicast
l'informazione non viene replicata su tutte e tre le porte, ma solo su
quella che conduce "all'hop dove risiede il 172 corretto", grazie alla
tabella di routing.
E questo succede a prescindere dal fatto che la CPE abbia IP sul bridge
oppure no.

Se il pacchetto è broadcast, come da intenzioni, l'informazione viene
replicata su tutte le interfacce 172.17.
Da lì arriva ovunque, se non viene segmentato. Un esempio è Cerisano,
dove le due antenne fanno parte della stessa VLAN e quindi il broadcast
arriva fino a Rovito (dove c'è la stessa situazione), e da lì a Cornite.
E questo succede a prescindere dal fatto che la CPE abbia IP sul bridge
oppure no.
Ma in questo caso, essendoci l'IP sul bridge, il broadcast viene
processato a Layer 3 anche sulla CPE. Da qui DUPs e overhead.

> Probabilmente STP può darci una mano in tal senso ma c'è da stare
> attenti a STP che può dare non poche rogne.

Non penso ci serva STP. Con Client Isolation e VLAN/GR stiamo creando
(creeremo) tantissimi domini di broadcast point-to-point.
Le chiacchiere (di OLSR) stanno a zero.
Just perfect :)

> Andiamo alle note tecniche
>
> da capizzanux, mentre sono associato a newspig, nel sitesurvey appare:
> 00:03:7F:BE:F6:9E sud.lappano.calabria.ninux.org  NONE-82 / -915.64128
>
> infatti io sono a cosenza sud e mi illumina lappano_sud (TP-link).
>
> Nota:
> quando sono associato ad un AP oppure sono station senza essid-lock,
> il segnale dei surveys è sempre attenuato di parecchio ( notato
> durante diversi sopralluoghi, solo dopo esserci associati abbiamo una
> stima reale, solitamente +6 - 9db di guadagno ), quindi il test va
> fatto con un associazione concreta :)

Ieri ho avuto una situazione simile!
Mi sa che più è basso il segnale meno c'è discrepanza. Infatti per un
-86 (associato) il SS dava -89 :)

> Voi in HL dovreste vedere:
> nord.lappano.calabria.ninux.org (la rocket)

Come detto in altra mail, purtroppo no.

> Note sulla rocket:
> E' difettosa, abbiamo già concordato con vilgio che acquistare robetta
> di seconda mano - da persone non di fiducia - significa buttare soldi.

+1000 :(

> Noi ieri abbiamo fatto il miracolo perchè siamo andati lì alle 17:30
> (!)

Minchia, senza la cena a San Marco Argentano avremmo fatto in tempo a
venire con Luca :)

> Abbiamo la rocket in prova e se fà le bizze la dovremo sostituire.

In Hacklab abbiamo 3 Rocket.
Se Vilgio vuole può prenderne una di queste, e per il pagamento anche in
comode rate a interessi comunitari.

> Il super nodo senza airMAX è cmq spettacolare, darà accesso a iw8rmn :)
> dobbiamo anche decidere chi fra noi linkerà dentro Lappano, mi sà che
> il meglio titolato sarò io a Sud e brodolini a Nord, che ne pensate ?
> :)

Lo capiremo meglio quando lo vedremo nei SS e potremo fare prove di
associazione :)
Ma è vero che Brodolini potrebbe essere il tramite tra i due supernodi.

Ma il tuo Capizzanux-AP 172.17.87.11 c'è ancora? Non lo pingo più.

Stefanauss.

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