Comprendre les priorités CoS et IEEE 802.1p pour des flux de trafic sans perte

Configuration des classes de transfert sans perte (attribut de perte de paquets)

La CLI de Junos inclut le paramètre no-loss pour la configuration des classes de transfert. Bien qu’il utilise le même nom, il ne s’agit pas de la classe de transfert par défaut sans perte. Le paramètre no-loss est un attribut de perte de paquet que vous pouvez spécifier pour configurer n’importe quelle classe de transfert en tant que classe de transfert sans perte.

Remarque :

Sur les commutateurs qui utilisent des classes de transfert différentes pour le trafic unicast et multidestination, la classe de transfert doit être une classe de transfert unicast. Sur les commutateurs qui utilisent les mêmes classes de transfert pour le trafic unicast et multidestination, seul le trafic unicast bénéficie d’un traitement sans perte.

Vous pouvez configurer jusqu’à six classes de transfert (en fonction de l’architecture système et de la disponibilité des ressources système) en tant que classes de transfert sans perte en incluant l’attribut no-loss drop au niveau de la [edit class-of-service forwarding-classes class forwarding-class-name queue-num queue-number] hiérarchie.

Si vous utilisez les classes de transfert fcoe ou no-loss par défaut, elles incluent par défaut l’attribut no-loss drop. Si vous configurez explicitement les classes de transfert fcoe ou no-loss et que vous souhaitez conserver leur comportement sans perte, vous devez inclure l’attribut no-loss drop dans la configuration.

Remarque :

Toutes les classes de transfert mappées à la même file d’attente de sortie doivent avoir le même attribut de perte de paquets. Toutes les classes de transfert mappées à la même file d’attente de sortie doivent être avec perte ou sans perte. Vous ne pouvez pas mapper à la fois une classe de transfert avec perte et une classe de transfert sans perte à la même file d’attente.

Pour éviter le partage de destin (un flux encombré affectant un flux non encombré), utilisez un mappage un-à-un des classes de transfert sans perte vers les points de code (priorités) et les files d’attente IEEE 802.1p. Mappez chaque classe de transfert sans perte à une file d’attente différente et classez le trafic entrant en classes de transfert de sorte que chaque classe de transfert ne transporte le trafic que d’une seule priorité (point de code).

Les classes de transfert fcoe et no-loss sont des cas particuliers, car dans la configuration par défaut, elles sont configurées pour un comportement sans perte (à condition que vous activiez également PFC sur les priorités mappées aux classes de transfert fcoe et no-loss dans la strophe d’entrée CNP).

Le Tableau 2 résume les configurations possibles des classes de transfert fcoe et sans perte. Le tableau fournit également le résultat de ces configurations en termes de comportement de trafic sans perte. Les configurations présentées supposent que PFC, DCBX et les classificateurs sont correctement configurés.

Pour toutes les autres classes de transfert, à l’exception des classes de transfert andno-loss, vous devez configurer explicitement le fcoe transport sans perte en spécifiant l’attribut no-loss packet drope, car la configuration par défaut de toutes les autres classes de transfert est avec perte.

Profils de notification de congestion (configuration PFC)

Utilisez CNP pour configurer les caractéristiques PFC sans perte sur les interfaces d’entrée et de sortie.

La strophe d’entrée d’un CNP active PFC sur des priorités IEEE 802.1p spécifiées (points de code) et affine les paramètres de mémoire tampon en configurant la valeur MRU et la longueur du câble sur les interfaces entrantes.

La strophe de sortie d’un CNP active le PFC (contrôle de flux) sur les files d’attente de sortie pour des priorités IEEE 802.1p spécifiées afin que les files d’attente puissent répondre aux messages de pause PFC de l’homologue connecté sur la priorité de votre choix. (Par défaut, les files d’attente de sortie 3 et 4 répondent aux messages PFC reçus lorsque ces files d’attente transportent un trafic sans perte dans les classes de transfert fcoe et no-loss, respectivement.)

