Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Prise en charge du filtrage MAC, du storm control et de la mise en miroir des ports dans un environnement EVPN-VXLAN

Nous prenons en charge le filtrage MAC, le storm control, ainsi que la mise en miroir et l’analyse des ports dans un réseau de superposition Ethernet VPN-VXLAN (EVPN-VXLAN).

Nous prenons en charge chacune de ces fonctionnalités en utilisant le style d’entreprise pour la configuration de l’interface.

Ces fonctionnalités sont également prises en charge en utilisant le style fournisseur de services (SP) pour la configuration de l’interface, avec certaines limitations :

  • Nous prenons en charge la mise en miroir des ports avec un filtre de pare-feu dans le sens d’entrée en utilisant la configuration d’interface de style SP, mais pas dans le sens de sortie.

  • Nous ne prenons en charge le storm control que sur une seule interface logique dans les configurations d’interface physique de type SP. Vous ne pouvez pas configurer le storm control sur plusieurs interfaces logiques avec des configurations de type SP.

    • En raison de limitations matérielles, le contrôle de tempête appliqué à une interface logique s’applique également à l’interface physique sous-jacente.

    • L’interface logique avec le contrôle d’orage configuré enregistre l’orage, mais n’importe quelle interface logique sur l’interface physique peut déclencher le contrôle d’orage.

Ces fonctionnalités ne sont prises en charge que dans une superposition ERB (Edge-Route Bridging) EVPN-VXLAN, également appelée topologie EVPN-VXLAN avec une fabric IP réduite. Ce réseau de superposition comprend les composants suivants :

  • Une seule couche de commutateurs Juniper Networks (par exemple, des commutateurs QFX10002, QFX5120 ou QFX5110), chacun d’entre eux fonctionnant à la fois comme un équipement de branche équipement Spine de couche 3 et de couche 2.

  • Périphériques de périphérie client (CE) qui sont monohoming ou multihoming en mode actif/actif vers les équipements spine-leaf.

Note:

EVPN-VXLAN prend en charge la mise en miroir des ports locaux et distants sur certaines plates-formes :

  • local : les paquets sont mis en miroir vers une destination sur le même périphérique.

  • remote : les paquets sont mis en miroir vers une destination sur un périphérique distant.

Si vous souhaitez utiliser la mise en miroir de ports distants avec EVPN-VXLAN, consultez la page de l’explorateur de fonctionnalités pour la mise en miroir de ports à distance avec encapsulation VXLAN pour voir les plates-formes et les versions prises en charge.

Pour plus d’informations sur la mise en miroir de ports locaux ou distants avec EVPN-VXLAN, reportez-vous à la section Mise en miroir de ports et analyseurs de ports.

Cette rubrique comprend les informations suivantes :

Avantages du filtrage MAC, du Storm Control et de la mise en miroir des ports dans un environnement EVPN-VXLAN

  • Le filtrage MAC vous permet de filtrer et d’accepter les paquets provenant d’interfaces CE entrantes, réduisant ainsi le volume d’adresses MAC associées dans la table de commutation Ethernet et le trafic dans un VXLAN.

  • Le contrôle de tempête vous permet de surveiller les niveaux de trafic sur les interfaces EVPN-VXLAN et, en cas de dépassement d’un niveau de trafic spécifié, de supprimer les paquets BUM (unicast inconnus) et sur certains commutateurs Juniper Networks, de désactiver l’interface pendant une durée spécifiée. Cette fonctionnalité permet d’éviter qu’un trafic excessif ne dégrade le réseau.

  • Dans un environnement EVPN-VXLAN, la mise en miroir de ports et les analyseurs vous permettent d’analyser le trafic jusqu’au niveau des paquets. Vous pouvez utiliser cette fonctionnalité pour appliquer des stratégies relatives à l’utilisation du réseau et au partage de fichiers, et pour identifier les sources de problèmes en localisant l’utilisation anormale ou importante de la bande passante par des stations ou des applications particulières.

