La Fibre

Télécom => Réseau => reseau TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: sim_v le 15 juin 2019 à 09:31:16

Titre: Test et intérêt du *VLAN* (sur les ports) à la maison sur un switch administré
Posté par: sim_v le 15 juin 2019 à 09:31:16
Pour beaucoup, l’option VLAN "port based" des switchs administrés n’aura pas d’intérêt.
Chez moi je l’utilise pour isoler le Wifi « invité » du reste du réseau.
Le port 1 est connecté à la BOX internet (je n'utilise pas son Wifi).
Le port 2 est un PC allumé en permanence. Je lui permets un l'accès l’interface du Wifi invité.
Le port 7 est le Wifi invité.

Du coup, les invités n’ont accès qu’à Internet (et au PC qui reste discret).
Les ordinateurs de la maison se voient entre eux et ignorent le wifi invité.

Les équipements communs sont sur les VLAN 1 & 2 (Box et PC).
Les équipements familiaux sont sur le VLAN 1.
Le Wifi invité uniquement sur le VLAN 2.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: renaud07 le 15 juin 2019 à 18:10:54
Simple curiosité : Tu mets quoi comme règles de firewall entre les 2 VLAN ? Blocage de toutes les IP sauf la box ?
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: sim_v le 17 juin 2019 à 11:06:57
Aucune règle de firewall car ce switch est intercalé entre la box et un ensemble d'autres équipement réseau ( schéma : https://lafibre.info/raccordement-maison/installation-de-sim_v/msg624851/#msg624851 ). Le switch ne travaille qu'au niveau 2, pas IP. Du coup si un équipement wifi-invité veut pinguer le NAS, le switch bloque car le NAS est sur le VLAN1 uniquement. Le ping ne remontera pas à la box et ne revient donc pas par la box. Un équipement connecté directement à la box est de facto sur les 2 VLAN.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: jdorel le 17 juin 2019 à 12:36:49
Si je suis ton schéma, ta box opérateur est directement connecté à la fois aux réseaux 'Wifi Invité' et local. Par défaut, ton réseau  'Wifi Invité' a donc accés à ton NAS, à moins d'avoir des règles de filtrages.

Essaie un ping depuis le réseau invité vers ton NAS (directement l'adresse IP, pas de nom de domaine). Si tu ne peux pas ping, c'est que tu as soit:
  - des règles de filtrage sr ta 'Box Opérateur'
  - un routeur en ton réseau invité et ta 'Box Opérateur'. Typiquement ton Access Point Wifi n'est pas qu'un AP, mais aussi un routeur (et rempli la fonction de DHCP).
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: Electrocut le 17 juin 2019 à 12:57:28
Ça me paraitrait logique que les communications "Réseau Invité" <-> NAS ne passent pas.
En effet, le switch ne transmettra par au NAS (VLAN 1) les requêtes ARP envoyée par le PC connecté au "Réseau invité" (VLAN 2).

En revanche, l'isolation entre VLAN1 et VLAN2 ne me parait pas suffisante, du fait que l'interface réseau de la Box est connectée aux 2 VLAN.

Exemple. Si depuis un équipement connecté au WiFi invité (VLAN2), j'applique la route ci-dessous :
- destination : <ip-NAS>
- masque : 255.255.255.255
- passerelle : <ip-BOX>

alors je peux envoyer du trafic au NAS, en utilisant la Box comme passerelle.

-> Il faudrait un sous-réseau IP différent par VLAN, et gérer des règles de pare-feu entre ces 2 sous-réseaux.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: sim_v le 17 juin 2019 à 14:00:00
J'essaierai le coup de forcer la passerelle vers la box.

De mémoire le wifi invité est en mode routeur et donc un sous-réseau du réseau principal mais je testerais aussi bien avec le mode bridge que le mode routeur.
Par défaut en tous cas, les invités ne voit pas les autres équipements du réseau (PC, imprimantes, équipement multimédia).
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: Thornhill le 17 juin 2019 à 14:58:49
Tu ne dis pas si tes équipements sont tous dans le même sous-réseau au niveau IP (si adressage statique), on suppose que oui.
 
Les broadcast Ethernet, y compris les requêtes ARP, ne devraient pas traverser les 2 Vlans, donc à priori pas de communication IP possible entre équipements des vlans 1 et 2, sauf à manipuler le masque de sous-réseau des 2 côtés.
Un équipement sur le vlan 2 pourrait se placer dans un sous-réseau plus petit pour envoyer des paquets aux IP sur les Vlan 1 en utilisant la box en routeur, mais il n'y aurait pas de chemin retour puisque les équipements du Vlan 1 le verraient comme une adresse du même sous-réseau donc n'utiliseraient pas un routage par la box pour le retour mais une requête ARP pour déterminer l'adresse MAC, sans jamais de réponse car domaine de broadcast différent vu du switch donc non propagé aux autres ports.

Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: sim_v le 17 juin 2019 à 15:24:57
Je valide ce soir mais le message de Thornhill correspond à l'idée que je me fais du fonctionnement de ces 2 VLAN.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: Thornhill le 17 juin 2019 à 15:29:43
Néanmoins, tu aurais peut-être intérêt à isoler réellement par un routeur/FW car en l'état un équipement mal intentionné sur le Vlan 2 a possibilité d'envoyer des paquets sur le Vlan1 (flood, dos, etc.)
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: sim_v le 17 juin 2019 à 15:40:52
Pas de souci car :
1- Le trafic broadcast est fortement limité sur le port 1/BOX (512 kb/s) (et 8 mbit/s sur les autres ports).
2- La borne est en 100 mbit/s ce qui limite naturellement l'usage de la bande passante.
3- Le Wifi invité est mis à disposition d'amis, c'est une maison, pas un hôtel.
4- Le Wifi invité est physiquement éteins si pas d'invité.
C'est ma fille qui s'en sert le plus pour les smartphones des copines.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: renaud07 le 17 juin 2019 à 16:25:09
Et comment tu fais pour récupérer le trafic des VLAN sur la LB ? Car il me se semble pas que celle-ci soit capable de le gérer côté LAN (pas possible de les tagguer).
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: sim_v le 17 juin 2019 à 16:28:15
C'est un VLAN basé sur les ports du switch, il n'y a -ici- pas d'information ajoutée dans les trames.
Embarquer le VLAN dans la trame c'est l'IEEE 8021Q qui n'est pas actif.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: renaud07 le 17 juin 2019 à 16:30:41
Ah, tu as donc 1 port pour chaque VLAN sur box ? Dans ce cas, ok. Ta description faisait penser le contraire.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: sim_v le 17 juin 2019 à 16:48:24
Non, je n'utilise qu'un port sur la BOX est il est identifié (et pas tagué au sens IEEE802.1q) au niveau du switch VLAN 1 et VLAN 2.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: renaud07 le 17 juin 2019 à 16:55:38
Donc ton switch est une exception à la règle, car théoriquement on ne peut avoir qu'un seul VLAN non taggué par port.

Par exemple, j'ai un D-link 1100 et si je veux mettre en untagged le VLAN 10 en plus du 1 (celui par défaut) sur n'importe quel port, c'est niet.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: Hugues le 17 juin 2019 à 16:56:43
Ouais donc tu ne sépares rien du tout :P
Il faut un routeur pour isoler des VLANs.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: sim_v le 17 juin 2019 à 17:14:07
Ouais donc tu ne sépares rien du tout :P

Et pourtant... ça marche bien.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: jdorel le 17 juin 2019 à 17:56:24
Je trouve cela étonnant que ton switch forward à la fois les trames du VLAN 1 et du VLAN 2 vers le port qui relie le switch au routeur. Pourrais-tu nous expliquer la configuration de ce port ?

Généralement, à moins de faire passer du traffic 802.1Q, un lien ne devrait pas voir passer du traffic issue ou destiné à plusieurs VLANs. Parmi les exceptions que je connais:
  - faire du port mirroring
  - faire des boucles niveaux 1, non repercutés au niveau 2
  - du traffic non taggé qui passe sur un lien censé être taggé 801.1Q

EDIT:
Après avoir revu l'image de ton premier post, il apparait que les ports 1 et 2 sont à la fois dans le VLAN 1 et dans le VLAN 2. A moins que ton switch èmette des trames taggés, cela paraît être une implèmentation défectueuse. Il est possible que ton switch èmette des trames taggés et que ton routeur ignore le tag.
Dans l'autre sens, si ton routeur èmet des trames non taggées, qui sont ensuite transmises aux 2 VLANs, cela paraît être une implèmentation incorrecte des VLANs par ton switch.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: kgersen le 17 juin 2019 à 18:20:47
Je trouve cela étonnant que ton switch forward à la fois les trames du VLAN 1 et du VLAN 2 vers le port qui relie le switch au routeur. Pourrais-tu nous expliquer la configuration de ce port ?

Généralement, à moins de faire passer du traffic 802.1Q, un lien ne devrait pas voir passer du traffic issue ou destiné à plusieurs VLANs. Parmi les exceptions que je connais:
  - faire du port mirroring
  - faire des boucles niveaux 1, non repercutés au niveau 2
  - du traffic non taggé qui passe sur un lien censé être taggé 801.1Q

EDIT:
Après avoir revu l'image de ton premier post, il apparait que les ports 1 et 2 sont à la fois dans le VLAN 1 et dans le VLAN 2. A moins que ton switch èmette des trames taggés, cela paraît être une implèmentation défectueuse. Il est possible que ton switch èmette des trames taggés et que ton routeur ignore le tag.
Dans l'autre sens, si ton routeur èmet des trames non taggées, qui sont ensuite transmises aux 2 VLANs, cela paraît être une implèmentation incorrecte des VLANs par ton switch.

C'est du 'port-based' vlan et pas du vlan taggé 802.1Q usuel. c'est pour cela que ca fonctionne. 

effectivement avec un switch "802.1Q pur" on ne pourrait faire cela.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: sim_v le 17 juin 2019 à 18:31:21
Pour comme indiqué en #11 et #13 je suis bien en VLAN selon les ports du switch, il n'y a pas de marquage des trames.

Les 2 réseaux sont bien isolés.
Même en forçant la passerelle par défaut.
Le wifi est bien en mode routeur ce qui me permet de mettre des restrictions : blocage de l'accès à l'interface d'administration du routeur wifi, de la livebox et du switch géré depuis le réseau invité (mais bon tout cela est aussi protégé par mot de passe).
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: jdorel le 17 juin 2019 à 22:32:08
C'est du 'port-based' vlan et pas du vlan taggé 802.1Q usuel. c'est pour cela que ca fonctionne.

Donc si je comprends bien, une trame issue du routeur se trouve sur deux VLANs différents ? Si c'est le cas, c'est vraiment moche. C'est un PVLAN groupé :)

Mais bon, ça remplis ses objectifs. Bon par contre t'as quand même un lien unidirectionnel entre tes deux réseaux (bidirectionnel si t'as une machine attaqué dans chaque réseau)
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: kgersen le 18 juin 2019 à 13:02:14
Donc si je comprends bien, une trame issue du routeur se trouve sur deux VLANs différents ? Si c'est le cas, c'est vraiment moche. C'est un PVLAN groupé :)

Mais bon, ça remplis ses objectifs. Bon par contre t'as quand même un lien unidirectionnel entre tes deux réseaux (bidirectionnel si t'as une machine attaqué dans chaque réseau)