Pour obtenir un transport sans perte, la priorité suspendue au niveau des interfaces entrantes doit correspondre à la priorité suspendue au niveau des interfaces de sortie pour un flux de trafic donné. Par exemple, si vous configurez des interfaces entrantes pour suspendre le trafic marqué avec la priorité 5 de l’IEEE 802.1p (point de code 101) et que le trafic de priorité 5 est mappé à la file d’attente de sortie 5, vous devez également configurer les interfaces de sortie correspondantes pour suspendre la priorité 5 dans la file d’attente 5. En outre, la classe de transfert mappée à la file d’attente 5 doit être configurée en tant que classe de transfert sans perte (à l’aide de l’attribut de suppression sans perte).

MISE EN GARDE :

Toute modification de la configuration PFC sur un port bloque temporairement l’intégralité du port (pas seulement les priorités affectées par la modification PFC) afin que le port puisse implémenter la modification, puis débloquer le port. Le blocage du port arrête le trafic entrant et sortant, et entraîne la perte de paquets sur toutes les files d’attente du port jusqu’à ce que le port soit débloqué.

Une modification de la configuration PFC désigne toute modification apportée à un CNP, y compris la modification de la partie d’entrée du CNP (activation ou désactivation du PFC en priorité, modification des valeurs MRU ou de longueur de câble) ou la modification de la partie de sortie du CNP qui active ou désactive le contrôle de flux de sortie sur une file d’attente. Une modification de la configuration PFC affecte uniquement les ports qui utilisent le CNP modifié.

Les actions suivantes modifient la configuration PFC :

• Suppression ou désactivation d’une configuration PFC (entrée ou sortie) dans un CNP utilisé sur une ou plusieurs interfaces. Par exemple :

  1. Un CNP existant avec une strophe d’entrée qui active le PFC sur les priorités 3, 5 et 6 est configuré sur les interfaces xe-0/0/20 et xe-0/0/21.

  2. Nous désactivons la configuration PFC pour la priorité 6 dans le CNP d’entrée, puis validons la configuration.

  3. La modification de configuration PFC entraîne l’arrêt de tout le trafic sur les interfaces xe-0/0/20 et xe-0/0/21 jusqu’à ce que la modification PFC ait été implémentée. Lorsque le changement de PFC a été implémenté, le trafic reprend.

• Configuration d’un CNP sur une interface. (Cela modifie l’état du PFC en activant le PFC sur une ou plusieurs priorités.)

• Suppression d’un CNP d’une interface. (Cela modifie l’état du PFC en désactivant le PFC sur une ou plusieurs priorités.)

Configuring Input Interface Flow Control (PFC and Headroom Buffer Calculation)

Sur les interfaces Ethernet, la strophe d’entrée du CNP active le PFC sur des priorités spécifiées afin que l’interface entrante puisse envoyer un message de pause à l’homologue connecté pendant les périodes de congestion. Les CNP d’entrée affinent également la marge de manœuvre utilisée pour la prise en charge des PFC en vous permettant de configurer la valeur MRU et la longueur du câble (si vous ne souhaitez pas utiliser la configuration par défaut).

Les tampons Headroom prennent en charge le transport sans perte en stockant le trafic qui arrive à une interface après que l’interface a envoyé un message de contrôle de flux PFC pour suspendre le trafic entrant. Tant que l’homologue connecté ne reçoit pas le message de contrôle de flux et suspend le trafic, l’interface continue de recevoir du trafic et doit le mettre en mémoire tampon (ainsi que le trafic toujours sur le réseau après la pause de l’homologue) pour éviter la perte de paquets.

Le système utilise la MRU et la longueur du câble physique connecté pour calculer l’allocation de la marge de manœuvre de la mémoire tampon. Les valeurs de configuration par défaut sont les suivantes :

• MRU pour le trafic de priorité 3 : 2 500 octets

• MRU pour le trafic de priorité 4 : 9 216 octets

• Longueur du câble : 100 mètres (environ 328 pieds)

Remarque :

Si vous configurez le contrôle de flux sur une priorité qui n’est pas l’une des priorités de contrôle de flux par défaut, la valeur MRU par défaut est de 2500 octets. Par exemple, si vous configurez le contrôle de flux sur la priorité 5 et que vous ne configurez pas explicitement une valeur MRU, la valeur MRU par défaut est de 2500 octets.

