JavaScript is required to for searching.
Ignorer les liens de navigation
Quitter l'aperu
Administration d'Oracle Solaris : Interfaces réseau et virtualisation réseau     Oracle Solaris 11 Information Library (Français)
search filter icon
search icon

Informations document

Préface

1.  Présentation de la pile réseau

Configuration réseau dans cette version d'Oracle Solaris

Pile réseau dans Oracle Solaris

Noms des périphériques réseau et des liaisons de données

Administration d'autres types de liens

Partie I Configuration automatique de réseau

2.  Présentation de NWAM

3.  Configuration et administration NWAM (présentation)

4.  Configuration de profil NWAM (tâches)

5.  Administration des profils NWAM (tâches)

6.  A propos de l'interface graphique NWAM

Partie II Configuration de liaisons de données et d'interfaces

7.  Utilisation des commandes de configuration de l'interface et de liaison de données sur les profils

8.  Configuration et administration des liaisons de données

9.  Configuration d'une interface IP

10.  Configuration des communications via une interface sans fil sur Oracle Solaris

11.  Administration des ponts

Présentation du pontage

Propriétés de liaison

Démon STP

Démon TRILL

Débogage des ponts

Autres comportements des ponts

Comportement DLPI

Administration VLAN

Comportement VLAN

Exemples de configuration de pont

Administration de ponts (liste des tâches)

Affichage d'informations sur les ponts configurés

Affichage des informations de configuration sur les liaisons de pont

Création d'un pont

Modification du type de protection pour un pont

Ajout d'une ou de plusieurs liaisons à un pont existant

Suppression des liaisons d'un pont

Suppression d'un pont du système

12.  Administration de groupements de liens

13.  Administration des réseaux locaux virtuels

14.  Présentation d'IPMP

15.  Administration d'IPMP

16.  Echange d'informations sur la connectivité réseau à l'aide du protocole LLDP

Partie III Virtualisation du réseau et gestion des ressources

17.  Introduction à la virtualisation du réseau et au contrôle des ressources (présentation)

18.  Planification de la virtualisation du réseau et du contrôle des ressources

19.  Configuration des réseaux virtuels (tâches)

20.  Utilisation de la protection des liens dans les environnements virtualisés

21.  Gestion des ressources réseau

22.  Contrôle du trafic réseau et de l'utilisation des ressources

Glossaire

Index

Présentation du pontage

Les ponts permettent de connecter des segments du réseau. Dans le cas d'une connexion par pont, les segments réseau reliés communiquent comme s'ils formaient un seul et même segment réseau. Le pontage est mis en oeuvre au niveau de la couche de liaison de données (L2) de la pile réseau. Les ponts utilisent un mécanisme de transmission de paquets pour connecter des sous-réseaux.

Bien que le pontage et le routage puissent être utilisés pour diffuser des informations sur l'emplacement des ressources réseau, ils diffèrent de plusieurs façons. Le routage est mis en oeuvre au niveau de la couche IP (L3) et utilise les protocoles de routage. Aucun protocole de routage n'est utilisé sur la couche de liaison de données. En revanche, les destinations des paquets transmis sont déterminées par l'examen du trafic sur le réseau, reçu sur les liaisons reliées au pont.

Lorsqu'un paquet est reçu, son adresse source est examinée. L'adresse source du paquet associe le noeud à partir duquel le paquet a été envoyé à la liaison sur laquelle il est reçu. Par la suite, lorsqu'un paquet reçu utilise cette même adresse comme adresse de destination, le pont transmet le paquet sur la liaison vers cette adresse.

La liaison associée à une adresse source peut être une liaison intermédiaire, connectée à un autre pont au sein du sous-réseau constitué de ponts. Au fil du temps, tous les ponts au sein du sous-réseau ''apprennent'' quelle est la liaison qui envoie un paquet vers un noeud donné. Par conséquent, l'adresse de destination du paquet est utilisée pour le diriger vers sa destination finale par le biais d'un pontage de connexions directes.

Une notification locale d'interruption de liaison indique que tous les noeuds d'une liaison donnée ne sont plus accessibles. Dans cette situation, le transfert de paquet vers la liaison est interrompu et toutes les entrées de transfert sur la liaison sont supprimées. Au fil du temps, les entrées de transfert sont également supprimées. Lorsqu'une liaison est restaurée, les paquets reçus via cette liaison sont traités comme des nouveaux paquets. Le ''processus d'apprentissage " basé sur l'adresse source d'un paquet recommence. Ce processus permet au pont de transférer correctement des paquets sur cette liaison lorsque l'adresse est utilisée comme adresse de destination.