Filtrage MAC

Le filtrage MAC vous permet de filtrer les adresses MAC et d’accepter le trafic. Cette fonctionnalité n’est compatible que sur les interfaces CE entrantes, c’est-à-dire les interfaces sur lesquelles l’encapsulation VXLAN n’est généralement pas activée. Pour utiliser cette fonctionnalité, vous devez effectuer les opérations suivantes :

  • Créez un filtre de pare-feu dans lequel vous spécifiez une ou plusieurs des conditions de correspondance prises en charge dans les tableaux 1 et 2.

  • Appliquez le filtre de pare-feu à une interface de couche 2 configurée dans la [edit interfaces interface-name unit logical-unit-number family ethernet-switching filter] hiérarchie.

Tableau 1 : conditions de correspondance prises en charge sur les commutateurs QFX5100 et QFX5110

Match Conditions

Prise en charge du filtre d’entrée d’interface

Prise en charge du filtre de sortie de l’interface

Adresse MAC source

X

X

Adresse MAC de destination

X

X

ID VLAN utilisateur

X

X

Port source

X

Port de destination

X

Type d’éther

X

Protocole IP

X

Priorité IP

X

Codes ICMP

X

Indicateurs TCP

X

Adresse IP

X

Note:

Dans Junos OS version 18.4R1, les commutateurs QFX5100 et QFX5110 prennent en charge le filtrage MAC uniquement sur une interface. De plus, à partir de Junos OS version 18.4R2 et ultérieures, les commutateurs QFX5100, QFX5110, QFX5120-48Y et EX4650-48Y prennent également en charge le filtrage MAC sur un VLAN mappé par VXLAN. Junos OS version 22.2 inclut la prise en charge du filtrage Mac et de la correspondance VNI de transit pour l’underlay IPv6 pur sur les appareils QFX10002, QFX10008 et QFX10016.
Tableau 2 : conditions de correspondance prises en charge sur les commutateurs QFX10000

Match Conditions

Prise en charge du filtre d’entrée d’interface

Prise en charge du filtre de sortie de l’interface

Adresse MAC source

X

Adresse MAC de destination

X

ID VLAN utilisateur

Port source

X

X

Port de destination

X

X

Type d’éther

X

X

Protocole IP

X

Priorité IP

X

X

Codes ICMP

X

X

Indicateurs TCP

X

X

Adresse IP

X

X
Note:

Lorsque vous configurez des filtres MAC sur QFX10000 commutateurs, gardez à l’esprit les points suivants :

  • Vous ne pouvez appliquer un filtre qu’à une interface. Vous ne pouvez pas appliquer de filtre à un VLAN mappé.

  • Nous ne prenons pas en charge une combinaison de conditions de correspondance de couche 2 et de conditions de correspondance de couche 3/couche 4 dans le même filtre de pare-feu. Par exemple, si vous incluez des conditions de correspondance du adresse MAC source et du port source dans le même filtre de pare-feu sur un commutateur QFX10002, le filtre de pare-feu ne fonctionnera pas.

  • Nous ne prenons pas en charge la condition de correspondance de l’ID VLAN de l’utilisateur. Par conséquent, si vous devez filtrer des interfaces logiques, chacune d’entre elles étant mappée à un VLAN particulier, vous devez utiliser le style de configuration du fournisseur de services lors de la configuration de l’interface physique et des interfaces logiques associées. Après avoir créé un filtre de pare-feu, vous devez l’appliquer à chaque interface logique pour obtenir l’effet de la condition de correspondance de l’ID VLAN de l’utilisateur.

  • La version 22.2 de Junos OS prend également en charge la correspondance des ID de réseau VNI (VNI) VxLAN sur les en-têtes extérieurs IP source/destination pour le trafic de transit sur une interface de couche 3 pour les périphériques QFX10002, QFX10008 et QFX10016. Les correspondances VNI sont effectuées uniquement sur les en-têtes externes et sur le trafic entrant. Sur les périphériques de transit qui acheminent les paquets de tunnel, le filtrage MAC doit prendre en charge la correspondance du VNI dans l’en-tête externe, ainsi que les adresses IPv6 source et de destination de l’en-tête externe comme conditions de correspondance. Utilisez le filtre de correspondance VNI sous l’option CLI de correspondance vxlan pour le set firewall family inet6 filter terme de la <vxlan [vni <vni-id>]> commande. Utilisez la commande pour afficher les show firewall filter statistiques.