Vous pouvez affiner la MRU et la longueur du câble pour ajuster la taille de la mémoire tampon d’une interface. Le commutateur dispose d’un pool de mémoire tampon global partagé et alloue dynamiquement de l’espace tampon aux files d’attente sans perte si nécessaire.

Une MRU plus faible ou une longueur de câble plus courte réduit la quantité de mémoire tampon requise sur une interface et laisse plus d’espace de mémoire tampon pour les autres interfaces. Une MRU plus élevée ou une longueur de câble plus longue augmente l’espace tampon requis sur une interface et laisse moins d’espace tampon pour les autres interfaces.

Dans de nombreux cas, vous pouvez mieux utiliser les tampons de marge de manœuvre en réduisant la valeur MRU (par exemple, une MRU de 2180 est suffisante pour la plupart des réseaux FCoE) et en réduisant la valeur de longueur du câble si le câble physique mesure moins de 100 mètres de long.

Remarque :

Lorsque vous configurez les tampons de la marge de manœuvre en modifiant la MRU ou la longueur du câble, et que vous validez la configuration, le système effectue une vérification de validation et rejette la configuration si l’espace tampon n’est pas suffisant.

Cependant, le système n’effectue pas de vérification de validation mais renvoie à la place une erreur syslog si :

• Les tampons sont configurés sur une interface LAG.

• Le classificateur par défaut est utilisé sur l’interface (au lieu d’un classificateur configuré par l’utilisateur).

• L’interface n’a pas encore été créée.

Configuring Output Interface Flow Control (PFC)

Sur les interfaces Ethernet, vous pouvez utiliser la strophe de sortie du CNP pour configurer le contrôle de flux sur les files d’attente de sortie et activer la réponse de pause PFC sur les priorités IEEE 802.1p spécifiées.

Remarque :

Sur les commutateurs qui utilisent des files d’attente de sortie différentes pour le trafic unicast et multidestination, la file d’attente doit être une file d’attente de sortie unicast.

Par défaut, les files d’attente de sortie 3 et 4 sont activées pour la pause PFC sur les priorités 3 (point de code IEEE 802.1p 011) et 4 (point de code IEEE 802.1p 100). La réponse de pause PFC par défaut prend en charge la configuration de classe de transfert sans perte par défaut, qui mappe la classe de transfert fcoe à la file d’attente 3 et à la priorité 3, et mappe la classe de transfert sans perte à la file d’attente 4 et à la priorité 4.

La configuration du PFC sur les files d’attente de sortie vous permet de suspendre toute priorité sur n’importe quelle file d’attente de sortie sur n’importe quelle interface Ethernet. Le contrôle de flux de sortie vous permet d’utiliser plus de deux files d’attente de sortie pour prendre en charge les flux de trafic sans perte (vous pouvez configurer jusqu’à six classes de transfert sans perte et mapper ces classes de transfert sans perte à différentes files d’attente de sortie activées pour la pause PFC). Le contrôle de flux de file d’attente de sortie vous permet également de prendre en charge plusieurs classes de transfert sans perte (chacune mappée à une priorité et à une file d’attente de sortie différentes) pour une classe de trafic.

Remarque :

Le contrôle du flux de sortie ne fonctionne que lorsque PFC est activé dans la strophe d’entrée CNP sur les priorités correspondantes sur l’interface. Par exemple, si vous activez le contrôle du flux de sortie sur la priorité 5 (point de code 101 de l’IEEE 802.1p), vous devez également activer PFC dans le CNP sur la strophe d’entrée de priorité 5.

Par exemple, si le réseau Ethernet convergé utilise deux priorités différentes pour le trafic FCoE (par exemple, priorité 3 et priorité 5), vous pouvez classer ces priorités en différentes classes de transfert sans perte qui sont mappées à différentes files d’attente de sortie :

1. Configurez deux classes de transfert sans perte pour le trafic FCoE, chaque classe de transfert étant mappée à une file d’attente de sortie différente. Par exemple, vous pouvez utiliser la classe de transfert fcoe par défaut, qui est mappée à la file d’attente 3, et vous pouvez configurer une deuxième classe de transfert sans perte appelée fcoe1 et la mapper à la file d’attente 5. La classe de transfert fcoe est destinée au trafic FCoE de priorité 3 (point de code 011) et la classe de transfert fcoe1 est destinée au trafic FCoE de priorité 5 (point de code 101).

