Discussion :

[boboss123]

Pour l'explication sur le fonctionnement d'un switch (layer-2... donc ne travaille que sur les adresses MAC, les adresses IP ne sont pas analysées), relie bien ce lien que je t'avais indiqué : https://reussirsonccna.fr/switch/

Il est indiqué :

la trame arrive sur le port E0 du switch SW1

le switch extrait l’adresse MAC source et l’insère dans sa table (cf schéma). Maintenant le switch sait que pour joindre cette adresse MAC (AAAA.AAAA.AAAA), il doit commuter les trames vers le port E0. Cette information lui servira donc pour le retour de la trame.
puis le switch extrait l’adresse MAC destination (DDDD.DDDD.DDDD) et la compare à sa table : aucune entrée trouvée donc ne sachant pas où envoyer la trame, il la diffuse sur tous les ports excpetés le port de réception E0.

Un switch n'interroge aucun équipement, il ne fait qu'écouter les trames : il enregistre les adresses MAC source des paquets entrants. Ensuite, il envoie les paquets sur le port où l'adresse MAC destination a été précédemment enregistrée. Si l'adresse MAC destination n'a pas été enregistrée, le paquet est broadcasté sur tous les ports.
La table d'un d'adresse MAC maintenant par un switch est la suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
+-------------------+-------------+------------+
|    @MAC source    | port source | Aging-time |
+-------------------+-------------+------------+
| 00:01:02:03:04:05 |     1       |    32 sec  |
| 00:01:02:03:AA:AA |     5       |    66 sec  |
+-------------------+-------------+------------+

=> A chaque fois qu'un paquet entre sur un port, le aging-time est réinitialisé pour l'adresse MAC source du paquet (ex : 120 sec). Tous les seconde, le aging-time de toutes les entrées en décrémenté : si un des aging-time arrive à 0, l'entrée est supprimée de la table.


Pour la table des VLAN pour un switch layer2 manageable, elle ressmble a ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
+------+----------+----------+-----------+-----------+----------+
| VLAN |   port 1 |   port 2 |   port 3  |   port 4  |   port 5 |
+------+----------+----------+-----------+-----------+----------+
|   1  | Tagged   | Untagged | NotMember | NotMember | Untagged |
|  ... |    ...   |   ...    |    ...    |   ....    |    ...   |
| 4095 | Untagged | Tagged   | NotMember | NotMember | Untagged |
+------+----------+----------+-----------+-----------+----------+

=> pour chaque VLAN, la configuration des ports est définie. Un port peut avoir trois états : untagged, tagged, notMember.
=> le PVID est un paramètre à part qui est associé pour chaque port, il définit dans quel VLAN un paquet sans tag VLAN est affecté. Donc dans ce type de switch, on peut dire qu'à l'intérieur, les paquets sont tous tagués VLAN puis avant de ressortir sur un port, le tag est retiré si le port de sorti est en mode untagged.
=> chaque VLAN a sa propre table d'adresse MAC et chacune d'elle est traité indépendamment : il n'y a pas de liaison entre elles.

[boboss123]

Il est fort possible que je ne sois pas exactement à jour sur ma connaissance des commutateurs.

La différence entre un concentrateur (hub) et un commutateur (switch), est que le premier pour chaque envoie d'une trame, diffuse dans tout le réseau, car il ignore les adresses MAC des périphériques pour la simple raison, qu'il ne gère aucune table.

=> je suis d'accord.

Pour le second, la trame est envoyé uniquement vers le périphérique ayant la bonne adresse MAC.

=> je suis d'accord.

Il y a au démarrage du commutateur, une initialisation qui fait qu'il récupère toutes les adresses MAC des périphériques connectés.

=> le commutateur ne fait pas d'initialisation : il écoute les trames puis les transmet en fonction de sa connaissance du réseau (c'est la table d'adresse MAC... voir mon précédent post).