Pour transférer les paquets à leur destination, les ponts doivent écouter en mode de promiscuité toutes les liaisons reliées au pont. L'écoute en mode de promiscuité rend les ponts vulnérables aux occurrences de boucles de transfert dans lesquelles les paquets tournent indéfiniment à taux plein. Par conséquent, le pontage utilise le mécanisme STP (Spanning Tree Protocol) pour éviter les boucles réseau qui rendraient les sous-réseaux inutilisables.

Outre l'utilisation de STP et de RSTP (Rapid Spanning Tree Protocol) pour les ponts, Oracle Solaris prend en charge l'amélioration de la protection TRILL. STP est utilisé par défaut, mais vous pouvez utiliser TRILL en spécifiant l'option -P trill pour les commandes de pontage.

L'utilisation d'une configuration de pont simplifie l'administration des divers noeuds réseau en les connectant au sein d'un seul et même réseau. En reliant ces segments par un pont, tous les noeuds partagent un réseau unique de diffusion. Par conséquent, chaque noeud peut atteindre les autres en utilisant des protocoles réseau tels qu'IP plutôt que des routeurs pour transférer le trafic d'un segment du réseau à l'autre. Si vous n'utilisez pas un pont, vous devez configurer le routage IP de sorte à autoriser le transfert du trafic IP entre les noeuds.

La figure ci-dessous illustre une configuration réseau de ponts simple. Le pont goldengate est un système Oracle Solaris dont le pontage est configuré. Les systèmes sanfrancisco et sausalito sont connectés physiquement au pont. Le réseau A utilise un hub physiquement connecté au pont d'un côté et à des systèmes informatiques de l'autre côté. Les ports de pont sont des liaisons, tels que bge0, bge1 et bge2.

Figure 11-1 Réseau simple relié par des ponts

image:Diagramme illustrant comment trois segments du réseau sont connectés par le biais d'un pont pour former un réseau unique.

Les réseaux de pont peuvent être formés en anneaux connectant physiquement plusieurs ponts. Ces configurations sont courantes dans les réseaux. Ce type de configuration risque de générer des problèmes dus aux paquets anciens qui saturent les liaisons réseau en tournant en boucle indéfiniment autour de l'anneau. Afin d'éviter de telles conditions de mise en boucle, les ponts Oracle Solaris mettent en oeuvre les protocoles STP et TRILL. Notez que la plupart des ponts matériels mettent également en oeuvre la protection contre les boucles STP.

La figure suivante illustre un réseau relié par des ponts, configuré dans un anneau. La configuration présente trois ponts. Deux systèmes sont connectés physiquement à westminster. Un système est connecté physiquement à waterloo. Un système est connecté physiquement à tower. Chaque pont est connecté physiquement aux autres par le biais des ports de pont.

Lorsque le protocole STP ou RSTP est utilisé dans le cadre de la protection contre les boucles, la boucle physique est atténuée en empêchant une des connexions dans la boucle de transmettre des paquets. Dans la figure, la liaison physique entre les ponts westminster et tower ne sert pas à transmettre des paquets.

Notez que si des liaisons physiques utilisables sont fermées dans le cadre de la protection contre les boucles, les protocoles STP et RSTP vous font perdre de la bande passante.

Contrairement à STP et RSTP, le protocole TRILL ne ferme pas les liaisons physiques afin d'éviter les boucles. TRILL calcule plutôt les informations du chemin le plus court pour chaque noeud TRILL au sein du réseau et les utilise pour transférer les paquets vers différentes destinations.

Par conséquent, TRILL permet au système de ne jamais interrompre aucune liaison utilisée. Les boucles ne posent pas problème dans la mesure où elles sont gérées de la même manière qu'IP gère les boucles. En d'autres termes, TRILL crée des routes en fonction des besoins et utilise des limites de connexion directe de transfert pour éviter les problèmes causés par les états de boucle temporaires.

Figure 11-2 Anneau de réseau relié par un pont

image:Diagramme illustrant comment les protocoles STP ou TRILL évitent les boucles en éliminant une connexion dans un anneau de pont.

Attention

Attention - Ne définissez pas local-mac-address?=false sur les plates-formes SPARC, sinon les systèmes utiliseront la même adresse MAC sur plusieurs ports et sur le même réseau.



