Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Multihébergement d’un système final connecté par Ethernet Conception et mise en œuvre

Pour obtenir une vue d’ensemble du multihébergement d’un système final connecté à Ethernet dans cette conception de référence, reportez-vous à la section Prise en charge du multihébergement pour les systèmes finaux connectés par Ethernet dans Composants de l’architecture de plan de la fabric de centre de données.

La figure 1 illustre le système terminal connecté en Ethernet multihébergement dans cette procédure :

Figure 1 : Exemple de présentation Ethernet-Connected Multihoming Example Overview du multihébergement connecté par Ethernet

Configuration d’un système final connecté en Ethernet multirésident à l’aide du multihébergement EVPN avec agrégation VLAN

Le multihébergement EVPN est utilisé dans ce bloc de construction pour connecter un système final connecté par Ethernet au réseau de superposition. Le multihébergement EVPN fonctionne en traitant deux ou plusieurs liaisons physiques multirésidents comme un seul segment Ethernet identifié par un ID de segment Ethernet (ESI) EVPN. L’ensemble des liaisons physiques appartenant au même segment Ethernet est traité comme une seule interface Ethernet agrégée. Les liens membres, à l’instar des liens membres d’une interface Ethernet agrégée traditionnelle, fournissent des chemins redondants vers et depuis le système final tout en garantissant que le trafic réseau superposé est équilibré en charge sur les différents chemins.

LACP avec le mode de minuterie rapide est utilisé pour améliorer la détection des défauts et la désactivation des membres d’un segment Ethernet altérés. MicroBFD peut également être utilisé pour améliorer encore l’isolation des pannes, mais peut ne pas être évolutif pour prendre en charge tous les ports orientés vers le système final. De plus, la prise en charge de microBFD doit exister au niveau du système final.

La conception de référence testait qu’un serveur connecté à Ethernet soit connecté à une seule branche ou multihébergé à 2 ou 3 périphériques à feuilles pour vérifier que le trafic peut être correctement traité dans les configurations multirésidentes avec plus de 2 périphériques à feuilles ; En pratique, un serveur connecté par Ethernet peut être multihébergé sur un grand nombre d’équipements de branche.

Pour configurer un serveur connecté en Ethernet multihébergement :

  1. (Interfaces Ethernet agrégées uniquement) Créez les interfaces Ethernet agrégées pour connecter chaque équipement Leaf au serveur. Activez LACP avec un intervalle de période rapide pour chaque interface Ethernet agrégée.

    Feuille 10 :

    Feuille 11 :

    Feuille 12 :

    Note:

    Les trois équipements Leaf de cette étape utilisent le même nom d’interface Ethernet agrégé (ae11) et les mêmes interfaces de liaison membre (et-0/0/13 et et-0/0/14) pour organiser et simplifier l’administration du réseau.

    Évitez d’utiliser des noms AE différents à chaque VTEP pour le même ESI, car cela nécessitera de configurer la clé d’administration LACP afin que le système final puisse identifier les liaisons multirésidents comme faisant partie du même LAG.
  2. Configurez chaque interface pour en faire une interface trunk. Attribuez des VLAN à chaque interface trunk.
    Note:

    Si vous connectez votre système final à l’équipement de branche à l’aide d’une seule liaison, remplacez le nom de l’interface (par exemple, —) ae11par un nom d’interface physique (par exemple, et-0/0/13—) pour le reste de cette procédure.

    Feuille 10 :

    Feuille 11 :

    Feuille 12 :

  3. Configurez les liaisons multirésidents à l’aide d’un ESI.

    Affectez chaque interface multirésidente au segment Ethernet, qui est identifié à l’aide de l’identifiant de segment Ethernet (ESI), qui héberge le serveur connecté par Ethernet. Assurez-vous que le trafic est transmis sur toutes les liaisons multirésidentes en configurant chaque liaison en tant que all-active.

    Les valeurs ESI doivent correspondre sur toutes les interfaces multirésidentes.

    Feuille 10 :

    Feuille 11 :

    Feuille 12 :

  4. Activez LACP et configurez un identificateur système.

    L’identificateur système LACP doit correspondre sur toutes les interfaces multirésidentes.

    Feuille 10 :

    Feuille 11 :

    Feuille 12 :

  5. Après avoir validé la configuration, vérifiez que les liens de chaque commutateur leaf sont dans l’état Up

    Exemple:

  6. Vérifiez que LACP est opérationnel sur les liaisons multirésidentes.

Activation de Storm Control

Le contrôle des tempêtes peut être activé dans le cadre de ce module. Le storm control est utilisé pour prévenir les tempêtes de trafic BUM en surveillant les niveaux de trafic BUM et en prenant une action spécifique pour limiter le transfert de trafic BUM lorsqu’un niveau de trafic spécifié, appelé niveau de storm control, est dépassé. Reportez-vous à la section Comprendre le contrôle des tempêtes pour plus d’informations sur la fonctionnalité.

Dans cette conception de référence, le contrôle de tempête est activé sur les interfaces Ethernet agrégées orientées serveur pour limiter le débit du trafic de diffusion, unicast inconnu et multicast (BUM). Si la quantité de trafic BUM dépasse 1 % de la bande passante disponible sur l’interface Ethernet agrégée, le storm control abandonne le trafic BUM pour éviter les tempêtes de diffusion.

Pour activer le storm control :

  1. Créez le profil storm control qui sera utilisé pour activer la fonctionnalité. Les interfaces configurées à l’aide du profil storm control sont spécifiées à cette étape.

    Dispositif Leaf :

  2. Définissez la configuration du storm control dans le profil.

    Dans cette conception de référence, le storm control est configuré pour interrompre stratégiquement le trafic BUM lorsque celui-ci dépasse 1 % de la bande passante d’interface disponible.

    Note:

    L’abandon du trafic BUM est la seule action de storm control prise en charge dans l’architecture Cloud Data Center.
    Note:

    Les paramètres de contrôle d’orage dans cette version de la conception de référence abandonnent le trafic multicast qui dépasse le seuil de contrôle d’orage configuré. Si votre réseau prend en charge des applications multicast, envisagez d’utiliser une configuration de storm control (telle que l’option no-multicast de l’instruction storm-control-profiles ) qui n’est pas représentée dans cette conception de référence.

    Les paramètres de storm control pour la prise en charge des applications multicast seront inclus dans une future version de cette conception de référence.
  3. Pour vérifier l’activité de storm control, filtrez les messages du journal système liés à storm control en entrant la show log messages | match storm commande.

Multihébergement d’un système final connecté par Ethernet - Historique des versions

Le Tableau 1 fournit un historique de toutes les caractéristiques de cette section et de leur prise en charge dans cette conception de référence.

Tableau 1 : Historique des versions

Libération

Description

19.1R2

Les commutateurs QFX10002-60C et QFX5120-32C exécutant Junos OS version 19.1R2 et ultérieures dans le même train de versions prennent en charge toutes les fonctionnalités documentées dans cette section.

18.4R2

Les commutateurs QFX5120-48Y exécutant Junos OS version 18.4R2 et les versions ultérieures dans le même train de versions prennent en charge toutes les fonctionnalités documentées dans cette section.

18.1R3-S3

QFX5110 commutateurs exécutant Junos OS version 18.1R3-S3 et les versions ultérieures dans le même train de versions prennent en charge toutes les fonctionnalités documentées dans cette section.

17.3R3-S1

Tous les équipements de la conception de référence qui prennent en charge Junos OS version 17.3R3-S1 et versions ultérieures dans le même train de versions prennent également en charge toutes les fonctionnalités documentées dans cette section.

Documentation connexe