De même, quand un nouveau périphérique se connecte, il y a des échanges entre eux, afin de mettre à jour la table qui gère les adressses MAC. Régulièrement, le commutateur doit demandé à tous les périphériques s'ils sont encore bien présent, et des échanges, disons de réinitialisation, doivent être fait régulièrement.

=> le commutateur ne demande jamais rien sauf si certaines fonctions spécifiques sont activées (ex : spanning tree, 802.1X, LLDP.).. mais on sort de la fonctionnalité switch de base.

Dans le cas où un périphérique est débranché, la table conserve l'adresse MAC, d'où les délais d'attente de la réponse du périphérique qui ne viendra jamais. Je suppose que l'adresse MAC est conservé, mais le périphérique doit être mis en indisponibilité. D'où la constatation que la première réponse de ce périphérique indisponible est longue à attendre, tandis que les fois suivantes, elle sera très rapide car maintenant le commutateur sait que le périphérique est débranché (ou indisponible).

Je ne comprends pas bien ce que tu as fais. Tu débranche puis rebranche un périphérique sur le même port, c'est ça ? ça ne semble pas logique comme comportement, ça devrait marcher de suite... cependant certains switches peuvent faire de l'analyse de requêtes ARP : ils interdisent toutes les paquets entrants dont l'adresse MAC n'a pas été enregistrée dans la table d'adresse MAC et l'enregistrement des adresses se fait uniquement sur requête ARP (fonction ARP inspection)... avec ce mécanisme, il faut donc que les requêtes ARP aient été effectuées par les deux équipements avant que la communication soit opérationnelle. Peut-être que c'est configurable dans systemd-networkd ? Sinon le soucis, c'est peut-être qu'il faut un délai avec qu'une interface soit active (en particulier qu'elle gère le spanning tree, il y a un temps de quelques secondes avant qu'elle soit activée réellement).

Si l'adresse MAC est renseignée mais n'est pas connu, pourquoi veux tu qu'il diffuse la trame sur toutes les sorties du commutateur, alors qu'il connait toutes les adresses MAC des périphériques branchés ? C'est contraire à son fonctionnement puisqu'il a une table où son stocké toutes les adresses MAC. Cela ne me semble pas logique du tout de procéder ainsi.

Parce que ça voudrait dire que les VLAN ne sont pas réellement isolés... c'est l'inverse de l'utilité première des VLANs.

Juste une question afin de comprendre comment va se faire la diffusion. Nous sommes dans un commutateur qui gère les niveaux 1 (physique) er 2 (liaison). Une diffusion se fait sur l'adresse IP de broadcasting et c'est du ressort du niveau 3 (réseau), non ? Ou alors, et je reconnais que je ne sais pas, s'il existe plusieurs mode de diffusion dans un réseau local.