Remarque - Ne configurez pas une liaison dans un pont lorsque les plus hauts niveaux de performances sont requis. Le pontage requiert que les interfaces sous-jacentes soient en mode de promiscuité, ce qui désactive un nombre d'optimisations importantes dans les couches de matériel, pilote et autres du système. La désactivation de ces améliorations de performances est une conséquence inévitable du mécanisme de pontage.

Vous pouvez utiliser un pont sur un système où certaines liaisons ne sont pas reliées par un pont et ne sont donc pas soumises à ces contraintes. Ces problèmes de performances n'ont d'incidence que sur les liaisons configurées pour faire partie d'un pont.


Pour plus d'informations sur le protocole STP, reportez-vous au document IEEE 802.1D-1998. Pour plus d'informations sur le protocole RSTP, reportez-vous au document IEEE 820.1Q-2004. Pour plus d'informations sur le protocole TRILL, reportez-vous aux documents Internet Engineering Task Force (IETF) TRILL draft documents.

Propriétés de liaison

Ces propriétés de liaison peuvent être affichées et modifiées par les commandes dladm show-linkprop, dladm set-linkprop et reset-linkprop  :

default_tag

Définit l'ID VLAN (virtual local area network, réseau local virtuel) par défaut pour les paquets sans étiquette envoyés depuis et vers la liaison. Les valeurs valides sont comprises entre 0 et 4094. La valeur par défaut est 1. Seules les liaisons non-VLAN et non-VNIC (virtual network interface card, carte réseau virtuelle) possèdent cette propriété. La définition de cette valeur sur 0 désactive la transmission de paquets sans étiquette depuis et vers le port. (Il s'agit d'une propriété MAC.)


Remarque - Cette propriété est également utilisée en dehors de la portée du pontage pour spécifier le PVID (Port VLAN Identifier) IEEE de cette liaison. Lorsque la propriété default_tag n'est pas définie sur zéro, vous ne pouvez pas créer un VLAN qui a ce même ID sur la liaison, car la liaison de base elle-même représente automatiquement le PVID.

Si, par exemple, le PVID est défini sur 5 sur net0, vous ne pouvez pas créer un VLAN avec l'ID 5 sur net0. Pour définir le VLAN 5 dans cette situation, utilisez net0.

Vous ne pouvez pas définir la propriété default_tag pour qu'elle soit égale à l'ID d'un VLAN existant créé sur ce lien. Par exemple, la commande suivante crée VLAN 22 sur net0 :

# dladm create-vlan -l net0 -v 22 myvlan0

Dans cette situation, vous ne pouvez pas définir default_tag sur 22, car net0 et myvlan0 représenteraient le même VLAN.

En définissant default_tag sur 0, vous permettez que les paquets sans étiquette sur net0 soient dissociés de tous les VLAN. Cette situation permet d'empêcher la transmission de ces paquets par un pont configuré.


forward

Active et désactive la transmission de trafic via le pont. Cette propriété existe sur toutes les liaisons, à l'exception des liaisons VNIC. Les valeurs valides sont 1 (vrai) et 0 (faux). La valeur par défaut est 1. Lorsqu'il est désactivé, un VLAN associé à une instance de liaison ne transfère pas de trafic via le pont. Désactiver le transfert revient à supprimer le VLAN de ''l'ensemble autorisé'' pour un pont traditionnel. Cela signifie que les E/S VLAN vers la liaison sous-jacente des clients locaux se poursuit, mais que le transfert sur les ponts n'a pas lieu.

stp

Active et désactive les protocoles STP et RSTP. Les valeurs valides sont 1 (vrai) et 0 (faux). La valeur par défaut 1 permet d'activer les protocoles STP et RSTP. Lorsqu'elle est définie sur 0, la liaison n'utilise pas n'importe quel type de protocole STP et elle est placée en mode de transfert à tout moment. Le mode de transfert utilise la protection BPDU (bridge protocol data unit). Désactivez les protocoles STP et RSTP lorsque vous souhaitez configurer des liaisons point à point connectées aux noeuds de fin. Seules les liaisons de type non-VLAN et non-VNIC possèdent cette propriété.

stp_cost

Représente les valeurs de coût STP et RSTP pour utiliser la liaison. Les valeurs valides sont comprises entre 1 et 65535. La valeur par défaut 0 signale que le coût est automatiquement calculé par le type de liaison. Les valeurs suivantes représentent le coût pour plusieurs types de liaisons : 100 pour 10 Mbit/s, 19 pour 100 Mbit/s, 4 pour 1 Gbit/s et 2 pour 10 Gbit/s.

