[Ninux-Calabria] simulazioni su routing a terra

[Giuseppe De Marco]

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

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


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)

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.

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)
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 )
4. il collegamento al bridge LAN/WLAN con indirizzo 192.168.1.1 viene
garantito tramite wifi ( chiedo conferma perchè non l'ho testato )
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
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.ninux.org/pipermail/calabria/attachments/20131216/fe1dfa40/attachment-0001.html>