<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
><br>
> se noi untagghiamo una CPU di una VLAN dobbiamo essere coscienti che<br>
> stiamo a sottrarre l'untagged alla VLAN default !!!<br>
><br>
<br>
Ma questo lo hai testato personalmente, rimanendo chiuso fuori da un<br>
router perché avevi untaggato la CPU?<br>
Perché a me tutto il discorso non torna, big time.<br>
Premetto che non ho avuto modo di giocare personalmente con i tag della<br>
CPU, e adesso non ho nemmeno un OpenWRT tra le mani. Maledizione.<br></blockquote><div><br></div><div>Certo, se ho ad es. VLAN 1 ( e/o VLAN2 ) e piazzo una CPU come untagged vengon sbattuto fuori.</div><div>Dipende dal chip ? Secondo me dovresti testarlo su un router diverso dal 740N.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Che io sappia, non esiste "la" default VLAN. E default VLAN è anche un<br>
termine abbastanza improprio, perché in teoria dovrebbe identificare la<br>
VLAN di cui tutte le porte fanno parte a router appena disimballato. Che<br>
come sappiamo, per gli OpenWRT, già è falso perché spesso lo switch è<br>
già partizionato in almeno 2 VLAN, che spesso neanche partono da VID 0.<br>
<br></blockquote><div><br></div><div>l'swconfig dev eth0 show che ho pubblicato espone i vid 0</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Da come ne parli ("comunicano sulla VLAN0 di default come untagged")<br>
probabilmente ti riferisci alla native VLAN. Ma di native VLAN ogni<br>
porta dello switch ha la sua. </blockquote><div><br></div><div>di default ha la vlan0, se poi la specifichi in network è diverso.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
È quella identificata dalla voce pvid<br>
nell'output di swconfig, e infatti puoi notare che anche a Verdebinario<br>
di native VLAN ce ne sono 3 sparse tra le 5 porte.<br></blockquote><div><br></div><div>al momento due:</div><div>172 e 192, la 10 è su br-lan.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Lo standard 802.1q parla di PVID e mai di Native VLAN, che è un termine<br>
proprietario Cisco. Ma essenzialmente indicano la stessa cosa.<br>
Vediamo un po', cosa significa Native VLAN? Lo standard dice che il PVID<br>
(Port VLAN ID) è utilizzato "per associare un VLAN ID con i frame<br>
ricevuti untagged e priority-tagged". Dimentichiamoci della priorità che<br>
non ce ne frega qui. Più in basso riporto la citazione completa.<br>
Cosa comporta la Native VLAN?<br>
Che se un pacchetto viene ricevuto UNTAGGED, SU una porta, viene<br>
inoltrato alla native VLAN configurata su quella porta.<br>
Se un pacchetto deve essere inviato DA una porta && quel pacchetto ha un<br>
tag VLAN che corrisponde alla native VLAN, allora il pacchetto viene<br>
inviato UNTAGGED.<br>
Dunque la native VLAN coinvolge sempre un membro untagged. Come<br>
sappiamo, una porta può essere membro untagged di esattamente una sola<br>
VLAN, altrimenti il traffico untagged ricevuto su questa porta non si<br>
saprebbe di che VLAN deve far parte. Questo comporta, come evidente<br>
dagli output di OpenWRT di VerdeBinario, che la native VLAN di una porta<br>
è uguale/s'imposta al VLAN ID della (unica) VLAN di cui è membro untagged.<br><br>
#1 non mi torna, perché la 4 è tagged su VLAN0, come può la<br>
comunicazione avvenire untagged anche su quella?<br></blockquote><div><br></div><div>avviene sulla 3 e non sulla 4 dove ho sistemato vlan tagged. La 3 è tutta off e comunica su br-lan.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
#2 non mi torna, perché tu stesso nella config non hai CPU untagged, ma<br>
non ti si è bloccato niente. Typo?<br></blockquote><div><br></div><div>Proprio perchè non ho CPU untagged mi funziona tutto, hai inteso male.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
#3 non mi torna, perché se anche untaggassimo la CPU su VLAN1, la CPU su<br>
VLAN0 rimane tagged. Non c'è conflitto, per le limitazioni di cui sopra.<br></blockquote><div><br></div><div>Questo non mi torna e dato che sono rimasto sbattuto fuori untaggando le CPU poi magari faremo un confronto specifico su questo aspetto, con un paio di router tra le mani.</div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
L'unica giustificazione che riesco a trovare di queste conclusione è una<br>
cosa che ho letto su 802.1q, dove dice che VID 0 è un valore che non<br>
dovrebbe essere usato, e che in realtà i pacchetti con ID 0 sono intesi<br>
specialmente come "untagged, appartenenti a qualsiasi sia la native VLAN"<br></blockquote><div><br></div><div>esatto, quello che dico. Il discorso è che la CPU untagged è esclusiva.</div><div>E l'unica spiegazione che sono riuscito, per adesso, a dare è che untaggando una CPU entri in conflitto con la vlan0.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> This is where the VLAN ID 0 comes in. A device that sends CoS-marked<br>
> frames can insert a 802.1Q tag into a frame, use the VLAN ID 0 and set<br>
> the CoS marking appropriately. When a VLAN-aware switch receives this<br>
> frame, the VLAN ID 0 tells it: "Put the frame in the ordinary access<br>
> VLAN of the port as if it was untagged, however, process the CoS field<br>
> accordingly." In other words, the VLAN ID 0 represents the access - or<br>
> the native - VLAN of the receiving port, whatever VLAN that might be.<br>
><br>
<br>
Se veramente il fatto di usare VID0 significa che in realtà è tutto<br>
untagged, CPU inclusa, allora in effetti untaggarla anche sulla VLAN è<br>
un problemone grosso.<br>
Ma è effettivamente così?<br>
Nei tuoi output port4 è link down, non stai usando il trunk, quindi non<br>
penso che tu abbia verificato se effettivamente ci passa tagged la sopra.<br></blockquote><div><br></div><div>Hahahha, vabè, il cavo è scollegato :) il trunking sulla 4 funziona.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In generale: hai provato con mano quello che dici, mettendo CPU untagged<br>
e verificando sfanculamenti?<br></blockquote><div><br></div><div>e sì. Solo sul 740N, con i limiti che bug e sciocchezze di LUCI impongono.</div><div>Possiamo rifare i test e giungere a conclusioni condivise.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Questo a meno che non selezioniamo "hardware certificato Ninux Calabria"<br>
e utilizziamo sempre quello, nel qual caso possiamo testare<br>
consistentemente i nostri scripting e finire addirittura per realizzare<br>
dei software di configurazione user-friendly griffati Ninux.<br>
Ma sono cose di la da venire.<br></blockquote><div><br></div><div>se solo ci fosse abbastanza spazio per python minimal :)</div><div><br></div></div></div></div>