À l’aide du filtre de pare-feu, vous spécifiez les adresses MAC associées à un VXLAN qui sont autorisées sur une interface particulière.

Note:

Une fois que vous avez appliqué le filtre de pare-feu à une interface de couche 2, l’interface réside sous l’instance de commutateur par défaut.

L’exemple de configuration suivant sur un commutateur QFX5110 crée un filtre de pare-feu nommé DHCP-Discover-In qui accepte et compte le trafic entrant qui répond à plusieurs conditions de correspondance (adresse MAC source, adresse MAC de destination, ports de destination et ID de VLAN) sur l’interface logique de couche 2 xe-0/0/6.0 :

Storm Control

Par défaut, le storm control est activé sur les commutateurs QFX et EX pour les interfaces de couche 2 associées à des VXLAN. Le niveau de contrôle des tempêtes est fixé à 80 % des flux de trafic BUM combinés.

Note:

Le storm control EVPN-VXLAN fonctionne un peu différemment sur les plateformes ACX Series. Pour plus de détails, voir Présentation de Storm Control sur les routeurs ACX Series.

Dans un environnement EVPN-VXLAN, le storm control est implémenté et configuré sur les interfaces de couche 2 associées aux VXLAN de la même manière que dans un environnement non-EVPN-VXLAN, à l’exception des différences suivantes :

  • Dans un environnement EVPN-VXLAN, les types de trafic surveillés par le storm control sont les suivants :

    • Trafic BUM de couche 2 provenant d’un VXLAN et transféré vers des interfaces au sein de ce même VXLAN.

    • Trafic multicast de couche 3 reçu par une interface IRB (Integrated Routing and Bridging) dans un VXLAN et transféré vers les interfaces d’un autre VXLAN.

  • Après avoir créé un profil de contrôle de tempête, vous devez le lier à une interface de couche 2 d’entrée au niveau de la [edit interfaces interface-name unit logical-unit-number family ethernet-switching] hiérarchie.

    Note:

    Une fois que vous avez lié le profil à une interface de couche 2, l’interface réside dans l’instance de commutateur par défaut.

  • Si les flux de trafic sur une interface dépassent le niveau de storm control spécifié, le commutateur Juniper Networks abandonne les paquets excédentaires, ce que l’on appelle la limitation de débit. En outre, les commutateurs QFX10000 dans un environnement EVPN-VXLAN prennent en charge la désactivation de l’interface pendant une durée spécifiée à l’aide de l’instruction action-shutdown de configuration au niveau de la [edit forwarding-options storm-control-profiles] hiérarchie et de l’instruction recovery-timeout de configuration au niveau de la [edit interfaces interface-name unit logical-unit-number family ethernet-switching] hiérarchie.

    Note:

    Les commutateurs QFX5100 et QFX5110 dans un environnement EVPN-VXLAN ne prennent pas en charge la désactivation de l’interface pendant une durée spécifiée.

    Note:

    Sur les commutateurs QFX5110, si vous configurez un storm control amélioré et un analyseur natif sur une interface, et que l’analyseur natif a le VLAN VxLAN en entrée, l’action d’arrêt ne fonctionnera pas pour le VLAN sur cette interface. La limitation de débit fonctionnera comme prévu.

La configuration suivante crée un profil nommé scp, qui spécifie que si la bande passante utilisée par les flux de trafic BUM combinés dépasse 5 % sur l’interface logique de couche 2 et-0/0/23.0, l’interface abandonne le trafic BUM excédentaire.