stp_edge

Indique si le port est connecté à d'autres ponts. Les valeurs valides sont 1 (vrai) et 0 (faux). La valeur par défaut est 1. Si l'option est définie sur 0, le démon suppose que le port est connecté à d'autres ponts même si aucun BPDU d'aucun type n'est visible.

stp_p2p

Spécifie le type du mode de connexion. Les valeurs valides sont true, false et auto. La valeur par défaut auto détecte automatiquement les connexions point à point. Spécifiez true afin d'appliquer le mode point à point, et spécifiez false pour appliquer le mode multipoint normal.

stp_priority

Définit la valeur de la priorité de port STP et RSTP. Les valeurs valides sont comprises entre 0 et 255. La valeur par défaut est 128. La valeur de priorité du port STP et RSTP permet de déterminer le port racine préféré d'un pont en ajoutant la valeur au début de l'identificateur du port. La priorité est d'autant plus élevée que la valeur numérique est petite.

Démon STP

Chaque pont que vous créez à l'aide de la commande dladm create-bridge est représenté comme une instance SMF nommée de manière identique de svc:/network/bridge . Chaque instance exécute une copie du démon /usr/lib/bridged, qui met en oeuvre le protocole STP.

L'exemple de commande suivant crée un pont appelé pontevecchio  :

# dladm create-bridge pontevecchio

Le système crée un service SMF appelé svc:/network/bridge:pontevecchio et un noeud d'observabilité appelé /dev/net/pontevecchio0.

Pour des raisons de sécurité, tous les ports exécutent le protocole STP standard par défaut. Un pont qui n'exécute pas un type de protocole de pontage, tel que STP, peut former des boucles de transfert durables sur le réseau. Dans la mesure où Ethernet n'a pas de compte de connexion directe ou TTL sur les paquets, toutes les boucles de ce type sont fatales pour le réseau.

Si vous savez qu'un port particulier n'est pas connecté à un autre pont (par exemple, une connexion point à point directe à un système hôte), vous pouvez désactiver administrativement STP pour ce port. Même si STP est désactivé sur tous les ports d'un pont, le démon STP continue de s'exécuter. Et ce pour les raisons suivantes :

Lorsque STP est désactivé sur un port, le démon bridged continue d'être à l'écoute des BPDU (protection BPDU). Le démon utilise syslog pour marquer toutes les erreurs et désactive le transfert sur le port pour indiquer une grave erreur de configuration réseau. La liaison est réactivée lorsque l'état de liaison fluctue ou que vous supprimez manuellement la liaison avant de la rajouter.

Si vous désactivez l'instance de service SMF d'un pont, le transfert par pont s'interrompt sur ces ports à l'arrêt du démon STP. Si l'instance est redémarrée, STP commence à partir de son état initial.

Démon TRILL

Chaque pont que vous créez à l'aide de la commande dladm create-bridge -P trill est représenté comme une instance SMF portant le même nom de svc:/network/bridge et svc:/network/routing/trill . Chaque instance de svc:/network/routing/trill exécute une copie du démon /usr/lib/trilld, qui met en oeuvre le protocole TRILL.

L'exemple de commande suivant crée un pont appelé bridgeofsighs  :

# dladm create-bridge -P trill bridgeofsighs

Le système crée deux services SMF appelés svc:/network/bridge:bridgeofsighs et svc:/network/routing/trill:bridgeofsighs. En outre, le système crée un noeud d'observabilité appelé /dev/net/bridgeofsighs0 .

Débogage des ponts

Chaque instance de pont reçoit un "noeud d'observabilité" qui apparaît dans le répertoire /dev/net/ et porte le nom du pont suivi d'un 0 de fin.

Le noeud d'observabilité est destiné à être utilisé avec les utilitaires snoop et wireshark. Ce noeud se comporte comme une interface Ethernet classique, à l'exception de la transmission des paquets, qui sont silencieusement supprimés. Vous ne pouvez pas monter IP sur un noeud d'observabilité, ni effectuer des demandes de liaison (DL_BIND_REQ), sauf si vous utilisez l'option passive.

