[Ninux-Calabria] simulazioni su routing a terra

Giuseppe De Marco demarcog83 a gmail.com
Lun 16 Dic 2013 15:40:42 UTC


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

Si, LUCI ti dice "Save and Apply" e tu lanci il router dalla finestra :)

> 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

Guarda domani in HPCC porto un tplink per completare i test e ultimare il
nostro "VLAN Comprehension".
Purtroppo da quello che si vede on-line, le VLAN sono state documentate un
pò a macchia di leopardo, la causa è una standardizzazione tardiva e
postuma alla loro introduzione sul mercato, la loro realtà è caratterizzata
da implementazioni diverse per produttori hardware anche se, da quanto ho
letto, pare che dal 2010 le cose stiano migliorando.

In realtà stamattina non ho avuto tempo per completare tutti i casi, specie
quelli riguardanti la porta CPU tagged/untagged (la 5 per intenderci).
Vorrei completare di osservare le differenze operazionali sostanziali in
maniera da sentirmi pratico e risoluto nei possibili casi di uso.

Purtroppo con le VLAN è molto facile fare confusione, specie perchè
documentazione diversa fà riferimento ad hardware/nomenclature del panorama
proprietario (Cisco e HP perlopiù), pertanto invito a ogni
hacker/informatico/tecnico di non sentirti in imbarazzo se mentre le studia
avverte un pò di confusione, condividiamo anche questa e non solo.

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

Ormai le VLAN stanno prendendo sempre più piede, significa per noi due cose:

1. Non possiamo permetterci più di ignorarle o sottoutilizzarle perché
rispondono alla maggiorparte dei problemi.
2. i produttori hardware non mettono più interfacce fisiche separate ma
mettono una unica interfaccia divisa a livello logico per mezzo di CHIP che
implementano 802.1Q.

Pertanto la VLAN1 è il modo semplice che hanno di separare la WAN e la LAN
(tipo VLAN0 e VLAN1), dove VLAN0 è la VLAN default.

Sui misteri della VLAN1 di openWRT, invece, penso che appena completerò i
test potremo fare una pubblicazione come ninux calabria e mettere nero su
bianco anche per la salute mentale dei nostri amici vicini e lontani.

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

Secondo me la sperimentazione deve continuare, con questa domanda mi sento
un pò cadere dal pero perché sto lasciando molte posizioni aperte.
Noi possiamo fare una vlan e untaggare una porta.
Nota bene che untaggare, da quello che ho appuranto anche incrociando le
esperienze su GNU/Linux classico, altro non è che bridgare una vlan tagged
con la l'ethernet della porta. Questo modo è quello che usano per unificare
il livello logico del link. Infatti la porta può essere untaggata solo una
volta per uso esclusivo di una singola VLAN, mentre N VLAN possono taggarsi
N porte senza problemi.

Avere N VLAN con la medesima porta tagged "equivale" a fare VLAN trunking
verso un altro dispositivo.

Per dare una parvenza, insufficiente, alla tua domanda ti posso dire la
prima cosa che farò con il mio caso di uso pratico:

1. Creo una VLAN, che è la rete delle antenne, e a queste associo due porte
untagged con CPU tagged.
2. La WAN è untagged e rimane così com'è per uplink verso rete privata
(eventualmente cambiare regole di firewall openWRT sulla WAN per consetire
l'amministrazione di openWRT dall'utente normale via wan)
3. lascio una porta per il VLAN trunking nell'eventualità di dover
aggiungere antenne e non avere porte disponibili, se sorgesse la necessità
grazie al trunking potremmo aggiungere un altro dispositivo, gli tagghiamo
le VLAN sulla porta di trunking e come risultato ho esteso le porte fisiche
unendo due switch su 802.1Q)
4. configuro le antenne come 172.17.87.x/16 come retrocompatibilità
(cerchiamo di mantenere le cose "umane" per il prossimo e anche per la
nostra salute mentale)

Le antenne comunicano come se fossero in LAN perchè la porta è untagged,
alla CPU vengono taggate pertanto da una porta qualsiasi possono essere
trunkate da/verso un altro dispositivo fisico.
Se invece penso alla tua proposta la vedo più consona alle esigenze  del
ptp, così da dividere tramite tag 802.1Q il link del ptp dal link verso
l'AP.
In questo caso possiamo creare due VLAN, con la stessa rete ma divise a
livello logico, sulla medesima porta !!!!

questo introduce un profilo diverso, perchè le ptp potremmo taggarle in
openWRT a patto di comunicare via VLAN taggata su airOS. E questo per
l'uomo qualsiasi è un dito nel cu*o.

Non prendiamo queste mie congetture come definitive, ripeto, la
sperimentazione deve proseguire, magari vagliando e ricontrollando (stile
checklist) quanto proviamo a formalizzare quì in lista.
Ultima premessa: OpenWRT ogni tanto fà dannare, take it easy.
Alcune combinazioni di CPU tagged con porte untagged causano loop interni,
devo riordinare i tests e formulare un metodo e una risposta a questo.


> 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à.
Possiamo farlo solo se taggassimo la porta, altrimenti la porta WAN è
untagged per comunicare con dispositivi generici.

> http://wiki.openwrt.org/doc/uci/network/switch
Una cosa mi ha un pò stupito, veramente poca documentazione buona.
Casi di uso ed esempi quasi inesistenti.

Le VLAN non sono difficili, se avessimo avuto una documentazione migliore
non staremmo quì ad osservare attoniti i tplink in loop.
In rete si trovano solo pubblicazioni simili alle congetture esposte dal
sottoscritto e nel più dei casi producono solo confusione, specie perchè
hardware diverso ha vlan e interfacce sulla versione di openWRT
discordanti, e diventa un gioco al massacro, specie quando introducono
terminologie ereditate da prodotti proprietari.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.ninux.org/pipermail/calabria/attachments/20131216/d7dab036/attachment-0001.htm>


Maggiori informazioni sulla lista Calabria