La configuration suivante crée un profil nommé scp, qui spécifie que si la bande passante utilisée par le flux de trafic multicast (les flux de trafic de diffusion et unicast inconnus sont exclus) dépasse 5 % sur l’interface logique de couche 2 et-0/0/23.0, l’interface abandonne le trafic multicast excédentaire.

La configuration suivante sur un commutateur QFX10000 crée le même profil que dans la configuration précédente. Toutefois, au lieu d’abandonner implicitement le trafic multicast si le flux de trafic dépasse 5 %, la configuration suivante désactive explicitement l’interface pendant 120 secondes, puis la rétablit.

Mise en miroir de ports et analyseurs

Pour analyser le trafic dans un environnement EVPN-VXLAN, nous prenons en charge les fonctionnalités suivantes de mise en miroir de ports et d’analyseur :

  • Mise en miroir locale

    • Sur une interface

    • Sur un VXLAN

  • Mise en miroir à distance

    • Sur une interface

    • Sur un VXLAN

Les sections suivantes fournissent plus d’informations sur les fonctionnalités prises en charge et incluent des exemples de configuration.

Mise en miroir locale

Note:

La mise en miroir locale est comparable à l’analyseur de port commuté (SPAN).
Tableau 3 : prise en charge de la mise en miroir locale

Entité à laquelle la mise en miroir locale est appliquée

Sens de la circulation

Prise en charge basée sur les filtres

Prise en charge basée sur l’analyseur

Interface orientée CE

Pénétration

Soutenu.

Reportez-vous à la section Cas d’utilisation 1 : Exemple de configuration.

Soutenu.

Reportez-vous à la section Cas d’utilisation 2 : Exemple de configuration.

Interface orientée CE

Sortie

Non pris en charge.

Soutenu; Toutefois, le trafic sortant en miroir peut porter des balises VLAN incorrectes qui diffèrent de celles du trafic d’origine.

Reportez-vous à la section Cas d’utilisation 3 : Exemple de configuration.

Interface orientée fabric IP

Pénétration

Soutenu.

Soutenu.

Reportez-vous au cas d’utilisation 4 : Exemple de configuration.

Interface orientée fabric IP

Sortie

Non pris en charge.

Soutenu. Toutefois, la décision de mise en miroir se fait à l’entrée, de sorte que l’en-tête de couche 2 ne sera pas le même qu’un paquet commuté ou routé. Les paquets encapsulés VXLAN en miroir n’incluent pas d’en-tête VXLAN.

Reportez-vous au cas d’utilisation 5 : Exemple de configuration.

VLAN mappé par VXLAN

Pénétration

Soutenu.

Pris en charge uniquement pour le trafic entrant via une interface orientée CE.

Reportez-vous au cas d’utilisation 6 : Exemple de configuration.

Configuration de la mise en miroir locale

Use Case 1: Firewall filter-based

À l’aide d’une instance de mise en miroir de port nommée pm1 et d’un filtre de pare-feu, cette configuration spécifie que le trafic de couche 2 qui entre dans VXLAN100 via l’interface logique xe-0/0/8.0 est mis en miroir vers un analyseur sur l’interface logique xe-0/0/6.0, puis vers l’instance de mise en miroir de port pm1.

Use Case 2: Analyzer-based

Grâce à l’utilisation de l’instruction analyzer de configuration au niveau de la hiérarchie, cette configuration spécifie que le trafic de couche 2 qui entre dans l’interface [set forwarding-options] logique xe-0/0/8.0 est mis en miroir vers un analyseur sur l’interface logique xe-0/0/6.0.

Use Case 3: Analyzer-based

À l’aide de l’instruction analyzer de configuration au niveau de la hiérarchie, cette configuration spécifie que le trafic de couche 2 qui sort de l’interface [set forwarding-options] logique xe-0/0/8.0 est mis en miroir vers un analyseur sur l’interface logique xe-0/0/6.0.

