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) |
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
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
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
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
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
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
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
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
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.
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 :
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é.
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.
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é.
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.
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.
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.
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.
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 :
pour traiter les nouveaux ports qui sont ajoutés ;
pour mettre en oeuvre la protection BPDU ;
pour activer ou désactiver le transfert sur les ports, si nécessaire.
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.
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 .
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 - 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.
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.
La section suivante décrit les différences dans le comportement des liaisons lorsqu'un pont est activé :
Les notifications d'activation de liaison (DL_NOTE_LINK_UP) et de désactivation de liaison (DL_NOTE_LINK_DOWN) sont fournies dans l'agrégat. En d'autres termes, lorsque toutes les liaisons externes affichent l'état de désactivation de liaison, les clients de niveau supérieur qui utilisent les couches MAC voient également les événements de désactivation de liaison. Lorsqu'une liaison externe sur le pont affiche l'état d'activation de liaison, tous les clients de niveau supérieur voient l'activation de liaison.
Ce rapport global sur l'activation et la désactivation des liaisons est élaboré pour les raisons suivantes :
Lorsque la désactivation de liaison s'affiche, les noeuds sur la liaison ne sont plus accessibles. Ce n'est pas vrai lorsque le code de pontage peut toujours envoyer et recevoir des paquets par le biais d'une autre liaison. Les applications d'administration qui nécessitent l'état réel des liaisons peuvent utiliser les statistiques du noyau sur la couche MAC pour révéler l'état. Ces applications sont différentes des clients ordinaires, comme IP, dans le sens où elles signalent des informations d'état matériel et qu'elles ne sont pas impliquées dans le processus de transfert.
Lorsque toutes les liaisons externes sont interrompues, l'état indique que le pont lui-même est fermé. Dans ce cas particulier, le système reconnaît qu'il est impossible d'accéder à quoi que ce soit. En contrepartie, les ponts ne peuvent pas être utilisés pour permettre des communications uniquement locales dans le cas où toutes les interfaces sont "réelles" (non virtuelles) et déconnectées.
Toutes les fonctions spécifiques aux liaisons sont généralisées. Les liaisons qui prennent en charge les fonctions spéciales d'accélération matérielle ne sont pas en mesure de les utiliser, car la détermination de la liaison de sortie réelle n'est pas entièrement effectuée par le client. La fonction de transfert de pont doit choisir une liaison de sortie en fonction de l'adresse MAC de destination, et cette liaison de sortie peut être n'importe quelle liaison sur le pont.
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.
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 :
Détermination du VLAN d'entrée. Cette tâche commence lorsqu'un paquet est reçu sur une liaison. Lorsqu'un paquet est reçu, une étiquette VLAN est recherchée. Si cette étiquette est absente ou s'il s'agit d'une étiquette uniquement de priorité (zéro), l'étiquette default_tag configurée sur cette liaison (si elle n'est pas définie sur zéro) sert d'étiquette VLAN interne. Si l'étiquette est absente ou définie sur zéro et que default_tag est définie sur zéro, le paquet est ignoré. Aucun transfert sans étiquette n'est réalisé. Si l'étiquette est présente et égale à default_tag, le paquet est également ignoré. Dans le cas contraire, l'étiquette d'entrée est considérée comme le VLAN d'entrée.
Vérification de l'appartenance de la liaison. Si le VLAN d'entrée n'est pas configuré comme un VLAN autorisé sur cette liaison, le paquet est ignoré. Le transfert est alors calculé, et la même vérification est effectuée pour la liaison de sortie.
Mise à jour d'étiquette. Si le VLAN (différent de zéro à ce stade) est égal à default_tag sur la liaison de sortie, l'étiquette sur le paquet (le cas échéant) est supprimée, indépendamment de la priorité. Si le VLAN n'est pas égal à default_tag sur la liaison de sortie, une balise est ajoutée, si elle n'est pas présente, et définie pour le paquet de sortie, la priorité actuelle étant copiée dans le paquet.
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.
Les exemples suivants montrent comment afficher des informations sur les configurations de pont et les services de pontage.
Vous pouvez obtenir des informations sur les ponts à l'aide de la commande suivante :
# dladm show-bridge BRIDGE PROTECT ADDRESS PRIORITY DESROOT tonowhere trill 32768/66:ca:b0:39:31:5d 32768 32768/66:ca:b0:39:31:5d sanluisrey stp 32768/ee:2:63:ed:41:94 32768 32768/ee:2:63:ed:41:94 pontoon trill 32768/56:db:46:be:b9:62 32768 32768/56:db:46:be:b9:62
Vous pouvez obtenir des informations sur le surnom TRILL d'un pont à l'aide de la commande suivante :
# dladm show-bridge -t tonowhere NICK FLAGS LINK NEXTHOP 38628 -- simblue2 56:db:46:be:b9:62 58753 L -- --