Lorsqu'il est utilisé, le noeud d'observabilité effectue une seule copie non modifiée de chaque paquet géré par le pont à la disposition de l'utilisateur. Ce comportement est similaire à celui d'un port de ''surveillance'' sur un pont traditionnel, et est soumis aux règles habituelles de ''mode de promiscuité'' DLPI. Vous pouvez utiliser pfmod ou les fonctions des utilitaires snoop et wireshark pour filtrer en fonction de l'ID VLAN.

Les paquets transmis représentent les données reçues par le pont.


Attention

Attention - Dans le cas où le pontage ajoute, supprime ou modifie une étiquette VLAN, les données affichées décrivent l'état qui précède ce processus. Ce cas rare peut être problématique si des valeurs default_tag distinctes sont utilisées sur différentes liaisons.


Pour afficher les paquets transmis et reçus sur une liaison particulière (une fois le pontage terminé), exécutez snoop sur chaque liaison plutôt que sur le noeud d'observabilité.

Pour plus d'informations à propos des noeuds d'observabilité, reportez-vous à la section Fonctions d'observabilité pour la virtualisation du réseau et le contrôle des ressources.

Autres comportements des ponts

Les sections suivantes décrivent comment le comportement des liaisons est modifié lorsque des ponts sont utilisés dans la configuration.

Pour plus d'informations sur le comportement des liaisons standard, reportez-vous à la section Administration de réseaux locaux virtuels.

Comportement DLPI

La section suivante décrit les différences dans le comportement des liaisons lorsqu'un pont est activé :

Administration VLAN

Par défaut, les réseaux locaux virtuels (VLAN, virtual local area networks) configurés sur le système sont transférés entre tous les ports sur une instance de pont. Lorsque vous appelez la commande dladm create-vlan ou dladm create-vnic -v et que la liaison sous-jacente fait partie d'un pont, cette commande permet également d'activer le transfert du VLAN spécifié sur cette liaison de pont.

Pour configurer un VLAN sur une liaison et désactiver le transfert vers ou à partir d'autres liaisons sur le pont, vous devez désactiver le transfert en définissant la propriété forward avec la commande dladm set-linkprop.

Utilisez la commande dladm create-vlan pour activer automatiquement le VLAN pour le pontage lorsque la liaison sous-jacente est configurée dans le cadre d'un pont.

Les VLAN sont ignorés dans le STP conforme aux normes. Le protocole de pontage calcule une seule topologie sans boucle à l'aide de messages BPDU sans étiquette et utilise cette arborescence pour activer et désactiver les liaisons. Vous devez configurer les liaisons, qui sont fournies dans vos réseaux, en double de telle sorte que, lorsqu'elles sont automatiquement désactivées par STP, les VLAN configurés ne sont pas déconnectés. Cela signifie que vous devez exécuter tous les VLAN en tout point de votre infrastructure de ponts ou examiner soigneusement toutes les liaisons redondantes.

Il n'est pas nécessaire que TRILL suive les règles STP complexes. Au contraire, TRILL encapsule automatiquement les paquets dont l'étiquette VLAN est intacte et les transmet à travers le réseau. En d'autres termes, TRILL relie les VLAN isolés lorsque le même ID de VLAN a été réutilisé dans un réseau de ponts unique.

Il s'agit d'une différence importante par rapport à STP où vous pouvez réutiliser les étiquettes VLAN dans des sections isolées du réseau pour gérer des ensembles de VLAN dépassant la limite de 4094. Bien que vous ne puissiez pas utiliser TRILL pour gérer les réseaux de cette manière, vous pouvez mettre en oeuvre d'autres solutions, comme des VLAN basés sur le fournisseur.

Dans un réseau STP présentant des VLAN, il peut s'avérer difficile de configurer les caractéristiques de basculement pour empêcher le partitionnement VLAN lorsque STP désactive la ''mauvaise'' liaison. La perte relativement minime de fonctionnalités dans les VLAN isolés est plus que compensée par la robustesse du modèle TRILL.

Comportement VLAN

Le pont effectue le transfert en examinant l'ensemble autorisé de VLAN et la propriété default_tag pour chaque liaison. Le processus général s'effectue comme suit :


Remarque - Dans le cas où le transfert a lieu vers plusieurs interfaces (destinations de diffusion, multidiffusion et inconnues), la vérification de liaison de sortie et la mise à jour d'étiquette doivent être effectuées indépendamment pour chaque liaison de sortie. Certaines transmissions peuvent être balisées, d'autres non.


Exemples de configuration de pont

Les exemples suivants montrent comment afficher des informations sur les configurations de pont et les services de pontage.