Use Case 4: Analyzer-based

Grâce à l’utilisation de l’instruction analyzer de configuration au niveau de la hiérarchie, cette configuration spécifie que le trafic de couche 2 qui entre dans l’interface [set forwarding-options] logique xe-0/0/29.0 est mis en miroir vers un analyseur sur l’interface logique xe-0/0/6.0.

Use Case 5: Analyzer-based

À l’aide de l’instruction analyzer de configuration au niveau de la hiérarchie, cette configuration spécifie que le trafic de couche 2 qui sort de l’interface [set forwarding-options] logique xe-0/0/29.0 est mis en miroir vers un analyseur sur l’interface logique xe-0/0/6.0.

Use Case 6: Analyzer-based

À l’aide de l’instruction analyzer de configuration au niveau de la [set forwarding-options] hiérarchie, cette configuration spécifie que le trafic de couche 2 qui entre dans le VLAN nommé VXLAN100 et est mis en miroir vers un analyseur sur l’interface logique xe-0/0/6.0.

Mise en miroir à distance

La mise en miroir de ports distants est utilisée lorsque la destination de sortie ne se trouve pas sur le même commutateur que la source. La mise en miroir à distance achemine le trafic en miroir à un ou plusieurs hôtes de destination distants. Il est souvent utilisé dans l’environnement des centres de données pour le dépannage ou la surveillance.

Dans un environnement EVPN-VXLAN, le flux de trafic en miroir au niveau du commutateur source est encapsulé et tunnelisé à travers la fabric IP sous-jacente jusqu’à l’adresse IP de l’hôte de destination. Nous prenons en charge les types d’encapsulation suivants :

  • Avec la mise en miroir à distance, l’encapsulation de routage générique (GRE) permet d’encapsuler le trafic entre des commutateurs séparés par un domaine de routage. Dans une superposition EVPN-VXLAN, l’encapsulation GRE permet la mise en miroir entre les équipements de branche sur la structure IP. Utilisez la mise en miroir à distance avec GRE lorsque les hôtes de destination de mise en miroir sont connectés à un commutateur qui fait partie de la même structure que le commutateur source. La mise en miroir à distance avec encapsulation GRE est comparable à la mise en miroir à distance encapsulée (ERSPAN).

    Note:

    Sur les plates-formes ACX7100-32C et ACX7100-48L, la version comparable d’ERSPAN est la version 2 d’ERSPAN (ERSPAN v2).

  • L’encapsulation VXLAN prend en charge la mise en miroir à distance pour EVPN-VXLAN lorsque les destinations source et sortie se trouvent dans des domaines VNI distincts. Vous devez configurer un VXLAN spécifique pour la mise en miroir du trafic pour les interfaces de destination de sortie et mappé à un VNI. La mise en miroir à distance avec encapsulation VXLAN est comparable à la mise en miroir à distance (RSPAN).

Tableau 4 : prise en charge de la mise en miroir à distance

Entité à laquelle la mise en miroir à distance est appliquée

Sens de la circulation

Prise en charge basée sur les filtres

Prise en charge basée sur l’analyseur

Interface orientée CE

Pénétration

Soutenu.

Non pris en charge sur ACX7100.

Soutenu. Reportez-vous à la section Cas d’utilisation 1 : Exemple de configuration.

Pris en charge le ACX7100. Toutefois, les paquets en miroir incluent un en-tête GRE.

Interface orientée CE

Sortie

Non pris en charge.

Soutenu. Reportez-vous à la section Cas d’utilisation 2 : Exemple de configuration.

Pris en charge le ACX7100. Toutefois, les paquets en miroir incluent un en-tête GRE.

Interface orientée fabric IP

Pénétration

Soutenu.

Non pris en charge sur ACX7100.

Soutenu. Reportez-vous à la section Cas d’utilisation 3 : Exemple de configuration.