En port-based y'a pas de vlan en entrer/sortie du switch: les paquets qui entrent/sortent du switch n'ont aucun marquage 802.1Q. tout se fait a l’intérieur du switch.

"une trame issue du routeur se trouve sur deux VLANs différents": oui c'est comme un trunk 802.1Q , en quoi c'est moche ?
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: sim_v le 18 juin 2019 à 13:05:02
Parce que c'est simple, presque compréhensible et 100% adapté à une usage personnel !
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: jdorel le 18 juin 2019 à 14:32:26
"une trame issue du routeur se trouve sur deux VLANs différents": oui c'est comme un trunk 802.1Q , en quoi c'est moche ?

Une trame sur un trunk 802.1Q n'est que sur un seul VLAN, même une trame non taggé sur un lien 802.1Q (ce qui ne devrait pas arriver sur une configuration propre) n'est présente que sur un seul VLAN (VLAN natif chez Cisco) du point de vue du switch.

Donc oui, c'est moche
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: Thornhill le 18 juin 2019 à 14:44:42
Le Port-based Vlan ne répondant à aucune norme, on peut partir du principe que l'implèmentation est libre, donc Netgear a fait un choix d'implèmentation pour le moins bizarre en autorisant deux vlans non taggués sur le même port.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: Nh3xus le 18 juin 2019 à 14:46:36
Préférez les standards IEEE :)
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: Thornhill le 18 juin 2019 à 14:51:55
Extrait de la doc :



