[Ninux-Calabria] simulazioni su routing a terra

[Vincenzo Pirrone]

Il 16/12/2013 03:36, Giuseppe De Marco ha scritto:
> Spax provo a mettere giù qualcosa, altrimenti poi mi scordo e quando
> siamo anche con Stefano e gli altri ci dimentichiamo le cose su cui
> confrontarci (e sto routing a terra non lo facciamo più).

+1000

>  
> Premesso che ho dovuto eseguire 
> root a OpenWrt:~# /etc/init.d/network restart && exit
> ogni volta che ho modificato la conf di switch, altrimenti non mi
> applica la configurazione, ovvero lui dice in un modo ma...

Con questo commento mi hai fatto risparmiare ore di smadonnamenti..

> 
> 
> Possiamo dire che:
> 
> 1. Su una porta taggata può comunicare solo la VLAN con medesimo ID,
> ovvero traffico VLAN corrispondente o un trunk.
> 2. Su una porta non taggata vengono accettati tutti i pacchetti
> "normali", ovvero traffico LAN classico
> 3. Switch di OpenWRT ogni tanto si incanta e fare test è molto noioso
> 4. L'ordine di mappatura porta fisica con porta logica è variabile ( se
> resetti e riavvi alle volte ti cambia... swconfig dev switch0 show )
> 5. CPU tagged se desiderassimo trattare vlan, CPU untagged se
> desideriamo trattare lan
> 6. CPU tagged con porta untagged se desiderassimo accettare traffico lan
> per trattarlo con l'interfaccia vlan (le antenne ubiquity)

Grazie avete dipanato quella grossa nebbia che avevo sul tagghing della
CPU!! Continuo ancora ad avere un po' di confusione in merito ma ne
parleremo con calma quando ci vediamo

> 
> Vorrei allineare alcune considerazioni con voi, tipo:
> 
> La VLAN1 è farlocca, nel momento in cui creiamo nuove VLAN, 192.168.1.1
> cessa di funzionare (indipendentemente dalla sua configurazione...
> eventuali test vostri ? ) e se si combinano danni basta spegnere,
> riaccendere e premere il tasto QSS appena il led status inizia ad
> illuminarsi. Premuto QSS si può accedere da telnet a 192.168.1.1 e
> risolvere il quasi brick.

Mi sa che la VLAN1 è utilizzata internamente, su AirOs per esempio non
te la fa proprio utilizzare.

> 
> Che altro dire?
> 
> 1. le antenne CPE in bridge le sistemiamo su porte VLAN untagged
> altrimenti le ubiquity non comunicano (a meno che non volessimo
> configurare VLAN su AirOS ma lo vedo sadico nei confronti dei nuovi utenti)

Quindi no vlan su CPE ho capito bene? Che indirizzi gli mettiamo? (come
suggerito in precedenza suggerisco di trattarli come host e metterli
nella 10.0.0.0)

> 2. la WAN la lasciamo in dhcp client per uplink verso rete locale utenza
> 3. ogni CPE antenna si collega su una porta untagged e le restanti porte
> vanno ad off ( chiedo conferma di questo )

Direi di si

> 4. il collegamento al bridge LAN/WLAN con indirizzo 192.168.1.1 viene
> garantito tramite wifi ( chiedo conferma perchè non l'ho testato )

Ora che ci penso fare in modo che la WLAN funzioni sia con indirizzo
ninux che con indirizzo privato potrebbe essere problematico, tu sai già
come fare? In ogni caso per me questa non è una priorità.

> 5. le porte restanti dal routing a terra dovremmo sistemarle come
> untagged per LAN
> 
> Completato questo schema (e di conseguenza il routing a terra perchè
> detto ciò OLSR non richiederà molto) potremo proseguire con lo sviluppo
> dei nostri unit test customizzati per core network.
> 
> due link toghi:
> http://coderazzi.net/howto/openwrt/tl841n/vlans.htm
> http://aming-blog.blogspot.it/2010/10/understanding-network-interfaces.html

Aggiungo anche questo
http://wiki.openwrt.org/doc/uci/network/switch


-- 
Vincenzo Pirrone
Twitter: @spax_arm
PGP Key ID: 5CF5047D

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