Pris en charge le ACX7100. Toutefois, les paquets encapsulés VXLAN en miroir comprennent un en-tête VXLAN et un en-tête GRE.

Interface orientée fabric IP

Sortie

Non pris en charge.

Soutenu. Toutefois, la décision de mise en miroir se fait à l’entrée, de sorte que l’en-tête de couche 2 ne sera pas le même qu’un paquet commuté ou routé. Reportez-vous au cas d’utilisation 4 : Exemple de configuration.

Note:

Le trafic en miroir peut inclure une fausse balise d’ID VLAN de 4094 sur la trame MAC native.

Pris en charge le ACX7100. Toutefois, les paquets en miroir incluent un en-tête GRE, mais pas un en-tête VXLAN.

VLAN mappé par VXLAN

Pénétration

Soutenu.

Non pris en charge sur ACX7100.

Pris en charge uniquement pour le trafic entrant dans une interface orientée CE. Reportez-vous au cas d’utilisation 5 : Exemple de configuration.

Non pris en charge sur ACX7100.

Configuration de la mise en miroir à distance avec l’encapsulation GRE

Les exemples de configuration suivants concernent la mise en miroir à distance basée sur un analyseur avec encapsulation GRE.

Note:

Pour obtenir un exemple de configuration d’un analyseur distant avec encapsulation GRE sur ACX7100, reportez-vous à la section Exemple : Activation d’une instance d’analyseur distant à une interface ESI-LAG.

Use Case 1

Grâce à l’utilisation de l’instruction analyzer de configuration au niveau de la hiérarchie, cette configuration spécifie que le trafic de couche 2 qui entre dans l’interface [set forwarding-options] logique xe-0/0/8.0 est mis en miroir sur une interface logique distante avec une adresse IP 10.9.9.2.

Use Case 2

À l’aide de l’instruction analyzer de configuration au niveau de la hiérarchie, cette configuration spécifie que le trafic de couche 2 qui sort de l’interface logique xe-0/0/8.0 est mis en miroir vers une interface logique distante dont l’adresse [set forwarding-options] IP est 10.9.9.2.

Use Case 3

Grâce à l’utilisation de l’instruction analyzer de configuration au niveau de la hiérarchie, cette configuration spécifie que le trafic de couche 2 qui entre dans l’interface [set forwarding-options] logique xe-0/0/29.0 est mis en miroir vers une interface logique distante avec une adresse IP 10.9.9.2.

Use Case 4

À l’aide de l’instruction analyzer de configuration au niveau de la hiérarchie, cette configuration spécifie que le trafic de couche 2 qui sort de l’interface logique xe-0/0/29.0 est mis en miroir vers une interface logique distante dont l’adresse [set forwarding-options] IP est 10.9.9.2.

Use Case 5

À l’aide de l’instruction analyzer de configuration au niveau de la [set forwarding-options] hiérarchie, cette configuration spécifie que le trafic de couche 2 qui entre dans VXLAN100, qui est mappé à l’interface logique xe-0/0/8.0, est mis en miroir sur une interface logique distante avec une adresse IP 10.9.9.2.

Configuration de la mise en miroir à distance avec l’encapsulation VXLAN

Pour savoir quelles plates-formes prennent en charge cette fonctionnalité à partir de quelles versions, consultez la page Explorateur de fonctionnalités pour la mise en miroir de ports distants avec encapsulation VXLAN.

Configuration basée sur l’analyseur

L’exemple de configuration suivant concerne la mise en miroir à distance basée sur un analyseur avec encapsulation VXLAN. Le trafic de couche 2 qui entre dans VLAN100 est mis en miroir vers le VLAN3555 de destination de sortie distant, qui est mappé à VNI 1555.

