3 votes

rhY avatar

Linux: ponts, VLANs et RSTP

Demandé el 6 de Janvier, 2017
Quand la question a-t-elle été
12995 affichage
Nombre de visites la question a
2 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

J'ai essayé de comprendre comment configurer RSTP sur Linux avec des VLAN et des ponts impliqués et maintenant je suis complètement confus.

Je cherche à relier trois interfaces, dont deux sont censées agir en tant que trunk (hdlc0 et hdlc1) et une est censée agir en tant que port d'accès (eth0). Je dois également activer RSTP sur chaque interface incluse dans le pont, mais avec la configuration ci-dessous, les paquets RSTP sont envoyés via hdlc0 et hdlc1 marqués (!) donc les autres appareils les rejettent. Comme Linux n'a pas de concept de 'vlan natif', je ne sais pas comment résoudre ce problème.

Voici ma configuration :

ifconfig eth0 up

ifconfig hdlc0 up
ifconfig hdlc1 up

vconfig add hdlc0 42
vconfig add hdlc1 42
ifconfig hdlc0.42 up
ifconfig hdlc1.42 up

brctl addbr br1
brctl addif br1 eth0
brctl addif br1 hdlc0.42
brctl addif br1 hdlc1.42

ifconfig br1 up
brctl stp br1 on

Une autre question : je me demande aussi comment configurer RSTP dans des scénarios où j'ai plusieurs ponts : disons qu'eth0 est un trunk avec le vlan 42-42 autorisé, le vlan 42 est censé passer par hdlc0 et le vlan 43 est censé passer par hdlc1, donc j'ai deux ponts. Si j'active RSTP sur les deux ponts, il s'exécutera probablement indépendamment sur chaque pont donc je rencontrerai bientôt des problèmes ?

Demandé el 6 de Janvier, 2017 par rhY

0 votes

Avatar de Adrian Zaugg

Il me semble que vous pouvez trouver de l'inspiration dans ce post: serverfault.com/questions/295652/…

Commenté el 6 de Janvier, 2017 par Adrian Zaugg

Réponses

Trop de publicités?

10voto

Willem avatar
Willem Points 2149

En Linux, les VLAN et les ponts sont des concepts complètement séparés, et les ponts Linux ne sont pas "conscients des VLAN".

Lorsque vous créez une interface VLAN, Linux étiquette/détiquette les paquets sur cette interface avant de les transmettre de/vers l'interface physique sous-jacente ("trunk"). Cependant, vous pouvez toujours utiliser l'interface physique sous-jacente pour envoyer des paquets non étiquetés ("VLAN natif").

Lorsque vous créez un pont, Linux commute les paquets entre les interfaces associées sans se soucier des étiquettes VLAN (ou du manque d'étiquettes) sur les paquets. Si vous attachez une interface trunk à un pont, le pont commute joyeusement les paquets étiquetés VLAN sans se soucier des étiquettes. Lorsque vous activez STP sur un pont, Linux génère des paquets STP non étiquetés et les dépose sur le pont.

Lorsqu'un pont est attaché à une interface physique qui a également des interfaces VLAN associées, ces interfaces VLAN cesseront de voir tout trafic qui n'est pas destiné à l'adresse MAC de l'interface physique. Ce comportement est dû à l'ordre dans lequel le commutage et le marquage VLAN sont traités, et peut être modifié en utilisant ebtables comme décrit à http://blog.rackspace.com/vms-vlans-and-bridges-oh-my-part-2. Cependant, en ce qui concerne l'Arbre de recouvrement, attacher des ponts à la fois à une interface physique et aux interfaces VLAN associées ne fonctionnera correctement que si vous utilisez de toute façon PVST+ (car le blocage de port STP est géré indépendamment pour chaque pont), donc ce n'est pas vraiment pertinent ici.

Mais vous pouvez également créer des interfaces VLAN sur un pont qui transmet des paquets étiquetés VLAN, puis ajouter ces interfaces VLAN à d'autres ponts.

Donc, pour accomplir ce que vous voulez, essayez :

ip link set dev hdlc0 up
ip link set dev hdlc1 up

brctl addbr br_native
brctl addif br_native hdlc0
brctl addif br_native hdlc1
brctl stp br_native on
ip link set dev br_native up

ip link add link br_native name br_native.42 type vlan id 42
ip link set dev br_native.42 up
ip link set dev eth0 up

brctl addbr br_42
brctl addif br_42 br_native.42
brctl addif br_42 eth0
ip link set dev br_42 up

Remarquez que le code de commutation de pont Linux prend en charge nativement uniquement le STP traditionnel 802.1D. Pour ajouter la prise en charge de RSTP et PVST+, utilisez https://github.com/mstpd/mstpd (Certains documents pertinents pour mstpd peuvent également être trouvés sur : https://docs.cumulusnetworks.com/display/DOCS/Spanning+Tree+and+Rapid+Spanning+Tree). Mstpd est également capable de parler MSTP, mais en raison de la manière dont Linux implémente ses FIB, il est actuellement impossible de mapper les topologies MSTP sur les ponts Linux, donc MSTP n'est pas réellement fonctionnel.

Pour répondre à votre deuxième question, je ne crois pas qu'il soit possible (sur un commutateur, pas seulement en utilisant Linux) d'utiliser STP ou RSTP pour diriger chacun des deux VLAN différents sur un seul trunk à travers deux autres troncs. Cela ne peut être accompli qu'en utilisant PVST+ ou MSTP, bien que comme mentionné ci-dessus, MSTP n'est pas supporté sur Linux.

Répondu el 6 de Janvier, 2017 par Willem (2149 Points )

0 votes

Avatar de rhY

Mais si je crée un second pont avec des interfaces physiques incluses, ce pont va "consommer" tous les paquets afin qu'ils n'atteignent jamais l'interface vlan. Cela peut être corrigé avec ebtables, mais dans ce cas, RSTP est actif sur le second pont (il bloque hdlc0, par exemple), mais pas sur le premier, donc les interfaces vlan ne sont pas bloquées (donc les paquets peuvent passer via hdlc0.42 et j'ai toujours une boucle). J'ai déjà essayé auparavant, je peux vous montrer un code.

