Présentation du pontage

Les ponts permettent de connecter des segments de réseau distincts, qui eux-mêmes relient des noeuds. 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 transfert de paquets pour connecter des sous-réseaux.

Bien que le pontage et le routage puissent être utilisés pour distribuer des informations sur l'emplacement des ressources réseau, ces techniques diffèrent en plusieurs points. 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 réseau ponté. Au fil du temps, tous les ponts au sein du réseau "apprennent" quelle liaison 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 paquets vers la liaison est interrompu et toutes ses entrées sont supprimées. Les anciennes entrées de transfert sont également vidées à intervalle régulier. 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 la mise en oeuvre des protocoles STP et RSTP (Rapid Spanning Tree Protocol) pour les ponts, Oracle Solaris prend en charge l'amélioration de la protection TRILL (Transparent Interconnection of Lots of Links). 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 noeuds par le biais de protocoles réseau (comme IP) et non de 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.

Figure 4-1 Réseau ponté simple

Le schéma ci-dessus illustre une configuration de réseau ponté simple. Le pont goldengate est un système Oracle Solaris configuré avec les fonctionnalités de pontage. 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.

Il est possible de former des réseaux pontés en anneau qui relient 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.

Le schéma suivant illustre un réseau ponté configuré en anneau. La configuration présente trois ponts. Deux systèmes sont connectés physiquement au pont westminster. Un système est connecté physiquement au pont waterloo. Enfin, un système est connecté physiquement au pont tower. Les ponts sont connectés physiquement les uns aux autres par le biais de ports.

Figure 4-2 Réseau ponté en anneau

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 transférer des paquets. Dans la Figure 4-2, 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 de liaisons utilisées. 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.

---

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

---

---

Attention - Ne configurez pas une liaison dans un pont lorsque les plus hauts niveaux de performances sont requis. Le pontage implique que les interfaces sous-jacentes soient en mode de promiscuité, ce qui désactive un grand nombre d'optimisations importantes, notamment dans les couches de matériel et pilote 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 ont une incidence uniquement 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

Vous pouvez répertorier les propriétés de liaison suivantes par le biais de la commande dladm show-linkprop. Pour les modifier, exécutez les commandes dladm set-linkprop et reset-linkprop.

default_tag

Définit l'ID de VLAN par défaut des paquets sans étiquette envoyés depuis et vers une 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 le transfert de paquets sans étiquette depuis et vers le port. (Il s'agit d'une propriété MAC.)

---

Remarque - Dans un autre contexte que le pontage, cette propriété permet de 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.

Par exemple, si le PVID est défini sur 5 sur net0, vous ne pouvez en aucun cas créer de VLAN portant l'ID 5 sur net0. Pour définir le VLAN 5 dans cette situation, utilisez net1.

Vous ne pouvez pas définir la propriété default_tag de sorte qu'elle soit égale à l'ID d'un VLAN existant créé sur cette liaison. Par exemple, la commande suivante crée le 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 ou désactive le transfert 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. Lorsque le transfert de trafic 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 ou 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. Lorsque cette propriété est définie sur 0, la liaison n'utilise pas le protocole STP ou RSTP et elle est toujours placée en mode de transfert. 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 de 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 cette propriété est définie sur 0, le démon part du principe que le port est connecté à d'autres ponts, même si aucune BPDU d'aucun type n'est détectée.

stp_p2p

Spécifie le type de 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 pour appliquer le mode point à point. 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é de port STP et RSTP permet de déterminer le port root préféré d'un pont en ajoutant la valeur au début du PVID. La priorité est d'autant plus élevée que la valeur numérique est petite.

Démon STP