VLAN Overview
Virtual LANs (VLANs) are made up of networked devices that are grouped logically into separate networks. You can group ports on a switch to create a virtual network made up of the devices connected to the ports.
Ports can be grouped in VLANs using port-based or 802.1Q criteria:
• Port-based VLANs. Assign ports to virtual networks. Ports with the same VLAN ID are placed in the same VLAN. This feature provides an easy way to partition a network into private subnetworks.
• 802.1Q VLANs. Create virtual networks using the IEEE 802.1Q standard. 802.1Q uses a VLAN tagging system to determine which VLAN an Ethernet frame belongs to

Assign Ports to Multiple Port-Based VLANs

A port-based VLAN configuration lets you assign ports on the switch to a VLAN. The number of VLANs is limited to the number of ports on the switch. In an advanced port-based VLAN configuration, you can assign a single port to multiple VLANs.
By default, all ports are members of VLAN 1.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: sim_v le 18 juin 2019 à 15:30:51
D-link semble le supporter également.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: renaud07 le 18 juin 2019 à 15:42:20
J'ai effectivement dit une connerie... J'ai bien une section port-based sur le mien et je peux aussi en assigner plusieurs au même port.

Par contre, c'est soit port-based, soit 802.1Q, on ne peut pas utiliser les 2 en même temps.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: Hugues le 18 juin 2019 à 16:05:58
Mais du coup, on est d'accord que ça fait juste un gros bridge entre les 3 VLANs ?
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: sim_v le 18 juin 2019 à 16:09:33
Dans mon cas ca permet avec un seul switch managé de séparer deux réseaux et de partager un accès internet entre les deux.
C'est quand même cool avec juste un switch à 30 EUR de faire cela (en plus des options sympa que propose un switch managé).
Donc oui, on peut parler de VLAN et trunk mais j'ai fait un post accessible sur un sujet qui l'est moins.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: Thornhill le 18 juin 2019 à 16:34:28
Mais du coup, on est d'accord que ça fait juste un gros bridge entre les 3 VLANs ?