2. Configurez un classificateur qui mappe chaque classe de transfert au point de code IEEE 802.1p souhaité (priorité). Si le trafic FCoE sur les deux priorités utilise une interface, le classificateur doit classifier les deux classes de transfert selon les priorités correctes. Si un trafic FCoE de priorités différentes utilise différentes interfaces, la configuration du classificateur sur chaque interface doit mapper la priorité correcte à la classe de transfert sans perte correspondante.

3. Appliquez le classificateur aux interfaces qui transportent le trafic FCoE. Le classificateur détermine le mappage des classes de transfert aux priorités sur chaque interface.

Pour configurer le transport sans perte pour ces classes de transfert, vous devez également :

• Activez PFC sur les deux priorités (3 et 5 dans cet exemple) au niveau des interfaces entrantes dans la strophe d’entrée CNP.

• Configurez PFC sur les files d’attente de sortie et les priorités des classes de transfert dans la strophe de sortie CNP afin que l’interface puisse répondre aux messages de pause reçus de l’homologue connecté.

  Remarque :

  Lorsque vous configurez le CNP sur une interface, tout le trafic entrant et sortant est bloqué jusqu’à ce que la configuration soit implémentée, puis l’interface est débloquée et le trafic reprend. Pendant le blocage de l’interface, toutes les files d’attente de l’interface subissent une perte de paquets.

• Configurez DCBX pour échanger des TLV de protocole d’application sur les deux priorités FCoE.

Remarque :

Si vous ne configurez pas le contrôle de flux pour suspendre les files d’attente de sortie, la configuration par défaut utilise un mappage un-à-un des points de code IEEE 802.1p (priorités) aux files d’attente de sortie par numéro. Par exemple, la priorité 0 (point de code 000) est mappée à la file d’attente 0, la priorité 1 (point de code 001) est mappée à la file d’attente 1, et ainsi de suite. Par défaut, seules les files d’attente 3 et 4 sont activées pour répondre aux messages de pause de l’homologue connecté, et vous devez explicitement activer PFC sur les priorités correspondantes dans la strophe d’entrée CNP pour obtenir un comportement sans perte.

Si vous n’utilisez pas la configuration par défaut, vous devez configurer explicitement le contrôle de flux sur chaque file d’attente de sortie que vous souhaitez activer pour la pause PFC. Par exemple, si vous configurez explicitement le contrôle de flux sur la file d’attente de sortie 5, la configuration par défaut n’est plus valide et seule la file d’attente de sortie 5 est activée pour la pause PFC. Les files d’attente de sortie 3 et 4 ne sont plus activées pour la pause PFC, de sorte que le trafic utilisant ces files d’attente ne répond plus aux messages de pause PFC même si la classe de transfert correspondante est configurée avec l’attribut no-loss drop. Pour conserver la configuration de pause sur les files d’attente de sortie 3 et 4 et configurer le contrôle de flux sur la file d’attente 5, vous devez configurer explicitement le contrôle de flux sur les files d’attente 3, 4 et 5.

Sur les commutateurs qui utilisent des files d’attente de sortie différentes pour le trafic unicast et multidestination, vous ne pouvez pas configurer le contrôle de flux pour suspendre une file d’attente de sortie multidestination. Vous pouvez configurer le contrôle de flux pour suspendre uniquement les files d’attente de sortie unicast. Sur les commutateurs qui utilisent les mêmes files d’attente de sortie pour le trafic unicast et multidestination, seul le trafic unicast bénéficie d’un traitement sans perte.

Output Interface Flow Control Profiles

La configuration de la strophe de sortie CNP crée un profil de contrôle de flux de sortie qui indique aux ports de sortie les files d’attente sur lesquelles l’interface Ethernet doit répondre aux messages de pause PFC.

Le système dispose d’un profil de contrôle de flux de sortie par défaut qui est appliqué à toutes les interfaces Ethernet lorsque le CNP connecté à l’interface n’a qu’une strophe d’entrée et n’inclut pas de strophe de sortie. Le profil par défaut répond aux messages de pause PFC reçus sur la file d’attente 3 (pour la priorité 3, pour la classe de transfert fcoe par défaut) et sur la file d’attente 4 (pour la priorité 4, pour la classe de transfert sans perte par défaut), et n’est effectif que si PFC est configuré sur ces priorités dans la strophe d’entrée CNP.

