[Ninux-Calabria] routing a terra

[Stefano De Carlo]

Il 23/12/2013 20:32, Giuseppe De Marco ha scritto:
>
> Lasciando tutte le CPU delle VLAN come tagged, le porte restanti
> comunicano di default sulla VLAN0 come untagged e quì credo di capire
> che VLAN0 corrisponde ad eth0 (Vlan default, interfaccia che contiene
> sub-interfacce) che essendo bridgata in br-lan deve avere - per forza
> - la CPU untagged altrimenti blocca tutto.
>
> se noi untagghiamo una CPU di una VLAN dobbiamo essere coscienti che
> stiamo a sottrarre l'untagged alla VLAN default !!!
>

Ma questo lo hai testato personalmente, rimanendo chiuso fuori da un
router perché avevi untaggato la CPU?
Perché a me tutto il discorso non torna, big time.
Premetto che non ho avuto modo di giocare personalmente con i tag della
CPU, e adesso non ho nemmeno un OpenWRT tra le mani. Maledizione.

Che io sappia, non esiste "la" default VLAN. E default VLAN è anche un
termine abbastanza improprio, perché in teoria dovrebbe identificare la
VLAN di cui tutte le porte fanno parte a router appena disimballato. Che
come sappiamo, per gli OpenWRT, già è falso perché spesso lo switch è
già partizionato in almeno 2 VLAN, che spesso neanche partono da VID 0.

Da come ne parli ("comunicano sulla VLAN0 di default come untagged")
probabilmente ti riferisci alla native VLAN. Ma di native VLAN ogni
porta dello switch ha la sua. È quella identificata dalla voce pvid
nell'output di swconfig, e infatti puoi notare che anche a Verdebinario
di native VLAN ce ne sono 3 sparse tra le 5 porte.
Lo standard 802.1q parla di PVID e mai di Native VLAN, che è un termine
proprietario Cisco. Ma essenzialmente indicano la stessa cosa.
Vediamo un po', cosa significa Native VLAN? Lo standard dice che il PVID
(Port VLAN ID) è utilizzato "per associare un VLAN ID con i frame
ricevuti untagged e priority-tagged". Dimentichiamoci della priorità che
non ce ne frega qui. Più in basso riporto la citazione completa.
Cosa comporta la Native VLAN?
Che se un pacchetto viene ricevuto UNTAGGED, SU una porta, viene
inoltrato alla native VLAN configurata su quella porta.
Se un pacchetto deve essere inviato DA una porta && quel pacchetto ha un
tag VLAN che corrisponde alla native VLAN, allora il pacchetto viene
inviato UNTAGGED.
Dunque la native VLAN coinvolge sempre un membro untagged. Come
sappiamo, una porta può essere membro untagged di esattamente una sola
VLAN, altrimenti il traffico untagged ricevuto su questa porta non si
saprebbe di che VLAN deve far parte. Questo comporta, come evidente
dagli output di OpenWRT di VerdeBinario, che la native VLAN di una porta
è uguale/s'imposta al VLAN ID della (unica) VLAN di cui è membro untagged.

Tu hai fatto queste affermazioni
1) "le porte restanti comunicano di default sulla VLAN0 come untagged"
2) "essendo bridgata in br-lan deve avere - per forza - la CPU untagged
altrimenti blocca tutto."
3) "se noi untagghiamo una CPU di una VLAN dobbiamo essere coscienti che
stiamo a sottrarre l'untagged alla VLAN default !!!"

#1 non mi torna, perché la 4 è tagged su VLAN0, come può la
comunicazione avvenire untagged anche su quella?
#2 non mi torna, perché tu stesso nella config non hai CPU untagged, ma
non ti si è bloccato niente. Typo?
#3 non mi torna, perché se anche untaggassimo la CPU su VLAN1, la CPU su
VLAN0 rimane tagged. Non c'è conflitto, per le limitazioni di cui sopra.

L'unica giustificazione che riesco a trovare di queste conclusione è una
cosa che ho letto su 802.1q, dove dice che VID 0 è un valore che non
dovrebbe essere usato, e che in realtà i pacchetti con ID 0 sono intesi
specialmente come "untagged, appartenenti a qualsiasi sia la native VLAN"

Dallo standard: <http://www.dcs.gla.ac.uk/~lewis/teaching/802.1Q-2005.pdf>

> The null VLAN ID. Indicates that the tag header contains only priority
> information; no VLAN identifier is present in the frame. This VID
> value shall not be configured as a PVID

Mentre dall'Interwebz: <https://supportforums.cisco.com/thread/2121489>

> The VLAN ID 0 is used when a device needs to send priority-tagged
> frames but does not know in which particular VLAN it resides. The
> basic Ethernet frame does not have any priority field. The priority
> bits, also called CoS bits (Class of Service) are a part of 802.1Q
> VLAN tag. Therefore, a device needing to add a CoS marking to its
> frames has to insert a 802.1Q tag into each frame. However, even
> though this device may be capable of adding 802.1Q tags into its
> frames, it may not know in what VLAN it currently resides.
>
>  This is where the VLAN ID 0 comes in. A device that sends CoS-marked
> frames can insert a 802.1Q tag into a frame, use the VLAN ID 0 and set
> the CoS marking appropriately. When a VLAN-aware switch receives this
> frame, the VLAN ID 0 tells it: "Put the frame in the ordinary access
> VLAN of the port as if it was untagged, however, process the CoS field
> accordingly." In other words, the VLAN ID 0 represents the access - or
> the native - VLAN of the receiving port, whatever VLAN that might be.
>

Se veramente il fatto di usare VID0 significa che in realtà è tutto
untagged, CPU inclusa, allora in effetti untaggarla anche sulla VLAN è
un problemone grosso.
Ma è effettivamente così?
Nei tuoi output port4 è link down, non stai usando il trunk, quindi non
penso che tu abbia verificato se effettivamente ci passa tagged la sopra.
In generale: hai provato con mano quello che dici, mettendo CPU untagged
e verificando sfanculamenti?



>
> Se posti la sequenza di comandi possiamo scriptarlo in un wizard con
> semplici raw input bash.
>
> Considero che i comandi di UCI sono universali mentre i chip fanno più
> di testa loro. Che faccia dannare è cosa amara...

Avrò dato un 150 comandi, intervallati da parecchie bestemmie e
tentativi a vuoto. Non sono salvati da nessuna parte, OpenWRT non salva
la bash history tra le sessioni.
Anche lo fossero, come dici tu sono specifici del router, scriptarli
sarebbe un incubo.
Questo a meno che non selezioniamo "hardware certificato Ninux Calabria"
e utilizziamo sempre quello, nel qual caso possiamo testare
consistentemente i nostri scripting e finire addirittura per realizzare
dei software di configurazione user-friendly griffati Ninux.
Ma sono cose di la da venire.

>
> Alla pari di una scoperta copernicana, la direzione dello switch
> tagga/untagga i frames, scriviamolo sui muri.

Assolutamente, è un concetto fondamentale eppure completamente
non-ovvio, andrebbe messo come prima riga in tutti i doc.

Stefanauss.

-------------- parte successiva --------------
Un allegato non testuale è stato rimosso....
Nome:        signature.asc
Tipo:        application/pgp-signature
Dimensione:  836 bytes
Descrizione: OpenPGP digital signature
URL:         <http://ml.ninux.org/pipermail/calabria/attachments/20131224/579aa736/attachment-0001.sig>