Je ne pense pas qu'on puisse réellement parler de bridge dans la mesure où il y a bien séparation des broadcast domains : seul le port vers la box, appartenant au 2 Vlans, recevra les broadcast des 2 vlans (arp, etc.), il n'y aura pas diffusion d'un vlan à l'autre.
Ça reste néanmoins une config "atypique" (pour être poli) et qui doit probablement laisser passer par exemple des paquets IP du vlan invité vers l'autre, en paramétrant un sous-réseau plus petit sur l'équipement du vlan invité et en utilisant la box comme gateway.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: renaud07 le 18 juin 2019 à 18:01:27
Ça reste néanmoins une config "atypique" (pour être poli) et qui doit probablement laisser passer par exemple des paquets IP du vlan invité vers l'autre, en paramétrant un sous-réseau plus petit sur l'équipement du vlan invité et en utilisant la box comme gateway.

Je viens d'essayer et ça donne un résultat bizarre : Si je mets un /29 et que je tente de ping mon PC en 192.168.1.11/24, le routeur me renvoie un nexthop 192.168.1.11 et le ping ne passe pas.

C'est juste dû au fait que le PC croit que l'autre est sur le même sous-réseau ? Il faut donc modifier les masques de chaque côté ? Mais dans ce cas on ne peut pas avoir une IP de passerelle commune, si ? (Faut que je revoie les calculs de masque, moi  ::))
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: Thornhill le 18 juin 2019 à 18:26:55
Je viens d'essayer et ça donne un résultat bizarre : Si je mets un /29 et que je tente de ping mon PC en 192.168.1.11/24, le routeur me renvoie un nexthop 192.168.1.11 et le ping ne passe pas.

C'est juste dû au fait que le PC croit que l'autre est sur le même sous-réseau ? Il faut donc modifier les masques de chaque côté ? Mais dans ce cas on ne peut pas avoir une IP de passerelle commune, si ? (Faut que je revoie les calculs de masque  :P)

Le paquet ne peut passer que dans un sens donc le ping ne répondra jamais : l'équipement dans le Vlan cible considérant l'IP source dans le même sous réseau, il ne passera pas par le routeur mais tentera une requête ARP qui n'aboutira jamais (pas dans le même broadcast domain ethernet).
Cette "faille" ne peut servir qu'à faire du flood entrant.

Tu peux valider l'arrivée du paquet par un tcpdump sur la cible.

Modifier les masques de l'autre côté: non, pas de combinaison qui fonctionne dans les 2 sens avec la même @IP de routeur (en fonction du masque, tu exclus soit le routeur soit la cible du subnet : dans un cas tu ne provoques pas de routage pour joindre la cible, dans l'autre cas le routeur n'est pas dans le subnet).

Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: renaud07 le 18 juin 2019 à 18:38:10
Merci pour la confirmation, c'est ce que j'en avais conclu aussi.