En outre, le système dispose de deux profils internes de contrôle de flux de sortie qu’il applique automatiquement aux ports de fabric (FTE) et aux interfaces FC natives (NP_Ports).

Comme un CNP de sortie peut configurer la réponse de pause PFC sur plusieurs files d’attente de sortie (priorités), un CNP de sortie configurable par l’utilisateur est généralement suffisamment flexible pour spécifier la réponse PFC souhaitée sur toutes les interfaces programmées.

Remarque :

Chaque port peut utiliser un profil de contrôle de flux de sortie. Vous ne pouvez pas appliquer plusieurs profils à un port.

Les profils de contrôle de flux de sortie peuvent être exprimés sous forme de tableau. Par exemple, le Tableau 3 montre le profil de contrôle de flux de sortie par défaut qui suspend les priorités 3 et 4 sur les files d’attente 3 et 4 (rappelez-vous que PFC doit également être activé sur les points de code 3 et 4 de la strophe d’entrée CNP pour que PFC fonctionne) :

Le Tableau 4 est un exemple de profil de contrôle de flux de sortie configuré par l’utilisateur. En utilisant l’exemple de la section précédente, la strophe de sortie CNP configure le contrôle de flux sur la file d’attente de sortie 5 et configure également explicitement le contrôle de flux de sortie sur les files d’attente 3 et 4 pour les classes de transfert fcoe et sans perte. (Si vous configurez explicitement un CNP de sortie, vous devez configurer explicitement chaque file d’attente de sortie pour laquelle vous souhaitez répondre aux messages PFC, car le profil configuré par l’utilisateur remplace le profil par défaut. Si cet exemple n’incluait pas les files d’attente 3 et 4, ces files d’attente ne répondraient plus aux messages PFC reçus.)

N’oubliez pas que vous devez également activer PFC sur les points de code 3, 4 et 5 de la strophe d’entrée CNP pour que cette configuration fonctionne. Lorsque vous configurez le CNP sur une interface, tout le trafic entrant et sortant est bloqué jusqu’à ce que la configuration soit implémentée, puis l’interface est débloquée et le trafic reprend. Pendant le blocage de l’interface, toutes les files d’attente de l’interface subissent une perte de paquets.

Configuring PFC Across Layer 3 Interfaces

L’activation du PFC sur les flux de trafic est basée sur le point de code IEEE 802.1p (priorité) dans le champ PCP (priority code point) de l’en-tête de trame Ethernet (parfois appelé bits CoS). Pour activer le PFC sur le trafic qui traverse des interfaces L3, le trafic doit être classé par son point de code IEEE 802.1p, et non par son point de code DSCP (ou DSCP IPv6).

Consultez Comprendre la fonctionnalité PFC sur les interfaces de couche 3 pour obtenir un aperçu conceptuel de l’activation du PFC sur le trafic sur les interfaces L3. Voir Exemple : Configuration de PFC sur des interfaces de couche 3 pour obtenir un exemple de configuration de PFC sur le trafic qui traverse des interfaces L3.

Configuration du DCBX (Application Protocol TLV Exchange)

Pour les applications qui nécessitent un transport sans perte, DCBX échange des TLV de protocole d’application avec l’interface homologue connectée. Par défaut, DCBX annonce les TLV du protocole d’application FCoE sur toutes les interfaces activées pour DCBX, et par défaut, DCBX est activé sur toutes les interfaces. Par défaut, DCBX ne publie aucune autre application.

Pour chaque application (par exemple, iSCSI) que vous souhaitez configurer pour un transport sans perte, vous devez permettre aux interfaces qui transportent ce trafic d’application d’échanger des TLV de protocole DCBX avec l’homologue connecté. L’échange TLV permet aux interfaces homologues de négocier une configuration compatible pour prendre en charge l’application.