Commenté el 7 de Janvier, 2017 par rhY

0 votes

Avatar de Willem

Hmmm... Vous avez raison, et je viens d'apprendre quelque chose de nouveau. Avant Linux 2.6.37, si le matériel NIC et le pilote prenaient en charge NETIF_F_HW_VLAN_RX, alors cela aurait pu fonctionner comme prévu. Avec Linux 2.6.37 et plus tard, le pont VLAN natif consomme toujours tous les paquets comme décrit ici: blog.rackspace.com/vms-vlans-and-bridges-oh-my-part-2

Commenté el 7 de Janvier, 2017 par Willem

0 votes

Avatar de Willem

Vous avez également raison que le STP sur le deuxième pont ne bloque pas la circulation sur le premier pont. Une solution consiste à utiliser PVST+ avec mstpd si vos autres commutateurs le prennent en charge. Une autre solution possible est d'ajouter les VLAN au-dessus du pont. Je mettrai à jour ma réponse avec un exemple.

Commenté el 7 de Janvier, 2017 par Willem
Afficher 1 autres commentaires

7voto

András Korn avatar
András Korn Points 631

Depuis le noyau Linux 3.0 environ, il n'est plus vrai que les ponts Linux ne sont pas "aware" des VLAN. https://linux-blog.anracom.com/2017/10/30/fun-with-veth-devices-in-unnamed-linux-network-namespaces-i/ et les articles suivants fournissent une explication assez bonne, mais en résumé:

Vous pouvez utiliser l'outil bridge(8) pour manipuler les interactions bridge-vlan, de manière similaire à la plupart des commutateurs gérés.

Dans votre situation, vous pourriez essayer quelque chose comme ceci:

# ip link set br0 type bridge vlan_filtering 1 vlan_default_pvid 1 stp_state 1 priority 32768 nf_call_iptables 1 nf_call_arptables 1
# bridge vlan add vid 1 pvid untagged dev eth0
bridge vlan add vid 19 dev eth0

ip link set up dev eth0
ip link set up dev hdlc0
ip link set up dev hdlc1

# si vous voulez seulement créer un pont VLAN42, vous n'avez pas besoin de ces lignes, mais voici comment vous pourriez les créer:
# ip link add link hdlc0 name hdlc0.42 type vlan protocol 802.1q id 1 reorder_hdr on gvrp on mvrp on loose_binding off
# ip link add link hdlc1 name hdlc1.42 type vlan protocol 802.1q id 1 reorder_hdr on gvrp on mvrp on loose_binding off
# ip link set up dev hdlc0.42
# ip link set up dev hdlc1.42

# maintenant pour la création du pont:
brctl addbr br1
brctl addif br1 eth0
brctl addif br1 hdlc0
brctl addif br1 hdlc1

# le port eth0 est un port untagged; supposons qu'il devrait être dans VLAN42:
bridge vlan add vid 42 dev eth0 pvid untagged
# hdlc0 est une interface trunk qui transmet vlan42 de manière taguée:
bridge vlan add vid 42 dev hdlc0
# hdlc1 transporte à la fois vlan42 et vlan43, les deux avec un tagging:
bridge vlan add vid 42 dev hdlc1
bridge vlan add vid 43 dev hdlc1

brctl stp br1 on
ip link set up dev br1

Vous pouvez également ajouter une interface VLAN à un pont, ce qui fait alors ce qui est logique, si vous y réfléchissez: le pont génère une trame Ethernet et la transmet au port, qui l'envoie. Étant donné que le port en question est une interface VLAN, il ajoute une étiquette VLAN avant d'envoyer la trame. Je suis sûr qu'il y a des utilisations valides pour cela mais je ne peux pas en penser à l'heure actuelle. :)

Répondu el 23 de Août, 2019 par András Korn (631 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X