Un commutateur (layer 2) n'analyse pas les adresses IP, il analyse uniquement les adresses MAC.
Remarque : si le bit I/G (https://fr.wikipedia.org/wiki/Adresse_MAC) est à 1, le paquet est diffusé sur tous les ports. L'adresse MAC FF:FF:FF:FF:FF:FF est un adresse MAC multicast spécifique, c'est l'adresse de broadcast.

[Artemus24]

layer-2... donc ne travaille que sur les adresses MAC, les adresses IP ne sont pas analysées

Je le sais et je ne fais aucune confusion sur l'acheminement des paquets dans un commutateur et de surcroit dans un réseau local.
Un commutateur ne gère que la couche 1 (physique) et la couche 2 (liaison) du modèle OSI.

puis le switch extrait l’adresse MAC destination (DDDD.DDDD.DDDD) et la compare à sa table : aucune entrée trouvée donc ne sachant pas où envoyer la trame, il la diffuse sur tous les ports exceptés le port de réception E0.

Il diffuse quoi ?

Quand le commutateur ignore l'adresse MAC qui est associée à une adresse IP, il se sert du protocole "ARP" pour le savoir et la diffuse partout.
Qui va répondre ? Cela dépend si le périphérique est dans le réseau local ou au delà du routeur.
Dans le premier cas, c'est l'adresse MAC du périphérique qui sera communiqué, dans le second cas, c'est l'adresse MAC du routeur.
Dans tous les cas, le commutateur aura l'adresse MAC du destinataire. Ce paquet "arp" retour se fait en UNICAST.
Le paquet (celui contenant les données à transmettre) est acheminé de saut (ou hop) en saut jusqu'à son périphérique destinataire.

Là où j'ai commis une erreur, l'adresse MAC disparait de la table quand le périphérique est débranché.
Pourquoi ? Parce que l'interface est remise à zéro quand elle passe à "DOWN".
Il est bon parfois de s'informer un peu plus sur ce que l'on croit savoir.

Si l'adresse MAC destination n'a pas été enregistrée, le paquet est broadcasté sur tous les ports.

Ce qui est diffusé est un paquet contenant le protocole arp, mais le paquet contenant les données à transmettre. Voir ce lien, ainsi que le protocole arp.

Il est vrai que je ne me souvenais plus de ce timer.

=> A chaque fois qu'un paquet entre sur un port, le aging-time est réinitialisé pour l'adresse MAC source du paquet (ex : 120 sec). Tous les seconde, le aging-time de toutes les entrées en décrémenté : si un des aging-time arrive à 0, l'entrée est supprimée de la table.

C'est un mécanisme qui consiste à ne pas remplir inutilement la table avec des adresses MAC qui ne sont plus sollicités.
La table est limité en nombre de lignes. Si l'adresse MAC n'est pas présente, on pose la question avec le protocole ARP et l'on réinitialise le aging-time.

=> le commutateur ne fait pas d'initialisation : il écoute les trames puis les transmet en fonction de sa connaissance du réseau (c'est la table d'adresse MAC... voir mon précédent post).

C'est le périphérique qui envoie sa carte de visite. Le commutateur est passif et comme tu dis, ne fait qu'écouter. Il y a bien un mécanisme qui fait passer l'interface à "UP". Il y a bien un bavardage qui se fait, je le vois avec la diode du commutateur qui n'arrête pas de clignoter.

Je ne comprends pas bien ce que tu as fais.

Je sais, mes explications sont parfois vaseuse. Laisse tombé.

Parce que ça voudrait dire que les VLAN ne sont pas réellement isolés... c'est l'inverse de l'utilité première des VLANs.

Je ne parlais pas ici du paquet VLAN à transmettre, mais de la recherche de l'adresse MAC dans le réseau local. En admettant que l'adresse MAC se trouve bien dans le réseau local, je ne sais pas si la réponse sera "trouvé" car il est dans le même réseau virtuel ou "pas trouvé" car appartenant à un autre réseau virtuel.

Je ne sais pas trop si je te l'ai dit, mais je débute dans la configuration des réseaux. J'ai encore de vieux souvenir de l'école, mais bon, ça remonte à Mathusalem.

@+

[boboss123]

Il diffuse quoi ?

Quand le commutateur ignore l'adresse MAC qui est associée à une adresse IP, il se sert du protocole "ARP" pour le savoir et la diffuse partout.

Je ne sais pas bien si on est raccord.
Pour le terme "diffuse", le switch envoie le paquet sur tous ses ports, c'est ça que ça veut dire.
Après dire que le commutateur se sert du protocole "ARP", il ne fait que réceptionner le paquet et le retransmettre, ce sont les équipements et les passerelles qui génèrent ce type de paquet : un switch de base ne sait même pas ce qu'est une trame ARP, il la traite comme n'importe quelle autre trame.

Oui lorsqu'un port passe à l'état down, toutes les adresses MAC du port peuvent être supprimées de la table d'adresse MAC... mais tous les switches ne le font pas, dans ce cas il faut attendre que le aging-time s'écoule.

[Artemus24]

Pour le terme "diffuse", le switch envoie le paquet sur tous ses ports, c'est ça que ça veut dire.

J'ai bien compris le sens du mot "diffuser" (en anglais "broadcast"). Mais ma question concernait le type de paquet.
Est-ce celui reçu contenant des données à transmettre ? Ou celui d'une demande d'adresse MAC par le protocole arp ?
Je suppose que cette demande d'adresse MAC sait gérer le NDP (Neighbor Discovery Protocol) pour l'IPv6.

un switch de base ne sait même pas ce qu'est une trame ARP, il la traite comme n'importe quelle autre trame.

Les commutateur ont beaucoup évolué et comme j'ai pu le lire, certains gèrent une partie du niveau 3 (réseau) du modèle OSI.
Un VLAN est géré par le niveau 3 et si le commutateur ne sait pas faire cela, il va se comporter normalement comme un commutateur de niveau 2 (liaison) et transmettre le paquet au bon destinataire, sans faire une diffusion sur tous les ports.

Dans ce lien, l'auteur affirme :

Les switchs de niveau 2 sont les plus courants vu qu’ils tendent à être plus accessibles sur un plan financier et s’acquittent très bien de leur tâche. Concrètement, ils utilisent l’adresse MAC (adresse physique) d’un appareil depuis les trames de messages reçus pour déterminer vers quel port l’information doit être relayée. Pour cela, un switch s’appuie sur une table d’adresses MAC dynamique qu’il génère et met à jour à partir des requêtes ARP (protocole permettant de traduire une adresse IP en adresse MAC), ce qui lui permet donc de reconnaître les trames.

A croire cette auteur, le niveau 2 (liaison) du modèle OSI sait gérer les demandes d'adresse MAC (arp ou ndp).

Pour revenir sur ce qui me dérangeait depuis le début, ce n'est pas le paquet reçu contenant des données à transmettre, qui sera diffusé partout dans le réseau local, mais un autre paquet, bien plus petit contenant une demande d'adresse MAC (ARP ou NDP). Car si tu procèdes en diffusant partout le paquet de données, ton commutateur (switch) se comporte comme un concentrateur (Hub), ce qui n'est pas le but. Le but est justement de réduire le trafic dans le réseau local, en envoyant le paquet de données au bon destinataire, sans faire une diffusion sur tout le réseau.

A vrai dire, ce n'est pas la mécanique du commutateur qui m'intéresse ici dans ce sujet, mais plutôt la configuration des VLAN. Mais merci pour tes explications sur le fonctionnement d'un commutateur.

[Artemus24]

Jusqu'à présent, j'ai traité l'acheminement des flux VLAN vers leur destinataire, des Raspberry Pi.
Maintenant, je traite la création des VLAN. Voici la configuration :
--> Fichier "06-ethernet.network" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
[Match]
Name=enp2s0

[Network]
DHCP=yes
DNS=192.168.1.1
VLAN=vl0
VLAN=vl1

--> Fichier "06-vlan0.netdev" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
[NetDev]
Name=vl0
Kind=vlan

[VLAN]
Id=210

--> Fichier "06-vlan0.network" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[Match]
Name=vl0
Type=vlan

[Network]
Address=10.0.0.210/24
DHCP=no
IPv6AcceptRA=no
IPv6SendRA=no
LinkLocalAddressing=no

[Route]
Destination=0.0.0.0/0
Gateway=10.0.0.1
Table=210

[RoutingPolicyRule]
From=10.0.0.0/24
Table=210

--> Fichier "06-vlan1.netdev" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
[NetDev]
Name=vl1
Kind=vlan

[VLAN]
Id=220

--> Fichier "06-vlan1.network" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[Match]
Name=vl1
Type=vlan

[Network]
Address=10.0.1.220/24
DHCP=no
IPv6AcceptRA=no
IPv6SendRA=no
LinkLocalAddressing=no

[Route]
Gateway=10.0.1.1
Table=220

[RoutingPolicyRule]
From=10.0.1.0/24
Table=220

Et voici le compte-rendu :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
root~> networkctl
IDX LINK   TYPE     OPERATIONAL SETUP
  1 lo     loopback carrier     unmanaged
  2 enp2s0 ether    routable    configured
  3 wlan0  wlan     off         unmanaged
 68 vl0    vlan     routable    configured
 69 vl1    vlan     routable    configured

5 links listed.
root~> networkctl status
●        State: routable
  Online state: online
       Address: 192.168.1.11 on enp2s0
                10.0.0.210 on vl0
                10.0.1.220 on vl1
                2a02:84xx:xxxx:xxx1::110 on enp2s0
                fe80::d65d:64ff:fe6b:f25b on enp2s0
       Gateway: 192.168.1.1 on enp2s0
                fe80::ce2d:1bff:fef0:2778 on enp2s0
           DNS: 192.168.1.1
           NTP: 192.168.1.1

janv. 24 15:31:07 Debian systemd-networkd[15121]: vl0: Link UP
janv. 24 15:31:07 Debian systemd-networkd[15121]: vl1: Link UP
janv. 24 15:31:08 Debian systemd-networkd[15121]: enp2s0: Lost carrier
janv. 24 15:31:08 Debian systemd-networkd[15121]: enp2s0: DHCPv6 lease lost
janv. 24 15:31:11 Debian systemd-networkd[15121]: enp2s0: Gained carrier
janv. 24 15:31:11 Debian systemd-networkd[15121]: vl0: Gained carrier
janv. 24 15:31:11 Debian systemd-networkd[15121]: vl1: Gained carrier
janv. 24 15:31:12 Debian systemd-networkd[15121]: enp2s0: Gained IPv6LL
janv. 24 15:31:14 Debian systemd-networkd[15121]: enp2s0: DHCPv6 address 2a02:84xx:xxxx:xxx1::110/128 (valid for 59min 59s, preferred for 59min 59s)
janv. 24 15:31:14 Debian systemd-networkd[15121]: enp2s0: DHCPv4 address 192.168.1.11/24, gateway 192.168.1.1 acquired from 192.168.1.1
root~> networkctl status enp2s0
● 2: enp2s0                     
                     Link File: /etc/systemd/network/01-wired.link
                  Network File: /etc/systemd/network/06-ethernet.network
                         State: routable (configured)
                  Online state: online
                          Type: ether
                          Path: pci-0000:02:00.0
                        Driver: r8169
                        Vendor: Realtek Semiconductor Co., Ltd.
                         Model: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
              Hardware Address: d4:5d:64:6b:f2:5b (ASUSTek COMPUTER INC.)
                           MTU: 1500 (min: 68, max: 9194)
                         QDisc: fq_codel
  IPv6 Address Generation Mode: eui64
      Number of Queues (Tx/Rx): 1/1
              Auto negotiation: yes
                         Speed: 1Gbps
                        Duplex: full
                          Port: tp
                       Address: 192.168.1.11 (DHCP4 via 192.168.1.1)
                                2a02:84xx:xxxx:xxx1::110
                                fe80::d65d:64ff:fe6b:f25b
                       Gateway: 192.168.1.1
                                fe80::ce2d:1bff:fef0:2778
                           DNS: 192.168.1.1
                                2a02:84xx:xxxx:xxx1::1
                           NTP: 192.168.1.1
             Activation Policy: up
           Required For Online: yes
               DHCP4 Client ID: IAID:0x5de26c15/DUID
             DHCP6 Client IAID: 0x5de26c15
             DHCP6 Client DUID: DUID-EN/Vendor:0000ab114fbd83174dabee7b0000

janv. 24 15:31:07 Debian systemd-networkd[14828]: enp2s0: DHCPv6 lease lost
janv. 24 15:31:07 Debian systemd-networkd[15121]: enp2s0: Configuring with /etc/systemd/network/06-ethernet.network.
janv. 24 15:31:07 Debian systemd-networkd[15121]: enp2s0: Link UP
janv. 24 15:31:07 Debian systemd-networkd[15121]: enp2s0: Gained carrier
janv. 24 15:31:08 Debian systemd-networkd[15121]: enp2s0: Lost carrier
janv. 24 15:31:08 Debian systemd-networkd[15121]: enp2s0: DHCPv6 lease lost
janv. 24 15:31:11 Debian systemd-networkd[15121]: enp2s0: Gained carrier
janv. 24 15:31:12 Debian systemd-networkd[15121]: enp2s0: Gained IPv6LL
janv. 24 15:31:14 Debian systemd-networkd[15121]: enp2s0: DHCPv6 address 2a02:84xx:xxxx:xxx1::110/128 (valid for 59min 59s, preferred for 59min 59s)
janv. 24 15:31:14 Debian systemd-networkd[15121]: enp2s0: DHCPv4 address 192.168.1.11/24, gateway 192.168.1.1 acquired from 192.168.1.1
root~> networkctl status vl0
● 68: vl0                       
                     Link File: /usr/lib/systemd/network/99-default.link
                  Network File: /etc/systemd/network/06-vlan0.network
                         State: routable (configured)
                  Online state: online
                          Type: vlan
                          Kind: vlan
                        Driver: 802.1Q VLAN Support
              Hardware Address: d4:5d:64:6b:f2:5b (ASUSTek COMPUTER INC.)
                           MTU: 1500 (max: 65535)
                         QDisc: noqueue
  IPv6 Address Generation Mode: none
                       VLan Id: 210
      Number of Queues (Tx/Rx): 1/1
              Auto negotiation: yes
                         Speed: 1Gbps
                        Duplex: full
                          Port: tp
                       Address: 10.0.0.210
             Activation Policy: up
           Required For Online: yes

janv. 24 15:25:13 Debian systemd-networkd[14828]: vl0: netdev ready
janv. 24 15:25:13 Debian systemd-networkd[14828]: vl0: Configuring with /etc/systemd/network/06-vlan0.network.
janv. 24 15:25:13 Debian systemd-networkd[14828]: vl0: Link UP
janv. 24 15:25:17 Debian systemd-networkd[14828]: vl0: Gained carrier
janv. 24 15:31:07 Debian systemd-networkd[14828]: vl0: Link DOWN
janv. 24 15:31:07 Debian systemd-networkd[14828]: vl0: Lost carrier
janv. 24 15:31:07 Debian systemd-networkd[15121]: vl0: netdev ready
janv. 24 15:31:07 Debian systemd-networkd[15121]: vl0: Configuring with /etc/systemd/network/06-vlan0.network.
janv. 24 15:31:07 Debian systemd-networkd[15121]: vl0: Link UP
janv. 24 15:31:11 Debian systemd-networkd[15121]: vl0: Gained carrier
root~> networkctl status vl1
● 69: vl1                       
                     Link File: /usr/lib/systemd/network/99-default.link
                  Network File: /etc/systemd/network/06-vlan1.network
                         State: routable (configured)
                  Online state: online
                          Type: vlan
                          Kind: vlan
                        Driver: 802.1Q VLAN Support
              Hardware Address: d4:5d:64:6b:f2:5b (ASUSTek COMPUTER INC.)
                           MTU: 1500 (max: 65535)
                         QDisc: noqueue
  IPv6 Address Generation Mode: none
                       VLan Id: 220
      Number of Queues (Tx/Rx): 1/1
              Auto negotiation: yes
                         Speed: 1Gbps
                        Duplex: full
                          Port: tp
                       Address: 10.0.1.220
             Activation Policy: up
           Required For Online: yes

janv. 24 15:25:13 Debian systemd-networkd[14828]: vl1: netdev ready
janv. 24 15:25:13 Debian systemd-networkd[14828]: vl1: Configuring with /etc/systemd/network/06-vlan1.network.
janv. 24 15:25:13 Debian systemd-networkd[14828]: vl1: Link UP
janv. 24 15:25:17 Debian systemd-networkd[14828]: vl1: Gained carrier
janv. 24 15:31:07 Debian systemd-networkd[14828]: vl1: Link DOWN
janv. 24 15:31:07 Debian systemd-networkd[14828]: vl1: Lost carrier
janv. 24 15:31:07 Debian systemd-networkd[15121]: vl1: netdev ready
janv. 24 15:31:07 Debian systemd-networkd[15121]: vl1: Configuring with /etc/systemd/network/06-vlan1.network.
janv. 24 15:31:07 Debian systemd-networkd[15121]: vl1: Link UP
janv. 24 15:31:11 Debian systemd-networkd[15121]: vl1: Gained carrier

Et quelques vérifications supplémentaires :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
root~> cat /proc/net/vlan/config
VLAN Dev name	 | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
vl0            | 210  | enp2s0
vl1            | 220  | enp2s0
root~> ip rule
0:	from all lookup local
32764:	from 10.0.1.0/24 lookup 220 proto static
32765:	from 10.0.0.0/24 lookup 210 proto static
32766:	from all lookup main
32767:	from all lookup default
root~> ip route list table 210
default via 10.0.0.1 dev vl0 proto static 
root~> ip route list table 220
default via 10.0.1.1 dev vl1 proto static 
root~> ip route list table 0
default via 10.0.0.1 dev vl0 table 210 proto static 
default via 10.0.1.1 dev vl1 table 220 proto static 
default via 192.168.1.1 dev enp2s0 proto dhcp src 192.168.1.11 metric 1024 
10.0.0.0/24 dev vl0 proto kernel scope link src 10.0.0.210 
10.0.1.0/24 dev vl1 proto kernel scope link src 10.0.1.220 
192.168.1.0/24 dev enp2s0 proto kernel scope link src 192.168.1.11 metric 1024 
192.168.1.1 dev enp2s0 proto dhcp scope link src 192.168.1.11 metric 1024 
local 10.0.0.210 dev vl0 table local proto kernel scope host src 10.0.0.210 
broadcast 10.0.0.255 dev vl0 table local proto kernel scope link src 10.0.0.210 
local 10.0.1.220 dev vl1 table local proto kernel scope host src 10.0.1.220 
broadcast 10.0.1.255 dev vl1 table local proto kernel scope link src 10.0.1.220 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
local 192.168.1.11 dev enp2s0 table local proto kernel scope host src 192.168.1.11 
broadcast 192.168.1.255 dev enp2s0 table local proto kernel scope link src 192.168.1.11 
fe80::/64 dev enp2s0 proto kernel metric 256 pref medium
default via fe80::ce2d:1bff:fef0:2778 dev enp2s0 proto ra metric 1024 expires 1685sec mtu 1500 pref high
local ::1 dev lo table local proto kernel metric 0 pref medium
local 2a02:842b:8eda:b301::110 dev enp2s0 table local proto kernel metric 0 pref medium
anycast fe80:: dev enp2s0 table local proto kernel metric 0 pref medium
local fe80::d65d:64ff:fe6b:f25b dev enp2s0 table local proto kernel metric 0 pref medium
multicast ff00::/8 dev enp2s0 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev vl0 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev vl1 table local proto kernel metric 256 pref medium

Le but est de créer deux VLAN (210 & 220).
Je t'ai mis les tables de routage afin de voir comment ils ont été configurées.

Le cas du réseau domotique est différent car ce réseau virtuel (vlan) est un réseau isolé et n'est pas accessible depuis l'internet.
Aucun flux ne sort du lan et je n'ai besoin que de l'acheminer d'un périphérique IOT vers un ordinateur central, comme une tablette

Je ne peux pas tester cette configuration pour la simple raison que j'aurai besoin d'un deuxième ordinateur, que je n'ai pas.
Ce que j'ai traité jusqu'à présent, est le cas d'un commutateur où des Raspberry Pi sont branchés et où je dispatche les flux vlan vers les Raspberry Pi.
Il me faudrait un autre ordinateur, sous Debian, qui ferai office de routeur/commutateur.
Et ces flux VLAN seraient envoyés vers l'autre commutateur afin de les réceptionner et de voir si les Raspberry Pi les reçoivent.

@+