Finalement, mis à part le flood, cette séparation un peu dégeu est pas si mal pour du domestique et ça a le mérite d'être simple à mettre en place. Même si ça serait mieux de tout faire dans les règles de l'art avec des subnet différents et firewall.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: kgersen le 18 juin 2019 à 22:08:54
Ce qui porte a confusion c'est le terme 'vlan' qui a un sens normalisé dans le monde pro. Ils auraient du appeler cela autrement que 'vlan' les 'puristes' auraient été contents  ;D

bref a l'arrivée c'est une solution simple, très efficace et largement suffisante pour un usage grand public.
Titre: Test et intérêt du *VLAN* (sur les ports) à la maison sur un switch administré
Posté par: Johannol le 19 juin 2019 à 09:53:25
C'est ça ;)

J'avais fais la même chose avec un TP-Link Manageable pour isoler le PC d'un ado "qui installe toute les merdes qui existe sur internet" et la partie saine du réseau à la maison (mon PC, le NAS, ...). Simple et efficace.
Titre: Test et intérêt du *VLAN* à la maison sur un switch administré
Posté par: Fuli10 le 20 juin 2019 à 11:43:23
Les broadcast Ethernet, y compris les requêtes ARP, ne devraient pas traverser les 2 Vlans, donc à priori pas de communication IP possible entre équipements des vlans 1 et 2,<...>
En théorie c'est . Après rien n’empêche de tomber sur des bugs ardus à trouver. Par exemple chez moi sur un AP unifi, j'avais 2 réseau wifi dont un sur un VLAN tagué. Mais manque de bol les paquets broadcast taggué étaient diffusés sur le réseau wifi du LAN non tagué. Ce qui était génial car sur les 2 réseau j'avais un routeur qui diffusait son prefix IPv6 via RA (donc broadcast) et les clients wifi qui recevaient les 2 RA. Au hasard si le prefix accepté était sur le réseau non tagué, l'IPv6 fonctionnait. Puis quand ça changeait pour l'autre prefix, je perdais l'IPv6 car le client croyait qu'il pouvait accéder au routeur derrière le LAN tagué, ce qui n'était pas du tout le cas. Bref j'avais un réseau qui marchouillait parfois, et parfois pas. Top !
Hâte qu'ubiquity sorte leur firmware officiel > 4.0.42 vu qu'ils semblent corriger ce qui semble être ce bug:
Citer
[UAP-IW] Fix link flapping and switch VLAN behavior.
[UAP-IW] Fix port/management VLAN provisioning.
Titre: Test et intérêt du *VLAN* (sur les ports) à la maison sur un switch administré
Posté par: Nh3xus le 20 juin 2019 à 13:11:09
Sur les vrais switches administrables tu peux filter les RA par ports / VLAN.

Chez Cisco, les mécanismes de sécurité relatifs à IPv6 au niveau L2 sont appellés "First Hop Security".

Dans ton cas, la fonction RA Guard serait intéressante :)

Titre: Test et intérêt du *VLAN* (sur les ports) à la maison sur un switch administré
Posté par: renaud07 le 20 juin 2019 à 17:05:02
WTF ? Je ne sais pas si j'ai un bug de switch ou de navigateur, mais une fois le port based désactivé je peux mettre plusieurs VLAN untagged pour le même port avec le 802.1Q alors que 2 jours avant ça ne marchait pas...

EDIT : apparemment c'est bien le switch, avec chrome je peux aussi en ajouter...
Titre: Test et intérêt du *VLAN* (sur les ports) à la maison sur un switch administré
Posté par: kgersen le 20 juin 2019 à 17:19:45
WTF ? Je ne sais pas si j'ai un bug de switch ou de navigateur, mais une fois le port based désactivé je peux mettre plusieurs VLAN untagged pour le même port avec le 802.1Q alors que 2 jours avant ça ne marchait pas...

Il perd la boule  :o

c'est pourtant tout a fait normal ...  ;D ce qui ne marche pas c'est plusieurs pvid par port. tu confond peut-etre les 2 ?

tagged vlan N = le port accepte en entrée et sortie le vlan N sans retirer l'etiquette du vlan des trames
untagged vlan N =le port accepte en entrée et sortie le vlan N en retirant l'etiquette du vlan des trames en sortie de ce port
pvid = l'etiquette a ajouter aux trames entrantes dans ce port qui n'ont pas d'etiquettes vlan

par nature, le pvid est unique par port (sinon le switch ne saurait dans quel vlan mettre les trames entrantes sans vlan).