Cette configuration utilise une interface de bouclage sur le VLAN de destination pour encapsuler les paquets mis en miroir.

  • L’interface de destination xe-0/0/2 est connectée en externe à l’interface de bouclage xe-0/0/3.

  • Les interfaces logiques xe-0/0/2.0 et xe-0/0/3.0 sont membres du VLAN3555 de destination.
  • L’interface xe-0/0/2.0 est configurée en style entreprise sans aucun mappage VNI, tandis que l’interface xe-0/0/3.0 est configurée en style fournisseur de services avec le même ID VLAN et avec le mappage VNI. Cela permet d’éviter le flooding ou la boucle entre ces ports.
  • Mac-learning doit être désactivé sur xe-0/0/2.0.
Note:

L’interface entrante doit être configurée en mode trunk, de sorte que les paquets encapsulés sont balisés. Pour décapsuler les paquets balisés, configurez la set protocols l2-learning decapsulate-accept-inner-vlan commande au niveau du nœud de décapsulation.

Pour configurer une interface de bouclage logique au lieu d’utiliser une connexion externe, utilisez la commande suivante :

set interfaces interface-name ether-options loopback

L’exemple de configuration ci-dessous utilise un bouclage logique sur l’interface xe-0/0/2 :

Configuration basée sur les filtres de pare-feu

La configuration suivante applique un filtre de pare-feu, filter1, au trafic entrant au niveau de l’interface xe-0/0/34. Le trafic entrant sur cette interface est répercuté sur la destination VLAN3555. Le VLAN de destination est défini à l’aide d’une instance de mise en miroir des ports nommée pm1.

Mise en miroir de ports distants à l’aide de conditions de correspondance VNI

Pour les commutateurs QFX10002, QFX10008 et QFX10016 Series, vous pouvez utiliser les valeurs des identifiants réseau VXLAN (VNI) comme condition de correspondance lors du filtrage du trafic pour la mise en miroir de ports distants. Cette capacité est souvent utilisée dans la planification réseau et pour des analyses telles que l’inspection approfondie des paquets (DPI).

La fonctionnalité de mise en miroir des ports distants crée une copie des paquets entrants ciblés, qui sont encapsulés dans un en-tête GRE IPv4 externe, puis transférés vers une destination distante désignée. La prise en charge des conditions de correspondance VNI signifie que vous pouvez sélectionner les paquets à mettre en miroir en fonction de leur VNI afin que seuls ces flux soient dirigés vers le port miroir distant. Vous pouvez également configurer une valeur DSCP (Differentiated Service Code Point) pour hiérarchiser le flux, par exemple, une priorité élevée ou une distribution au mieux. Les interfaces de routage et de pontage intégrées (IRB) ne sont pas prises en charge en tant que port miroir de destination.

De manière générale, la procédure de mise en miroir de ports distants basée sur les VNI consiste à créer une instance de mise en miroir de ports distants, à promouvoir les VNI dans la famille de filtres de pare-feu pour gérer les VNI, à créer les règles et actions de filtrage nécessaires, puis à appliquer la stratégie de pare-feu à une interface d’entrée. Le tunneling GRE doit également être en place sur l’interface utilisée pour envoyer les paquets mis en miroir.

Remote Port Mirroring on the Basis of VNI Use Case: Sample Configuration

Les exemples de code ci-dessous mettent en évidence les principales configurations de CLI Junos dont vous avez besoin pour mettre en miroir les paquets en fonction de VNI.

  1. Activez la mise en miroir des ports distants, ainsi que la source de trafic et la destination vers laquelle vous souhaitez envoyer les paquets mis en miroir.
  2. Créez un filtre de pare-feu (ici nommé bf_vni_st) et promouvez VNI dans ce filtre pour qu’il devienne le module de transfert de paquets (en d’autres termes, cette commande définit l’ensemble du filtre pour optimiser les conditions de correspondance VNI).
  3. Créez un filtre de pare-feu d’entrée (bf_vni_st), qui spécifie une condition de correspondance VNI (6030 dans cet exemple) et une action (count, dans cet exemple).
  4. Appliquez le filtre au trafic entrant au niveau de l’interface que vous souhaitez mettre en miroir.

Documentation connexe