Chaque pont créé à l'aide de la commande dladm create-bridge est représenté comme une instance de service de l'utilitaire de gestion des services (SMF) qui porte le même nom (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 ci-dessous crée un pont nommé pontevecchio :

# dladm create-bridge pontevecchio

Le système crée une instance de service SMF nommée svc:/network/bridge:pontevecchio et un noeud d'observabilité nommé /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 de logique transistor-transistor (TTL) sur les paquets, toutes les boucles de ce type sont fatales pour le réseau.

Si un port particulier n'est pas connecté à un autre pont (car le port établit une connexion point à point directe à un système hôte, par exemple), vous pouvez désactiver administrativement STP sur 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 lorsqu'elle 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 ci-dessous crée un pont nommé 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.

Le noeud d'observabilité est destiné à être utilisé avec les utilitaires snoop et wireshark. Ce noeud fonctionne comme une interface Ethernet classique, à cette exception près que les paquets sont silencieusement rejetés lors de leur transmission. Vous ne pouvez pas raccorder 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é met une seule copie non modifiée de chaque paquet traité par le pont à la disposition de l'utilisateur en vue d'effectuer des opérations de surveillance et de dépannage. Ce comportement est similaire à celui d'un port de surveillance sur un pont traditionnel. Il est soumis aux règles habituelles de mode de promiscuité DLPI (Data Link Provider Interface). Vous pouvez exécuter la commande pfmod ou les fonctions des utilitaires snoop et wireshark pour filtrer les paquets en fonction de l'ID de VLAN.

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

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é.

Vous pouvez également obtenir les statistiques relatives à l'utilisation des ressources réseau par les paquets sur les liaisons en exécutant la commande dlstat. Pour plus d'informations, reportez-vous au Chapitre 4, Contrôle du trafic réseau et de l’utilisation des ressources dans Oracle Solaris du manuel Utilisation de réseaux virtuels dans Oracle Solaris 11.1.

Modification du comportement des liaisons en présence de ponts

Les sections suivantes décrivent en quoi le comportement des liaisons est modifié lorsque des ponts sont inclus dans une configuration réseau.

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

Comportement des DLPI

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 link-down, 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 link-up, tous les clients de niveau supérieur voient les événements d'activation de liaison.

  Ce rapport global sur l'activation et la désactivation des liaisons est élaboré pour les raisons suivantes :

  • Lorsque l'état link-down 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 au niveau de la couche MAC pour révéler l'état. Ces applications sont différentes des clients ordinaires (comme IP) dans ce sens qu'elles signalent des informations d'état matériel et ne sont pas impliquées dans le processus de transfert de paquets.

  • Lorsque toutes les liaisons externes sont interrompues, l'état indique que le pont lui-même est hors service. Dans ce cas particulier, le système reconnaît qu'il est impossible d'accéder à quelque noeud que ce soit. En contrepartie, les ponts ne peuvent pas être utilisés pour autoriser des communications exclusivement locales dans le cas où toutes les interfaces sont "réelles" (et non virtuelles), et toutes les liaisons sont 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.

Administration des VLAN sur les réseaux pontés

Par défaut, les VLAN configurés sur le système répartissent les paquets sur tous les ports définis 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 des paquets du VLAN spécifié sur cette liaison de pont.

Pour configurer un VLAN sur une liaison et désactiver le transfert de paquets vers ou à partir d'autres liaisons sur le pont, il faut désactiver le transfert en définissant la propriété forward du VLAN 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 par le protocole STP conforme aux normes. Le protocole de pontage calcule une seule topologie sans boucle à l'aide de messages BPDU sans étiquette et utilise cette topologie arborescente 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 impérativement exécuter tous les VLAN en tout point de votre infrastructure de ponts ou examiner soigneusement toutes les liaisons redondantes.

Le protocole TRILL ne suit pas les règles STP complexes. Au contraire, TRILL encapsule automatiquement les paquets dont l'étiquette VLAN est intacte et les transmet via le réseau. En d'autres termes, TRILL relie les VLAN isolés lorsque le même ID de VLAN a été réutilisé au sein d'un seul réseau ponté.

Il s'agit d'une différence importante par rapport à STP, étant donné que vous pouvez réutiliser des étiquettes VLAN dans des sections isolées du réseau pour gérer des ensembles de VLAN dépassant la limite de 4094. TRILL ne permet pas de gérer les réseaux de cette manière, mais 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 compensée par la robustesse du modèle TRILL.

Comportement des VLAN

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

1. Détermination du VLAN d'entrée. Ce processus débute lorsqu'un paquet entrant est reçu par le système 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 de priorité uniquement (définie sur zéro), la valeur de la propriété 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é. En présence d'une étiquette égale à la valeur default_tag, le paquet est également ignoré. Autrement, l'étiquette est considérée comme le paquet VLAN entrant.

2. Vérification de l'appartenance de la liaison. Si le VLAN d'entrée n'est pas configuré comme 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.

3. Mise à jour d'étiquettes. Si l'étiquette VLAN (différente de zéro à ce stade) est identique à la valeur default_tag sur la liaison de sortie, l'étiquette du paquet (le cas échéant) est supprimée, indépendamment de la priorité. Si le VLAN n'est pas égal à la valeur default_tag sur la liaison de sortie, une étiquette est ajoutée (le cas échéant) et définie pour le paquet sortant, la priorité actuelle étant copiée dans le paquet.

Affichage des configurations de pont

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

• Vous pouvez afficher des informations sur les ponts en exécutant 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 afficher des informations sur le pseudonyme TRILL d'un pont en exécutant la commande suivante :

  # dladm show-bridge -t tonowhere
  NICK FLAGS LINK        NEXTHOP
  38628 --   simblue2    56:db:46:be:b9:62
  58753 L    --          --