Si vous configurez DCBX pour publier une application, la publication DCBX par défaut est remplacée et DCBX publie uniquement les applications configurées. Si vous souhaitez qu’une interface annonce uniquement l’application FCoE, vous n’avez pas besoin de configurer l’échange TLV du protocole d’application DCBX ; à la place, vous pouvez utiliser la configuration par défaut.

Si vous souhaitez que DCBX annonce d’autres applications, vous devez configurer explicitement un mappage d’application et l’appliquer aux interfaces sur lesquelles vous souhaitez échanger des TLV de protocole pour ces applications. Si vous souhaitez échanger des TLV de protocole d’application FCoE en plus d’autres TLV de protocole d’application, vous devez également configurer explicitement l’application FCoE dans le mappage d’application. Présentation du protocole d’application DCBX TLV Exchange décrit le fonctionnement du mappage des applications.

Remarque :

Le transport sans perte nécessite également que vous activiez PFC sur la priorité correcte (point de code IEEE 802.1p) sur les interfaces entrantes à l’aide d’un CNP d’entrée. Si la priorité que vous interrompez au niveau des interfaces entrantes n’est pas mappée à la file d’attente 3 ou 4 (les deux files d’attente de sortie activées par défaut pour le contrôle de flux de pause PFC), vous devez également activer la suspension des files d’attente de sortie qui correspondent aux priorités d’entrée suspendues à l’aide de la strophe de sortie du CNP.

Fate Sharing entre les classes de trafic

Vous pouvez configurer différents flux de trafic sans perte (ou avec perte) pour partager le destin, c’est-à-dire pour recevoir le même traitement CoS.

Le partage du destin n’est pas souhaitable pour la convergence des E/S. Au lieu d’un contrôle indépendant du sort de chaque type d’écoulement, différents types d’écoulements reçoivent le même traitement. Le partage du destin est particulièrement indésirable pour les flux sans perte. Si un flux sans perte subit une congestion et doit être suspendu, cela affecte les flux qui partagent le destin avec le flux encombré, même si les autres flux ne subissent pas de congestion, et peut également provoquer une congestion des ports entrants. Si votre réseau exige que toutes les priorités 802.1p soient sans perte, vous pouvez y parvenir en permettant un certain partage du destin entre les huit priorités en les répartissant sur un maximum de six classes de transfert sans perte.

Si le nombre de priorités sans perte est inférieur ou égal au nombre de classes de transfert sans perte configurées, vous pouvez éviter le partage du destin en configurant un mappage un-à-un des classes de transfert vers les points de code (priorités) et les files d’attente de sortie IEEE 802.1p. (Chaque classe de transfert doit être mappée à une file d’attente de sortie différente et classée selon une priorité différente.)

Si vous souhaitez configurer différents flux de trafic pour partager le destin, deux configurations de partage du destin sont prises en charge : mapper une classe de transfert à plusieurs points de code IEEE 802.1p (priorité) et mapper deux classes de transfert à la même file d’attente de sortie :

1. Si vous mappez une classe de transfert sans perte à plusieurs priorités, le trafic balisé avec chacune des priorités utilise les mêmes propriétés CoS associées (les propriétés CoS associées à la classe de transfert). Par exemple, la configuration d’une classe de transfert appelée fc1, son mappage à la file d’attente 1 et son mappage aux points de code 101 et 110 à l’aide d’un classificateur nommé classify1 entraîne le partage du destin du trafic étiqueté avec les priorités 101 et 110 :

   Dans ce cas, si le trafic mappé à l’une ou l’autre des priorités subit une congestion, les deux priorités sont suspendues car elles sont mappées à la même classe de transfert et sont donc traitées de la même manière.