dans le monde Cisco, le pvid n'a pas ce nom et c'est en fait le mode du port qui determine le pvid ("switchport mode access" ou "switchport mode trunk" puis le vlan correspondant au mode choisi).
Titre: Test et intérêt du *VLAN* (sur les ports) à la maison sur un switch administré
Posté par: renaud07 le 20 juin 2019 à 18:23:09
Pour moi, vu que le PVID est unique, il ne devrait y avoir que 1 VLAN untagged par port possible.

Admettons qu'on ai les VLAN 10 et 20 untag, comment tu fais pour communiquer avec le 20 si le PVID est à 10 ?

Ce genre de config sert donc pour les flux unidirectionnels genre vidéo surveillance ?

EDIT : Je n'avais pas la berlue:
Citer
Sur les switch où la notion n'apparaît pas, cela veut simplement dire que si un port est "untagged" dans le VLAN A alors son PVID est aussi égal à A et dans ce cas le switch n'acceptera pas qu'un port puisse être "untagged" pour plusieurs VLAN en même temps.

Enfin, j'aurais juré que ça ne fonctionnait pas la première fois (faut que je le reset pour voir).

Je viens aussi de trouver un cas où ça peut-être utile (c'est comme le port based sauf que c'est la solution "clean", je n'y aurais pas pensé) :

Citer
Solution 1 (qui ne marche pas sur tous les switch)
Il faut que le switch accepte d'avoir un port untagged pour plusieurs VLAN à la fois (sinon passer à la solution 2).
- Les ports 1 à 4 ont leur PVID à 2 et sont untagged pour les VLAN 2 et 3.
- Les ports 5 à 7 ont leur PVID à 1 et sont untagged pour les VLAN 1 et 3.
- le port 8 a sont PVID à 3 et est untagged pour les VLAN 1, 2 et 3

https://forum.hardware.fr/hfr/systemereseauxpro/Reseaux/ports-tagged-untagged-sujet_8055_1.htm

Le même genre d’exemple qu'ici avec 2 VLAN et une LB.



Titre: Test et intérêt du *VLAN* (sur les ports) à la maison sur un switch administré
Posté par: Optix le 20 juin 2019 à 22:14:32
Il est tout à fait possible d'avoir plusieurs VLAN untagged sur un même port. L'untag efface l'étiquette en sortie de port.

Par contre, en entrée, seul le PVID par défaut sera traité.

Exemple d'utilisation : pour mon PC, j'ai un VLAN pour la data (en PVID), et un VLAN pour l'IPTV multicast, untag sur le même port que la data. Mes flux repartent dans le VLAN data, mais pas dans l'infra TV.
Titre: Test et intérêt du *VLAN* (sur les ports) à la maison sur un switch administré
Posté par: renaud07 le 08 mars 2021 à 04:40:04
Je viens de retomber sur ce sujet, en cherchant à me remémorer ces histoires de PVID/untag car j'ai remis en service mon téléphone SIP qui était tombé en rade d'alim y'a plusieurs mois et entre temps j'avais du réinitialiser mon switch et donc refaire la configuration.

Cette fois il se passe ce que j'avais constaté la première fois, à savoir impossible de définir plusieurs VLAN untag sur le même port, le switch m'envoie bouler (il devait donc bien y avoir un bug en passant du port based au 802.1Q).

D'autre part, j'ai remarqué que le port où est branché le tel (qui ne tag pas les trames) qu'il soit untag ou tag, le trafic passe quand même. Normal ?
Titre: Test et intérêt du *VLAN* (sur les ports) à la maison sur un switch administré
Posté par: doctorrock le 09 mars 2021 à 19:32:20
Je viens de retomber sur ce sujet, en cherchant à me remémorer ces histoires de PVID/untag car j'ai remis en service mon téléphone SIP qui était tombé en rade d'alim y'a plusieurs mois et entre temps j'avais du réinitialiser mon switch et donc refaire la configuration.

Cette fois il se passe ce que j'avais constaté la première fois, à savoir impossible de définir plusieurs VLAN untag sur le même port, le switch m'envoie bouler (il devait donc bien y avoir un bug en passant du port based au 802.1Q).

D'autre part, j'ai remarqué que le port où est branché le tel (qui ne tag pas les trames) qu'il soit untag ou tag, le trafic passe quand même. Normal ?

Ingress filtering pas activé ?
Titre: Test et intérêt du *VLAN* (sur les ports) à la maison sur un switch administré
Posté par: renaud07 le 11 mars 2021 à 02:10:01
Merci pour la piste, mais mon switch ne possède pas ce genre de réglage...