2. Si vous mappez plusieurs classes de transfert sans perte à la même file d’attente de sortie, le trafic mappé aux classes de transfert utilise la même file d’attente de sortie. Cela augmente la quantité de trafic sur la file d’attente et peut créer une congestion qui affecte tous les flux de trafic mappés à la file d’attente. Par exemple, la configuration de deux classes de transfert appelées fc1 et fc2, le mappage des deux classes de transfert à la file d’attente 1 et le mappage des classes de transfert aux points de code 101 et 110 (respectivement) à l’aide d’un classificateur nommé classify1, entraîne le partage du destin du trafic balisé avec les priorités 101 et 110 sur la même file d’attente de sortie :

   Dans ce cas, même si les deux classes de transfert utilisent des priorités IEEE 802.1p différentes, si une classe de transfert subit une congestion, cela affecte l’autre classe de transfert. La raison en est que si la file d’attente de sortie est suspendue en raison d’une congestion sur l’une ou l’autre classe de transfert, tout le trafic qui utilise cette file d’attente est suspendu. Étant donné que les deux classes de transfert sont mappées à la file d’attente, le trafic mappé aux deux classes de transfert est suspendu.

   Remarque :

   Si vous mappez plusieurs classes de transfert à une file d’attente, toutes les classes de transfert mappées à la même file d’attente doivent avoir le même attribut de perte de paquets (toutes les classes de transfert doivent être avec perte, ou toutes les classes de transfert mappées à une file d’attente doivent être sans perte).

Configuration du commutateur de transit et configuration de la passerelle FCoE-FC

Sur un commutateur de transit (tous les ports Ethernet, pas de ports FC natifs) qui transfère le trafic FCoE (ou tout autre trafic qui nécessite un transport sans perte sur le réseau Ethernet), la configuration des classificateurs, des classes de transfert sans perte, DCBX et PFC sur les interfaces entrantes et sortantes pour prendre en charge le transport sans perte est décrite dans ce document.

Lorsqu’un commutateur joue le rôle de passerelle FCoE-FC (si des interfaces FC natives sont prises en charge sur votre commutateur), le système utilise des interfaces FC natives (NP_Ports) pour se connecter au commutateur FC (ou au redirecteur FCoE) à la périphérie FC du réseau. Vous ne pouvez pas appliquer CNP ou DCBX aux interfaces FC natives, mais uniquement aux interfaces Ethernet.

Sur une passerelle FCoE-FC, la configuration de l’interface Ethernet des classificateurs, DCBX et PFC est la même que celle d’un commutateur de transit. La configuration des classes de transfert sans perte est également la même.

Toutefois, la prise en charge du transport sans perte sur les interfaces FC natives nécessite que vous réécriviez la valeur de priorité IEEE 802.1p si votre réseau utilise une priorité autre que 3 (point de code IEEE 011) pour le trafic FCoE. Si votre réseau utilise la priorité 3 pour le trafic FCoE, vous pouvez et devez utiliser la configuration par défaut sur les interfaces FC natives.

Par défaut, les interfaces FC natives balisent les paquets avec la priorité 3 lorsqu’elles encapsulent les paquets FC entrants dans Ethernet. Si votre réseau FCoE utilise une priorité différente de 3 pour le trafic FCoE, vous devez réécrire la valeur de priorité à la valeur que votre réseau utilise sur l’interface FC, classer le trafic FCoE dans la priorité correcte sur les interfaces Ethernet et activer PFC sur la priorité correcte sur les interfaces Ethernet, comme décrit dans Présentation du remappage de priorité CoS IEEE 802.1p sur une passerelle FCoE-FC.

Résultats de la configuration et vérifications de validation

Les différentes configurations des classes de transfert et de leurs attributs de perte, des classificateurs, des CNP (contrôle de flux PFC) et du contrôle de flux Ethernet PAUSE (contrôle de flux IEEE 802.3X) entraînent des comportements différents du système.

Le Tableau 5 décrit les résultats des configurations de transport sans perte possibles dans chaque cas. Dans la colonne Résultat , on suppose que le calcul de la marge de mémoire tampon du système a abouti à une configuration réussie.

Toutefois, si le système calcule qu’il n’y a pas suffisamment d’espace tampon pour prendre en charge la configuration, une vérification de validation vous empêche de valider la configuration sur une interface Ethernet individuelle. Pour les interfaces LAG, le système n’émet pas d’erreur de vérification de validation mais émet à la place un message syslog.

Remarque :

Après avoir configuré le transport sans perte pour une interface LAG, vérifiez les messages syslog pour confirmer que la validation a réussi.

Remarque :

Si vous essayez de configurer à la fois PFC et Ethernet PAUSE sur une liaison, le système renvoie une erreur de validation. PFC et Ethernet PAUSE sont des configurations mutuellement exclusives sur une interface.