Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Comment configurer la mise en miroir des ports distants pour les structures EVPN-VXLAN

À propos de cet exemple de configuration réseau

Cet exemple de configuration réseau (NCE) explique comment configurer la mise en miroir des ports distants pour les structures EVPN-VXLAN. La mise en miroir de ports copie un flux de trafic et l’envoie à une station de surveillance à distance (RMON) à l’aide d’un tunnel GRE. Tout comme ERSPAN, la mise en miroir des ports distants du trafic utilisateur avec l’encapsulation VXLAN est souvent utilisée dans l’environnement du centre de données à des fins de dépannage ou de surveillance.

Nous démontrons comment ajouter la mise en miroir des ports distants aux commutateurs lean spine et aux équipements de branche à routage périphérique dans une structure EVPN-VXLAN. Notre structure d’exemple repose sur une architecture de pontage à routage périphérique (ERB). La mise en miroir des ports VXLAN est également prise en charge dans les structures de pontage à routage central (CRB).

Voir aussi

Présentation des cas d’utilisation

Mise en miroir des ports distants et structures EVPN-VXLAN

La mise en miroir des ports distants copie un flux de trafic et transmet le trafic en miroir à un ou plusieurs hôtes de destination en miroir. Le flux de trafic est identifié par l’interface entrante ou sortante, dans certains cas, à l’aide d’un filtre de pare-feu pour une granularité accrue. Les hôtes de destination en miroir sont connectés à un commutateur de branche qui fait partie de la même structure que le commutateur source.

Pour les structures IP EVPN-VXLAN, le flux de trafic en miroir est encapsulé dans l'encapsulation de routage générique (GRE) et transmis via la structure IP sous-jacente à l'adresse IP de l'hôte de surveillance. Vous utilisez cet hôte comme station de surveillance pour capturer et décoder le flux de trafic.

La mise en miroir de ports distants avec un tunnel GRE s’adapte parfaitement aux structures IP comme EVPN-VXLAN, car vous pouvez connecter la station de surveillance à n’importe quel commutateur de branche de la structure en faisant la publicité du sous-réseau de l’hôte dans l’underlay EBGP. De plus, le commutateur de destination connecté à la station de surveillance n’a pas besoin d’effectuer de décapsulation GRE avant de transmettre le flux GRE à la station de surveillance. Le tunnel GRE peut traverser plusieurs nœuds IP intermédiaires ou être envoyé en dehors de la structure.

Méthodes de mise en miroir des ports : Instance d’analyse et instance de mise en miroir des ports

Deux méthodes sont disponibles pour la mise en miroir des ports : une instance d’analyse et une instance de mise en miroir des ports. Chaque approche présente des avantages différents et est compatible avec différentes architectures. Dans les deux cas, le tunnel GRE à des fins de mise en miroir est créé automatiquement, de sorte qu’il n’est pas nécessaire de configurer un tunnel GRE.

L’instance d’analyse met en miroir les ports sans aucun critère de filtrage. Un outil d’analyse est la forme la plus simple de mise en miroir du trafic à implémenter. Il vous suffit de spécifier l’interface qui est la source du trafic en miroir et si le trafic à mettre en miroir sur cette interface est sortant, entrant ou les deux. Vous spécifiez également l’adresse IP pour la destination du trafic en miroir. Il n’est pas nécessaire de configurer ou d’appliquer un filtre de pare-feu.

L’instance d’analyse n’étant pas spécifique au locataire, c’est la meilleure approche lorsque vous ne disposez pas d’informations sur le flux utilisateur.

L’instance de mise en miroir de ports utilise des critères spécifiques au trafic utilisateur pour mettre en miroir le trafic. L’administrateur de la structure décide de l’adresse IP source du locataire, du protocole, du port, etc., qui présente un intérêt pour l’interface en miroir. Utilisez une instance de mise en miroir de port lorsque le trafic spécifique doit être mis en miroir.

Juniper Networks prend en charge trois architectures de centre de données principales. Toutes prennent en charge la mise en miroir des ports distants. Pour chaque architecture, nous recommandons la méthode de mise en miroir des ports suivante :

  • Overlay ponté : instance d’analyse

  • Pontage à routage central (CRB) : instance de mise en miroir des ports

  • ERB (Edge-Routed Bridging) : instance de mise en miroir des ports

Présentation technique

Mise en miroir de ports distants dans une structure ERB EVPN-VXLAN

Ce NCE couvre la mise en miroir des ports distants pour une architecture ERB avec un cœur de réseau réduit.

Dans une structure EVPN-VXLAN ERB avec un cœur de réseau réduit, les flux internes propres aux locataires ne peuvent pas être envoyés de manière sélective dans le tunnel. Seul le filtrage externe basé sur l’en-tête (underlay) est pris en charge par un équipement de cœur de réseau réduit. Par exemple, un commutateur de cœur de réseau peut filtrer les paquets provenant d’une adresse de bouclage IPv4 source spécifique et envoyer le trafic à la station de surveillance connectée à un autre équipement de branche à l’aide du tunnel GRE.

La mise en miroir de ports distants avec GRE pour un flux spécifique à un locataire est prise en charge sur les équipements de branche dans une architecture ERB. Dans ce cas, vous pouvez implémenter le filtre de mise en miroir des ports distants à l’interface de routage et de pontage intégrés (IRB) pour mettre en miroir le trafic inter-VLAN (routée). Pour mettre en miroir le trafic intra-VLAN (ponté), appliquez un filtre d’interface à l’interface entrante jointe au serveur ou à l’équipement hôte.

Dans une méthode, le cœur de réseau ou la branche, le trafic en miroir s’en va vers l’outil d’analyse distant via un tunnel GRE.

Mise en miroir des ports distants avec les commutateurs QFX Series

Dans les exemples suivants, nous démontrons différentes façons d’utiliser la mise en miroir de ports distants pour une architecture ERB basée sur des commutateurs QFX Series.

Les commutateurs QFX5110 et QFX5120 fonctionnent aussi bien que les équipements de branche dans une architecture de centre de données de référence ERB, car ces modèles peuvent effectuer un routage VNI (inter-virtual network identifier).

Le tableau 1 illustre la prise en charge des types d’instance en miroir de ports dans divers cas d’utilisation lors de l’utilisation de commutateurs QFX10002 et QFX10008. Le tableau 2 affiche les mêmes éléments lors de l’utilisation des commutateurs QFX5110 et QFX5120.

Tableau 1 : Mise en miroir des ports distants sur QFX10002 et QFX10008

Cas d’utilisation

Sous-cas d’utilisation

Instance d’analyse

Instance de mise en miroir de ports

Cœur de réseau assurant le transit IP

Entrant de la branche au cœur du réseau

Soutenu

Soutenu

Sortie du cœur de réseau vers la branche

Soutenu

Soutenu

Cœur de réseau dans un scénario CRB

Entrant d’IRB qui met fin au trafic

Seules les interfaces ge, xe et et ae sont prises en charge

Non pris en charge

Sortie d’IRB qui met fin au trafic

Seules les interfaces ge, xe et et ae sont prises en charge

Non pris en charge

Encapsulation de bordure

Accès entrant d’ESI-LAG

Soutenu

Soutenu

De l’encapsulation de bordure

Sortie de la structure

Non pris en charge

Non pris en charge
Tableau 2 : Mise en miroir des ports distants sur QFX5110 et QFX5120

Cas d’utilisation

Sous-cas d’utilisation

Instance d’analyse

Instance de mise en miroir de ports

Cœur de réseau maigre fournissant un transit IP

Entrant de la branche au cœur du réseau

Soutenu

Soutenu

Sortie du cœur de réseau vers la branche

Soutenu

Non pris en charge

Branche dans un scénario ERB

Entrant d’IRB qui met fin au trafic

Seules les interfaces ge, xe et et ae sont prises en charge

Soutenu

Sortie d’IRB qui met fin au trafic

Seules les interfaces ge, xe et et ae sont prises en charge

Non pris en charge

Encapsulation de bordure

Accès entrant d’ESI-LAG

Soutenu

Soutenu

Sortie d’accès d’ESI-LAG

Soutenu

Non pris en charge

De l’encapsulation de bordure

Entrante de la structure

Non pris en charge

Non pris en charge

Sortie de la structure

Non pris en charge

Non pris en charge

Tous les commutateurs QFX de cet exemple exécutent Junos OS version 18.4R2 ou supérieure. Les commutateurs QFX5110 et QFX5120 exécutant Junos OS version 18.4R2 prennent en charge ces chiffres d’évolutivité :

  • Sessions d’analyse par défaut : 4

  • Sessions de mise en miroir de ports : 3 sessions de mise en miroir de ports + 1 session de mise en miroir globale des ports

Le présent livre couvre les cas d’utilisation suivants :

  1. Exemple : La solution d’entrée/sortie d’un équipement de cœur de réseau ERB EVPN-VXLAN vous montre comment mettre en miroir le trafic entrant et sortant via un équipement de cœur de réseau réduit dans une structure ERB.

  2. Exemple : La solution d’entrée d’un équipement de branche de structure ERB EVPN-VXLAN explique comment mettre en miroir le trafic entrant à travers un équipement de branche dans un scénario ERB.

  3. Exemple : Activer une instance de mise en miroir à distance dans une interface ESI-LAG vous montre comment utiliser une instance de mise en miroir de port ou une instance d’analyse dans le cas d’utilisation d’encapsulation de bordure pour l’accès au trafic entrant et sortant via une interface ESI-LAG.

  4. Exemple : Activez une instance d’analyse à distance dans une interface ESI-LAG pour savoir comment utiliser une instance d’analyse pour mettre en miroir le trafic entrant et sortant via une interface ESI-LAG.

Utilisez les procédures décrites dans ces exemples pour mettre en miroir les ports distants dans votre cas d’utilisation particulier.

Topologie

Exigences

Cet exemple de configuration utilise les équipements suivants exécutant Junos OS version 18.4R2 ou supérieure. Cet exemple a été validé à nouveau sur les commutateurs QFX exécutant Junos 22.2R1.

  • Deux commutateurs QFX5110 comme équipements de cœur de réseau réduit.

  • Un commutateur QFX10002 en tant qu’équipement de bordure de branche.

  • Deux commutateurs QFX5110 ou 5120 en tant qu’équipements de branche 1 et de branche de serveur 2.

  • Un QFX10002 en tant que branche de serveur 4. Si vous le souhaitez, vous pouvez utiliser un QFX5110 ou un QFX5120 au lieu d’un QFX10002.

  • Deux serveurs qui envoient et reçoivent du trafic via la structure EVPN-VXLAN.

  • Station de surveillance équipée d’une application d’analyse. Dans cet exemple, nous utilisons Wireshark.

Topologie de base

Ce livre explique comment ajouter différents types de mise en miroir de ports à une structure EVPN-VXLAN existante. La figure 1 détaille la topologie de base pour tous les exemples suivants.

Figure 1 : Topologie de base de la mise en miroir des ports Port Mirroring Baseline Topology

Les cœurs de réseau 1 et 2 sont des équipements « lean spines » qui n'effectuent aucune encapsulation ou décapsulation VXLAN. Les serveurs 1 et 2 partagent le VLAN 101 et le sous-réseau 10.1.101.0/24. Le serveur 1 commence par une installation centralisée vers la branche 1. Dans les sections ultérieures, nous la attachons à la branche 2 pour former une interface ESI-LAG. Le serveur 2 est attaché à la branche 4. La branche 3 fonctionne comme une branche de bordure. Sa configuration est la même que celle utilisée sur les feuilles du serveur. Notez que dans cet exemple, la branche 4 est un commutateur QFX10000 connecté à l’équipement d’analyse sur l’interface xe-0/0/33:1.

La topologie prend en charge le multihébergement avec ESI-LAG entre les serveurs 1 et 1 et 2. Tous les scénarios de cette NCE n’utilisent pas cette fonctionnalité multi-domicile. Pour connaître les configurations complètes des équipements de démarrage, reportez-vous à l’annexe : Configurations complètes des équipements.

Exemple : Solution d’entrée/sortie pour un équipement de cœur de réseau ERB EVPN-VXLAN

Aperçu

Dans cet exemple, nous mettons en miroir les ports distants sur un commutateur de cœur de réseau réduit. Le trafic en miroir est envoyé par un tunnel GRE vers la station de surveillance distante. Ce cas d’utilisation est basé sur la méthode d’instance de mise en miroir des ports.

Cet exemple utilise une architecture ERB EVPN-VXLAN où le routage d’identifiant de réseau virtuel (VNI) unicast a lieu au niveau des équipements de branche. Les équipements « lean spine » ne terminent aucun tunnel VXLAN. Ils fournissent un transfert IP et, dans le cas d’un overlay basé sur IBGP, des capacités de réflexion de route. Notre overlay est basé sur EBGP, nous n’utilisons donc pas la réflexion de route.

Cette configuration met en miroir tout le trafic envoyé entre les équipements de branche. La station de surveillance capture à la fois le trafic intra-VLAN (ponté) et inter-VLAN (roué) pour tous les VLAN sur les feuilles. Les informations spécifiques du locataire ne sont pas provisionnés sur les équipements lean spine, mais vous pouvez activer les sessions de mise en miroir au cœur de réseau.

Connaissez la capacité du port d’analyse. Une grande quantité de trafic passe par le port d’analyse, car vous passez en miroir tout le trafic overlay envoyé entre l’association de branche. Les équipements de branche sont reliés au cœur de réseau par deux interfaces 40GE, ce qui leur permet de transporter de gros volumes de trafic. Les commutateurs disposent de capacités de mise en mémoire tampon limitées. Des chutes de trames se produisent si vous miroirs plus de trafic que la station de surveillance ne le prend en charge.

Pour augmenter la capacité, utilisez une interface Ethernet agrégée avec plusieurs membres de liaisons. Réduisez la charge du trafic en procédant à la mise en miroir sur les équipements de branche et à la mise en miroir sélective du trafic pour certains locataires uniquement.

Topologie

Cet exemple de configuration utilise les composants matériels et logiciels indiqués dans La configuration requise. Les équipements de la topologie commencent par les configurations de base fournies dans l’annexe : Configurations complètes des équipements.

Comme le montre la Figure 2, le cœur de réseau 1 met en miroir le trafic overlay entrant et sortant circulant entre les branches 1 et 4 via un filtre de pare-feu appliqué à son interface et-0/0/7. Cette interface est intégrée à la branche 1 du serveur. Le trafic de superposition est généré en envoyant du trafic ping entre le serveur 1 et le serveur 2. Le trafic en miroir est envoyé par le cœur de réseau 1 à la station de surveillance distante connectée à l’interface xe-0/0/33:1 de la branche de bordure 3.

Figure 2 : Topologie de la mise en miroir des ports distants via un équipement de cœur de réseau Topology of Remote Port Mirroring Through Spine Device

Le cœur de réseau utilise un tunnel GRE pour envoyer le trafic en miroir à la station de surveillance. Gre est nécessaire, car le trafic en miroir peut être de couche 2, ou overlay couche 3, et ne peut donc pas être acheminé vers l’underlay de la structure. Le tunnel GRE se forme automatiquement une fois que l’accessibilité IP vers le sous-réseau de surveillance 172.16.1.0/24 est établie via l’underlay.

Le serveur 1 est une branche 1 à domicile dans ce scénario.

Configuration

Utilisez cet exemple pour mettre en miroir le trafic transitant par le cœur de réseau 1. Pour mettre en miroir tout le trafic, répétez la configuration sur le cœur de réseau 2. Lorsque la mise en miroir des ports est configurée sur les cœurs de réseau 1 et 2, le trafic est mis en miroir, quel que soit le saut suivant de la structure ECMP sélectionnée par la branche.

  1. (Facultatif) Désactivez BGP sur le cœur de réseau 2. À des fins de test, nous désactivons la catégorie BGP sur le cœur de réseau 2. Ainsi, nous pouvons nous concentrer uniquement sur le cœur de réseau 1 et garantir la mise en miroir de tout le trafic entre les branches 1 et 4.

    Après avoir désactivé BGP sur le cœur de réseau 2, la branche 1 possède un saut suivant pour atteindre le bouclage de la branche 4. Il s’agit de Spine 1 via son interface et-0/0/48.

  2. Créez une instance de mise en miroir au niveau du cœur de réseau 1 pour envoyer le trafic en miroir à la station de surveillance distante.

  3. Les cœurs de réseau maigres ne sont pas conscients de la superposition dans une structure ERB. Tout le trafic encapsulé VXLAN envoyé entre les équipements de branche utilise l’adresse VTEP locale. L'adresse VTEP correspond normalement à l'adresse de bouclage de l'équipement. Cela signifie que nous pouvons utiliser un filtre sur les équipements de cœur de réseau pour qu’il corresponde aux adresses de bouclage des équipements de branche associés pour diriger le trafic vers l’instance de mise en miroir des ports.

    Au niveau du cœur de réseau 1, créez des filtres de pare-feu qui correspondent aux adresses IP source et de destination des branches 1 et 4. En faisant correspondance entre l’ADRESSE IP source et l’adresse IP de destination, tout le trafic overlay envoyé entre ces branches est mis en miroir dans le tunnel GRE.

    Note:

    Comme les cœurs de réseau maigres ne sont pas orientés VXLAN, cette méthode met en miroir l’ensemble du trafic overlay envoyé par l’équipement de branche. Par exemple, si la branche comporte 100 VLAN ou VXLAN définis, le trafic de l’ensemble des 100 VNF est mis en miroir. Si vous souhaitez mettre en miroir un niveau plus précis de granularité, consultez l’exemple : Solution d’entrée pour un équipement de branche de structure ERB EVPN-VXLAN. Dans cet exemple, la fonction miroir se produit au niveau de l’équipement de branche compatible VXLAN.

    Définissez un filtre de pare-feu pour le trafic envoyé à partir de la branche 1. Dans notre exemple, tout le trafic VXLAN envoyé par la branche 1 (via les cœurs de réseau) a une adresse source de 10.1.255.11. Tout trafic VXLAN envoyé par la branche 4 a une adresse source de 10.1.255.14.

    Définissez un filtre de pare-feu pour le trafic envoyé à partir de la branche 4.

  4. Appliquez les filtres de pare-feu aux interfaces de structure leaf 1 et Leaf 4 au niveau du cœur de réseau 1.

    Notez la directionnalité de l’application de filtre. Nos filtres sont compatibles avec une plate-forme QFX5110, qui ne prend en charge que les filtres d’entrée pour la mise en miroir des ports, conformément au tableau 2. En utilisant des filtres d'entrée correspondant au VTEP de la branche locale comme adresse source et au VTEP de la branche distante comme adresse de destination, nous veillons à ce que seul le trafic de superposition entre ces deux branches soit mis en miroir. Si vous souhaitez mettre en miroir tout le trafic VXLAN envoyé par une branche, quelle que soit la branche de destination, il suffit de correspondre à l'adresse source de la branche locale dans votre filtre.

  5. (Facultatif) Ajoutez des filtres supplémentaires.

    Dans cet exemple jusqu’à présent, nous avons supposé que le serveur 1 n’est qu’un seul emplacement pour la branche 1. Si le serveur est multi-accueil vers les branches 1 et 2, vous devez adapter les filtres indiqués pour capturer le trafic envoyé de la branche 2 à la branche 4, et vice versa.

    Par exemple, ces instructions créent un filtre d'entrée pour l'interface leaf 2 du cœur de réseau 1 :

    Une modification rapide du filtre existant port-mirror-from-leaf4 est également nécessaire pour correspondre à l'adresse de destination du 2 VTEP de Leaf.

  6. Validez les modifications au niveau du cœur de réseau 1.

    Les changements par rapport à la ligne de référence EVPN-VXLAN de départ sont illustrés :

  7. Modifiez la configuration au niveau de la branche 3 pour configurer l’interface xe-0/0/33:1 connectée à la station de surveillance.

    Le dispositif de branche connecté à la station de surveillance n’a pas besoin d’une configuration GRE explicite. En effet, le tunnel GRE se termine à la station de surveillance. Vous devez vous assurer que l'adresse IP de la station de surveillance est joignable dans l'underlay de structure. En d’autres termes, le cœur de réseau ne peut pas envoyer le trafic encapsulé GRE à la station de surveillance s’il n’a pas d’accessibilité sous-jacente à la station de surveillance.

  8. Modifiez la stratégie d'exportation underlay au niveau de la branche de bordure 3 pour annoncer le préfixe de la station de surveillance. Notre topologie utilise un underlay EBGP. Nous ajoutons simplement un nouveau terme à la politique d’exportation sous-jacente existante.

  9. Validez les modifications sur la branche de bordure 3.

    Les changements apportés à la base de départ sont indiqués :

Vérification

  1. Vérifiez la connectivité underlay du cœur de réseau 1 à la station de surveillance.

    Sur le cœur de réseau 1, affichez la route vers 172.16.1.0/24.

    Note:

    À proprement parler, seule une connectivité simple entre le cœur de réseau et la station de surveillance est requise. Nous avons configuré une route statique sur la station de surveillance pour lui permettre d’atteindre l’underlay de structure. Cela permet d’effectuer des tests ping pour isoler les pannes.

    Ping sur la station de surveillance pour confirmer la connectivité.

    La sortie confirme l’accessibilité underlay attendue du cœur à la station de surveillance.

  2. Confirmez les instances de mise en miroir des ports sur le cœur de réseau 1. Sur le cœur de réseau 1, vérifiez que l’état de mise en miroir des ports distants est up.

    La sortie confirme la définition correcte de l’instance de mise en miroir des ports. L’état indique up que le cœur de réseau dispose d’un itinéraire sous-jacent jusqu’à la station de surveillance. Rappelez-vous que GRE est un protocole sans état. C’est pourquoi il est bon de vérifier la connectivité entre le cœur de réseau et la station de surveillance, comme nous l’avons fait à l’étape précédente.

  3. Vérifiez que les filtres appliqués au cœur de réseau 1 reflètent correctement le trafic de test.

    Effacer les compteurs juste avant de générer des pings.

    Lancez des pings entre le serveur 1 et le serveur 2 sur la structure.

    Affichez maintenant les compteurs de pare-feu sur le cœur de réseau 1. Vérifiez que les filtres appliqués au cœur de réseau 1 reflètent correctement le trafic de test. Notre topologie exemple ne comporte qu’un seul VLAN et une paire de serveurs. Il est ainsi facile de corréler le trafic test pour filtrer les correspondances. Tout nombre non nul est un bon signe que le filtre fonctionne.

    Les compteurs de pare-feu reflètent correctement le trafic test entre les deux serveurs.

  4. Vérifiez que le trafic envoyé entre le serveur 1 et le serveur 2 est mis en miroir au niveau du cœur de réseau 1 et envoyé à la station de surveillance.

    Une fois de plus, générez du trafic entre les serveurs 1 et 2 (non illustrés pour la brièveté). Utilisez l’option rapid de votre commande ping pour générer un volume plus important de trafic de test qui facilite la corrélation.

    Le trafic de l’interface de surveillance est compté sur l’interface au niveau de la branche 3 qui se connecte à la station de surveillance. Vérifiez que le nombre de paquets sortants reflète le trafic de test généré.

    La sortie confirme que le trafic est mis en miroir à la station de surveillance. L’absence de paquets en entrée est attendue, car la station de surveillance ne génère aucune réponse au trafic GRE reçu.

  5. Utilisez Wireshark ou une application d’analyse équivalente pour capturer et décoder le trafic en miroir.

    Figure 3 : Analyse Mirrored Traffic Analysis du trafic en miroir

    La capture indique que le serveur 1 envoie du trafic ping au serveur 2 et que le serveur 2 répond. Cela confirme que le trafic overlay envoyé entre l’association Leaf 1 et Leaf 4 est correctement mis en miroir au niveau du cœur de réseau 1. Notez que le trafic encapsulé VXLAN (port UDP 4789) est à son tour encapsulé dans GRE (protocole IP 47). Le type de protocole de l’en-tête GRE est « ERSPAN » (comparable à la mise en miroir de ports distants) et tous les autres indicateurs sont définis sur zéro.

    Le décodage vous permet de voir les adresses VTEP de branche ou de bouclage utilisées dans l’underlay (10.1.255.x). La trame de couche 2 d’origine, envoyée par les serveurs, est également présente, comme encapsulée dans VXLAN à l’aide du VNI 101. Le paquet IP envoyé par les serveurs est également décodé. Les adresses IP utilisées par les serveurs de l’overlay sont visibles (10.1.100.x/24), tout comme les détails des paquets IP/ICMP qu’ils ont générés.

    Vous avez bien configuré la mise en miroir des ports sur votre topologie.

Exemple : Solution d’entrée pour un équipement de branche de structure ERB EVPN-VXLAN

Aperçu

Utilisez l’exemple suivant pour mettre en miroir le trafic circulant à travers un équipement de branche sur une structure ERB EVPN-VXLAN. Contrairement au scénario de mise en miroir de ports à base de cœur de réseau réduit couvert dans le premier exemple, la branche est tenant-and-VLAN dans une conception ERB. Cela signifie que nous pouvons mettre en miroir le trafic spécifique envoyé entre nos équipements de branche plutôt que l’ensemble du trafic overlay. Les flux utilisateur qui correspondent aux critères de filtrage du dispositif de branche ERB sont mis en miroir dans un tunnel GRE qui se termine au niveau de la station de surveillance reliée à la branche 3 de bordure.

Topologie

Cet exemple de configuration utilise les composants matériels et logiciels indiqués dans La configuration requise. Les équipements de la topologie commencent par les configurations de base fournies dans l’annexe : Configurations complètes des équipements.

La figure 4 illustre la topologie de la mise en miroir des ports distants avec des fonctionnalités de filtrage des flux d’utilisateur.

Figure 4 : Topologie de la mise en miroir des ports distants via un équipement de branche Topology of Remote Port Mirroring Through Leaf Device

Notez que le serveur 1 n’est toujours qu’un seul emplacement pour la branche 1. La différence est que les filtres et l’instance de mise en miroir des ports sont désormais définis sur l’équipement de branche. L’objectif est de correspondre à l’ensemble du trafic envoyé par le serveur 1 au sous-réseau 10.1.101.0/24 associé au VLAN 101. Le trafic envoyé depuis le serveur 1 vers les destinations VLAN 101 est activé et envoyé au poste de mise en miroir des ports à la branche de bordure 3.

Configuration

Note:

Dans le premier scénario, nous avons désactivé BGP sur le cœur de réseau 2 pour nous concentrer sur l’application de filtre au niveau du cœur de réseau 1. Dans les autres exemples, les cœurs de réseau 1 et 2 sont entièrement opérationnels.

  1. Configurez une instance de mise en miroir de port sur la branche 1. Utilisez l’adresse IP 172.16.1.2 pour la station de surveillance.

  2. Ensuite, créez un filtre de pare-feu correspondant au sous-réseau affecté au VLAN 101. L’objectif est de mettre en miroir tout le trafic 101 intra-VLAN envoyé par le serveur 1 à la branche 1. Pour capturer le trafic inter-VLAN, spécifiez le sous-réseau du VLAN cible pour l'adresse de destination.

    Note:

    Si vous souhaitez mettre en miroir uniquement le trafic routée (entre VLAN), utilisez un family inet filtre appliqué à l'interface IRB du VLAN. Une seule interface IRB est définie pour chaque VLAN. Un filtre appliqué à l'interface IRB du VLAN capture tout le trafic inter-VLAN pour le VLAN associé, quel que soit le port du panneau avant sur lequel le trafic arrive.

    La méthode indiquée ici fonctionne pour le trafic inter-VLAN et intra-VLAN, mais nécessite l’application de filtres aux interfaces côté serveur en fonction de leur appartenance au VLAN. Un inet filtre appliqué à une interface IRB ne voit pas le trafic ponté (intra-VLAN).

  3. Appliquez le filtre de pare-feu en miroir de port distant au port d’accès connecté au serveur 1 dans la direction d’entrée.

    Note:

    Sur les commutateurs QFX5110 et QFX5120, le filtre de pare-feu ne peut pas être appliqué dans la direction de sortie ou utilisé sur les interfaces de structure connectées aux équipements de cœur de réseau.

  4. La branche de bordure 3 n’a pas besoin d’être configurée pour effectuer la déscapsulation GRE puisque le tunnel GRE se termine à la station de surveillance. Toutefois, la branche 3 doit promouvoir l'accessibilité du sous-réseau de la station de surveillance dans l'underlay de la structure. Configurez les éléments suivants sur la branche 3 pour établir l’accessibilité à la station de surveillance.

    Commencez par configurer l’interface xe-0/0/33:1 associée à la station de surveillance.

  5. Modifiez la stratégie d'exportation underlay au niveau de la branche de bordure 3 pour annoncer le préfixe de la station de surveillance. Notre topologie utilise un underlay EBGP. Nous ajoutons simplement un nouveau terme à la politique d’exportation sous-jacente existante.

  6. Validez la configuration.

    Les modifications par rapport à la base de départ sont affichées à la branche 1.

    Vous avez réussi à configurer la mise en miroir de ports distants via un équipement de branche sur une structure EVPN-VXLAN ERB.

Vérification

  1. Vérifiez la connectivité sous-jacente de la branche 1 à la station de surveillance.

    Sur la branche 1, affichez la route vers 172.16.1.0/24.

    Note:

    À proprement parler, seule une simple connectivité entre la branche et la station de surveillance est requise. Nous avons configuré une route statique sur la station de surveillance pour lui permettre d’atteindre l’underlay de structure. Cela permet d’effectuer des tests ping pour isoler les pannes.

    Ping sur la station de surveillance pour confirmer la connectivité.

    La sortie confirme l’accessibilité underlay attendue de la branche 1 à la station de surveillance. Nous devons sourcer le ping à partir de l'adresse de bouclage de la branche, car notre stratégie d'exportation sous-jacente ne fait que promouvoir l'accessibilité de l'adresse loopback. Dans l’exemple du lean spine, il n’était pas nécessaire de s’approvisionner à partir de l’adresse de bouclage. En effet, le cœur de réseau et la branche de bordure sont directement reliés par une liaison de structure. Ainsi, la branche de bordure est en mesure de router la réponse ping vers le cœur de réseau lorsqu'elle provient de l'interface de la structure de branche du cœur de réseau.

  2. Confirmez l’instance de mise en miroir des ports sur la branche 1.

    Sur la branche 1, vérifiez que l’état de mise en miroir des ports distants est up.

    La sortie confirme la définition correcte de l’instance de mise en miroir des ports. L’état indique up que la branche comporte un itinéraire sous-jacent vers la station de surveillance. Rappelez-vous que GRE est un protocole sans état. C’est pourquoi il est bon de vérifier la connectivité entre la branche et la station de surveillance, comme nous l’avons fait à l’étape précédente.

  3. Vérifiez que le filtre appliqué à la branche 1 reflète correctement le trafic test.

    Lancez des pings entre le serveur 1 et le serveur 2 sur la structure. Vérifiez que le filtre appliqué à la branche 1 reflète correctement le trafic. Notre topologie exemple ne comporte qu’un seul VLAN et une paire de serveurs. Il est ainsi facile de corréler le trafic test pour filtrer les correspondances. Tout nombre non nul est un bon signe que le filtre fonctionne.

    Effacer les compteurs juste avant de générer des pings.

    Affichez maintenant les compteurs de pare-feu sur le cœur de réseau 1.

    Les compteurs de pare-feu reflètent correctement le trafic test entre les deux serveurs.

  4. Vérifiez que le trafic envoyé entre le serveur 1 et le serveur 2 est mis en miroir à la branche 1 vers la station de surveillance.

    Une fois de plus, générez du trafic entre les serveurs 1 et 2 (non illustrés pour la brièveté). Nous avons utilisé l’option rapide pour la commande ping pour générer un plus grand volume de paquets afin de faciliter la détection.

    Surveillez les compteurs de trafic d’interface au niveau de la branche de bordure 3 pour vérifier que le trafic de test est envoyé à la station de surveillance.

    La sortie confirme que le trafic est mis en miroir à la station de surveillance. L’absence de paquets d’entrée est attendue car la station de surveillance ne génère aucune réponse au trafic GRE qu’elle reçoit.

  5. Utilisez Wireshark ou une application d’analyse équivalente pour capturer et décoder le trafic en miroir.

    Figure 5 : Analyse Mirrored Traffic Analysis du trafic en miroir

    La capture indique que le serveur 1 envoie du trafic ping au serveur 2. Le trafic de réponse n’est pas mis en miroir, car nous avons appliqué notre filtre dans la direction d’entrée uniquement à la branche 1. Appliquez une instance en miroir de port similaire et une configuration de filtre à la branche 4 pour également mettre en miroir le trafic de retour. Rappelez-vous que dans le cas du « lean spine », le trafic en miroir a montré l’encapsulation VXLAN. Dans notre cas de branche ERB, nous mettons en miroir le trafic de couche 2 avant qu’il n’ait été encapsulé dans VXLAN. Le filtre utilisé pour mettre en miroir le trafic est appliqué sous forme de filtre d’entrée sur l’interface côté serveur. À l’entrée, il n’y a pas d’encapsulation VXLAN.

    Il en va de même pour l'application du filtre à l'interface IRB d'un VLAN. Dans le cas IRB, le trafic en miroir ne contient pas d’encapsulation VXLAN. Les filtres IRB traitent le trafic inter-VLAN au niveau de la couche IP. Ainsi, dans le cas du filtre IRB, seul le trafic IP de couche 3 est mis en miroir.

    Le décodage indique que le tunnel GRE se trouve entre la branche 1 et la station de surveillance via l’underlay. La trame Ethernet et les paquets IP associés, tels qu’envoyés par le serveur 1, sont décodés. Les adresses IP attribuées aux serveurs sont visibles (10.1.100.x/24), tout comme les détails des paquets IP/ICMP générés par le serveur 1.

    Vous avez bien configuré la mise en miroir des ports sur votre topologie.

Exemple : activer une instance de mise en miroir à distance sur une interface ESI-LAG

Aperçu

Un identifiant de segment Ethernet (ESI) est le numéro unique de 10 octets qui identifie un segment Ethernet dans une structure EVPN-VXLAN connectée au serveur. L’ESI est configuré sur l’interface qui se connecte au serveur. Lorsque plusieurs liens forment un groupe d’agrégation de liens (LAG) et sont connectés au serveur, cela forme une interface ESI-LAG, également appelée EVPN LAG. Dans certains cas, vous devrez activer la mise en miroir des ports pour tout ou partie du trafic entrant ou sortant de l’interface ESI-LAG.

Utilisez cette section pour activer la mise en miroir des ports distants au niveau ESI-LAG d’une structure ERB EVPN-VXLAN.

Topologie

Cet exemple de configuration utilise les composants matériels et logiciels indiqués dans La configuration requise. Les équipements de la topologie commencent par les configurations de base fournies dans l’annexe : Configurations complètes des équipements.

Dans ce cas, nous modifions la structure EVPN pour prendre en charge le multihébergement du serveur 1 pour laisser 1 et 2. Pour ce faire, nous utilisons des interfaces ESI-LAG, également connues sous le nom d’EVPN LAG. Consultez les meilleures pratiques de configuration EVPN LAG pour connaître les meilleures pratiques.

La figure 6 illustre la topologie de cet exemple. Les deux cœurs de réseau sont opérationnels dans cette topologie. ECMP signifie que les branches 1 et 2 peuvent envoyer du trafic via l’un ou l’autre équipement de cœur de réseau. Pour simplifier l’illustration, nous montrons le trafic et les chemins en miroir avec le cœur de réseau 1 comme priorité.

Figure 6 : Topologie de la mise en miroir des ports distants sur l’interface Topology of Remote Port Mirroring at ESI-LAG Interface ESI-LAG

L’interface ae0.0 est l’interface ESI-LAG jointe au serveur 1. Le serveur 1 se voit attribuer l’adresse IP 10.1.101.10/24 et est associé au VLAN 101. L’objectif est de filtrer, puis de mettre en miroir le trafic envoyé à partir du serveur 1 à mesure qu’il passe par ae0.0 sur l’une ou l’autre branche. Le trafic en miroir est placé dans un tunnel GRE et envoyé à la station de surveillance. Comme auparavant, vous devez vous assurer que le sous-réseau de la station de surveillance est joignable dans l’underlay EBGP.

Avant de commencer

Si vous partez de la configuration de base indiquée dans l’annexe : Configurations complètes des équipements, suivez ces étapes pour modifier votre topologie avant de commencer.

  1. Modifiez la configuration des branches 1 et 2 pour prendre en charge la connexion multi-utilisateur du serveur 1. Commencez par rebaptiser l’interface xe-0/0/0/0 existante pour devenir la nouvelle interface ae0.0. Cette configuration s’adapte à toutes les configurations de l’interface xe-0/0/0 pour gagner du temps.

  2. Les spécificités de configuration de l'interface Ethernet agrégée du serveur, souvent appelée interface de liaison sous Linux, dépassent la portée de cette NCE. Notez que pour le serveur, il n’existe qu’une configuration Ethernet agrégée standard. Les instructions relatives à ESI-LAG sont appliquées uniquement aux équipements de branche.

    Note:

    La configuration de base de départ permet d’avoir une interface Ethernet agrégée via l’instruction de set chassis aggregated-devices ethernet device-count 1 configuration. Vous devez activer la prise en charge du châssis pour les équipements agrégés ou l’interface agrégée n’est pas créée.

  3. Après avoir appliqué et appliqué ces modifications aux équipements de branche et au serveur, vérifiez que l’interface ae0 est disponible sur les deux branches. L’exemple ci-dessous a été raccourci par souci de clarté.

    Vérifiez également que le serveur 1 est capable d’envoyer un ping au serveur 2 (ce qui n’est pas indiqué pour la brièveté).

Configuration

Cet exemple montre comment activer la mise en miroir des ports distants au niveau ESI-LAG à l’aide d’une instance de mise en miroir des ports distants. Cette méthode prend en charge les critères de correspondance spécifiques aux locataires (dans un VLAN de superposition) afin de mettre en miroir le trafic de manière sélective.

  1. Configurez une instance de mise en miroir de ports à la fois sur les branches 1 et 2. Le serveur 1 peut envoyer du trafic pour le VLAN 101 sur l’une ou l’autre de ses interfaces membres LAG. L’ECMP signifie que le trafic peut arriver à l’une ou l’autre des branches. L’adresse IP 172.16.1.2 est la station de surveillance.

  2. Ensuite, créez un filtre de pare-feu correspondant au sous-réseau affecté au VLAN 101 sur les deux branches. L’objectif est de mettre en miroir tout le trafic intra-VLAN 101 envoyé par le serveur 1 à la branche 1 ou la branche 2. Pour capturer le trafic inter-VLAN, spécifiez le sous-réseau du VLAN cible pour l'adresse de destination.

    Si vous devez filtrer plusieurs adresses IP source ou de destination, envisagez d’utiliser un source-prefix-list et/ou un destination-prefix-list dans votre filtre. Vous pouvez ainsi apporter des modifications à la liste des préfixes sans avoir à modifier la définition du filtre.

    Note:

    Si vous souhaitez mettre en miroir uniquement le trafic routée (entre VLAN), utilisez un family inet filtre appliqué à l'interface IRB du VLAN. Une seule interface IRB est définie pour chaque VLAN. Un filtre appliqué à l'interface IRB du VLAN capture donc tout le trafic inter-VLAN pour le VLAN associé, quel que soit le port du panneau avant sur lequel les passerelles de trafic sont reliées.

    La méthode indiquée dans cet exemple fonctionne pour le trafic inter-VLAN et intra-VLAN, mais nécessite l’application de filtres aux interfaces serveur en fonction de leur appartenance au VLAN. Un inet filtre appliqué à une interface IRB ne voit pas le trafic ponté (intra-VLAN).

  3. Appliquez le filtre de pare-feu en miroir de port distant à l’interface ae0.0 en tant que filtre d’entrée sur les deux feuilles.

    Note:

    Sur les commutateurs QFX5110 et QFX5120, le filtre de pare-feu ne peut pas être activé dans la direction sortante ou utilisé aux interfaces connectées aux équipements de cœur de réseau.

  4. La branche de bordure 3 n’a pas besoin d’être configurée pour effectuer la déscapsulation GRE puisque le tunnel GRE se termine à la station de surveillance. Toutefois, la branche 3 doit promouvoir l'accessibilité du sous-réseau de la station de surveillance dans l'underlay de la structure. Configurez l’interface xe-0/0/33:1 qui se fixe à la station de surveillance.

    Modifiez la stratégie d'exportation underlay au niveau de la branche de bordure 3 pour annoncer le préfixe de la station de surveillance. Notre topologie utilise un underlay EBGP. Nous ajoutons simplement un nouveau terme à la politique d’exportation sous-jacente existante.

  5. Les modifications apportées à la base de départ sont affichées à la branche 1.

    Vous avez réussi à configurer la mise en miroir de ports distants via un équipement de branche sur une structure EVPN-VXLAN ERB.

Vérification

  1. Vérifier la connectivité sous-jacente de la branche 1 à la station de surveillance.

    Sur la branche 1, affichez la route vers 172.16.1.0/24.

    Note:

    À proprement parler, seule une connectivité simple est requise entre la branche et la station de surveillance. Nous avons configuré une route statique sur la station de surveillance pour lui permettre d’atteindre l’underlay de structure. Cela permet de tester le ping en tant qu’outil d’isolation des pannes.

    Ping sur la station de surveillance pour confirmer la connectivité.

    La sortie confirme l’accessibilité underlay attendue de la branche 1 à la station de surveillance. Nous devons sourcer le ping à partir de l'adresse de bouclage de la branche, car notre stratégie d'exportation sous-jacente ne fait que promouvoir l'accessibilité de l'adresse loopback. Il n’est pas nécessaire de s’approvisionner à partir de l’adresse de bouclage dans le cas du lean spine. En effet, le cœur de réseau et la branche de bordure partagent une liaison de structure directement connectée.

  2. Confirmez l’instance de mise en miroir des ports sur la branche 1.

    Sur la branche 1, vérifiez que l’état de mise en miroir des ports distants est up.

    La sortie confirme la définition correcte de l’instance de mise en miroir des ports. L’état indique up que la branche comporte un itinéraire sous-jacent vers la station de surveillance. Rappelez-vous que GRE est un protocole sans état. C’est pourquoi il est bon de vérifier la connectivité entre la branche et la station de surveillance, comme nous l’avons fait à l’étape précédente.

  3. Vérifiez que le filtre appliqué aux branches 1 et 2 reflète correctement le trafic test. Lancez des pings entre le serveur 1 et le serveur 2 sur la structure.

    Vérifiez que le filtre appliqué aux branches 1 et 2 reflète correctement le trafic. Notre topologie exemple ne comporte qu’un seul VLAN et une paire de serveurs. Il est ainsi facile de corréler le trafic test pour filtrer les correspondances. Tout nombre non nul est un bon signe que le filtre fonctionne.

    En raison du comportement de l'ECMP, le flux ping unique ne contient qu'une seule liaison membre de l'interface Ethernet agrégée. Cela signifie que le trafic test doit être envoyé à une branche ou à l’autre, mais pas aux deux. Si le serveur 1 génère de nombreux flux, attendez-vous à voir les paquets transféré vers les deux feuilles à l’aide des deux interfaces membres.

    Effacer les compteurs juste avant de générer des pings.

    Affichez maintenant les compteurs de pare-feu sur les branches 1 et 2.

    La sortie indique qu’aucun paquet n’est visible au niveau de la branche 1. Cela indique que pour ce flux, le serveur est en hachage vers la branche 2.

    Vérifiez les compteurs de pare-feu à la branche 2 :

    Le compteur de pare-feu de la branche 2 reflète correctement le trafic de test généré.

  4. Vérifiez que le trafic envoyé entre le serveur 1 et le serveur 2 est mis en miroir aux branches 1 et/ou 2 pour une transmission à la station de surveillance.

    Une fois de plus, générez du trafic entre les serveurs 1 et 2 (non illustrés pour la brièveté). Utilisez l’option rapide de la commande ping pour générer un plus grand volume de paquets afin de faciliter la détection.

    Surveillez les compteurs de trafic d’interface au niveau de la branche de bordure 3 pour vérifier que le trafic test arrive à la station de surveillance.

    La sortie confirme que le trafic est envoyé à la station de surveillance. L’absence de paquets d’entrée est attendue car la station de surveillance ne génère aucune réponse au trafic GRE qu’elle reçoit.

  5. Utilisez Wireshark ou une application d’analyse équivalente pour capturer et décoder le trafic en miroir.

    Figure 7 : Analyse Mirrored Traffic Analysis du trafic en miroir

    La capture indique que le serveur 1 envoie du trafic ping au serveur 2. Le trafic de réponse n’est pas mis en miroir, car nous avons appliqué notre filtre aux branches 1 et 2 uniquement dans la direction d’entrée. Appliquez une instance en miroir de port similaire et une configuration de filtre à la branche 4 pour mettre en miroir le trafic de retour. Rappelez-vous que dans le cas du « lean spine », le trafic en miroir a montré l’encapsulation VXLAN. Dans ce cas de branche ERB, nous mettons en miroir le trafic de couche 2 avant qu’il n’ait été encapsulé dans VXLAN. Le filtre utilisé pour mettre en miroir le trafic est appliqué en tant que filtre d’entrée sur l’interface ae0.0 côté serveur. Il n’y a pas d’encapsulation VXLAN à l’entrée.

    Il en va de même pour l'application d'un filtre à l'interface IRB du VLAN. Dans le cas du filtrage IRB, le trafic en miroir ne contient pas non plus l’encapsulation VXLAN. Les filtres IRB traitent uniquement le trafic inter-VLAN au niveau de la couche IP. Ainsi, dans le cas du filtre IRB, seul le trafic IP de couche 3 est mis en miroir.

    Le décodage montre que le tunnel GRE se trouve entre la branche 2 et la station de surveillance via l’underlay. La trame Ethernet et le paquet IP envoyés par le serveur 1 sont également décodés. Les adresses IP attribuées aux serveurs sont visibles (10.1.100.x/24), tout comme les détails des paquets IP/ICMP générés par le serveur 1.

    Vous avez bien configuré la mise en miroir des ports sur votre topologie.

Exemple : activer une instance d’analyse à distance sur une interface ESI-LAG

Aperçu

Un identificateur de segment Ethernet (ESI) est le numéro unique de 10 octets qui identifie un segment Ethernet. L’ESI est activé à l’interface connectée au serveur. Lorsque plusieurs liaisons forment un groupe d’agrégation de liens (LAG), le résultat est une interface ESI-LAG, également connue sous le nom de LAG EVPN. Dans certains cas, vous devrez activer la mise en miroir des ports directement pour tout ou partie du trafic entrant ou sortant de l’interface ESI-LAG.

Les instances d’analyse de sortie et d’entrée sont prises en charge pour les interfaces ESI-LAG sur les équipements de branche dans une structure EVPN-VXLAN. Cette fonctionnalité est utile dans un centre de données où l’administrateur doit envoyer tout le trafic entrant ou sortant d’un port ESI-LAG vers, ou depuis, un hôte distant. Utilisez cette section pour activer une instance d’analyse au niveau ESI-LAG d’une structure ERB EVPN-VXLAN.

Une instance d’analyseur diffère d’une instance de mise en miroir de port dans le fait que l’analyseur fonctionne dans l’entrée, la sortie ou dans les deux directions. Il met également en miroir tout le trafic sur l’interface. Par exemple, si le serveur 1 dispose de 10 VLAN utilisant une interface d’agrégation, le trafic de l’ensemble des 10 VLAN est envoyé à la station de surveillance. Dans l’exemple précédent de mise en miroir des ports, un filtre permet la mise en miroir sélective du trafic d’un VLAN ou d’adresses IP spécifiques dans un VLAN.

Les instances d'analyse n'utilisent pas de filtres de pare-feu pour une correspondance granulaire. Tout le trafic dans la direction spécifiée sur l’interface spécifiée est mis en miroir.

Topologie

Cet exemple de configuration utilise les composants matériels et logiciels indiqués dans La configuration requise. Les équipements de la topologie commencent par les configurations de base fournies dans l’annexe : Configurations complètes des équipements.

Dans cet exemple, une interface ESI-LAG, également connue sous le nom de LAG EVPN, est utilisée entre le serveur 1 et la branche 1 et la branche 2. Consultez les meilleures pratiques de configuration EVPN LAG pour connaître les meilleures pratiques.

Note:

Vous pouvez configurer l’instance d’analyse sur un commutateur ACX7100 exécutant Junos OS Evolved 22.3R1 ou version ultérieure.

La figure 8 illustre la topologie de cet exemple.

Figure 8 : Topologie de l’outil d’analyse à distance sur une interface Topology of Remote Analyzer on an ESI-LAG Interface ESI-LAG

L’interface ae0.0 est l’interface ESI-LAG jointe au serveur 1. Le serveur 1 se voit attribuer l’adresse IP 10.1.101.10/24 et est associé au VLAN 101. L’objectif est de configurer une instance d’analyse afin de transférer tout le trafic envoyé et reçu sur l’interface ae0.0 au niveau des branches 1 et 2. Le trafic en miroir est placé dans un tunnel GRE et envoyé à la station de surveillance. Comme auparavant, vous devez vous assurer que le sous-réseau de la station de surveillance est joignable dans l’underlay EBGP.

Note:

Les deux cœurs de réseau sont opérationnels dans cette topologie. ECMP signifie que les branches 1 et 2 peuvent envoyer du trafic via l’un ou l’autre équipement de cœur de réseau. Pour réduire l’encombrement dans le dessin, nous montrons le trafic et les chemins en miroir avec l’équipement de cœur de réseau 1 comme point de mire.

Avant de commencer

Si vous partez de la configuration de base indiquée dans l’annexe : Configurations complètes des équipements, suivez ces étapes pour modifier votre topologie avant de commencer.

  1. Modifiez la configuration des branches 1 et 2 pour prendre en charge la connexion multi-utilisateur du serveur 1. Nous commençons par rebaptiser l’interface xe-0/0/0/0 existante pour en faire la nouvelle interface ae0.0. Cette configuration s’adapte à toutes les configurations de l’interface xe-0/0/0 pour gagner du temps.

    Les spécificités de configuration de l'interface Ethernet agrégée du serveur, souvent appelée interface de liaison sous Linux, dépassent la portée de cette NCE. À noter que, pour le serveur, il n’existe qu’une configuration Ethernet agrégée standard. Les instructions relatives à ESI-LAG sont appliquées uniquement aux équipements de branche.

    Note:

    La configuration de base de départ permet d’agréger un équipement Ethernet à l’aide de l’instruction de set chassis aggregated-devices ethernet device-count 1 configuration. Vous devez activer la prise en charge du châssis pour les équipements agrégés ou l’interface agrégée n’est pas créée.

  2. Après avoir appliqué et appliqué ces modifications aux équipements de branche et au serveur, vérifiez que l’interface ae0 est disponible sur les deux branches. L’exemple ci-dessous a été raccourci par souci de clarté.

    Vérifiez que le serveur 1 est capable d’envoyer un ping au serveur 2 (ce qui n’est pas indiqué pour la brièveté).

Configuration

Cet exemple montre comment activer la mise en miroir des ports distants au niveau ESI-LAG à l’aide d’une instance d’analyse à distance.

  1. L’interface ae0.0 est l’interface ESI-LAG où se connecte le serveur locataire 1. Cet ESI-LAG se termine aux branches 1 et 2. Configurez l’instance d’analyse dans les deux feuilles pour l’interface ae0.0. Notez que vous configurez un outil d’analyse distant pour les directions d’entrée et de sortie.

  2. La branche de bordure 3 n’a pas besoin d’être configurée pour effectuer la décapsulation GRE puisque le tunnel GRE se termine à la station de surveillance. Toutefois, la branche 3 doit promouvoir l'accessibilité du sous-réseau de la station de surveillance dans l'underlay de la structure.

    Configurez l’interface xe-0/0/33:1 qui se fixe à la station de surveillance.

    Modifiez la stratégie d'exportation underlay au niveau de la branche de bordure 3 pour annoncer le préfixe de la station de surveillance. Notre topologie utilise un underlay EBGP. Nous ajoutons simplement un nouveau terme à la politique d’exportation sous-jacente existante.

  3. Les modifications par rapport à la base de départ sont affichées à la branche 1.

    Vous avez réussi à configurer la mise en miroir de ports distants via un équipement de branche sur une structure EVPN-VXLAN ERB.

Vérification

  1. Vérifiez la connectivité sous-jacente des branches 1 et 2 à la station de surveillance.

    Sur la branche 1, affichez la route vers 172.16.1.0/24.

    Note:

    À proprement parler, seule une connectivité simple est requise entre la branche et la station de surveillance. Nous avons configuré une route statique sur la station de surveillance pour lui permettre d’atteindre l’underlay de structure. Cela permet de tester le ping en tant qu’outil d’isolation des pannes.

    Ping sur la station de surveillance pour confirmer la connectivité.

    La sortie confirme l’accessibilité underlay attendue de la branche 1 à la station de surveillance. Nous devons sourcer le ping à partir de l'adresse de bouclage de la branche, car notre stratégie d'exportation sous-jacente ne fait que promouvoir l'accessibilité de l'adresse loopback. Il n’était pas nécessaire de s’approvisionner à partir de l’adresse de bouclage dans l’exemple du « lean spine », car le cœur de réseau et la branche de bordure sont directement reliés par un sous-réseau de liaison de structure partagée.

  2. Confirmez l’instance de l’analyseur sur les branches 1 et 2.

    Sur la branche 1, vérifiez que l’état de l’analyseur distant est up.

    La sortie confirme la définition correcte de l’instance d’analyse. L’état indique up que la branche comporte un itinéraire sous-jacent vers la station de surveillance. Rappelez-vous que GRE est un protocole sans état. C’est pourquoi il est bon de vérifier la connectivité entre la branche et la station de surveillance, comme nous l’avons fait à l’étape précédente.

  3. Vérifiez que le trafic envoyé entre le serveur 1 et le serveur 2 est mis en miroir par les branches 1 et/ou 2 vers la station de surveillance.

    Une fois de plus, générez du trafic entre les serveurs 1 et 2 (non illustrés pour la brièveté). Nous avons utilisé l’option rapide pour la commande ping pour générer un plus grand volume de paquets afin de faciliter la détection.

    Surveillez les compteurs de trafic d’interface au niveau de la branche de bordure 3 pour vérifier que le trafic test arrive à la station de surveillance.

    La sortie confirme que le trafic arrive à la station de surveillance. L’absence de paquets en entrée est attendue, car la station de surveillance ne génère aucune réponse au trafic GRE qu’elle reçoit.

  4. Utilisez Wireshark ou une application d’analyse équivalente pour capturer et décoder le trafic en miroir.

    Figure 9 : Analyse Mirrored Traffic Analysis du trafic en miroir

    La capture indique que le serveur 1 envoie du trafic ping au serveur 2. En raison des instances d’analyse appliquées aux deux directions de l’interface ae0.0, le trafic de réponse est également mis en miroir. Étant donné que l’analyseur fonctionne au niveau de l’interface, le LACP, qui est un protocole de niveau liaison utilisé sur l’interface Ethernet agrégée, est également mis en miroir. Rappelez-vous que dans le cas du « lean spine », le trafic en miroir a montré l’encapsulation VXLAN. Dans ce cas de branche ERB, nous capturons le trafic de couche 2 avant qu’il ne soit encapsulé dans VXLAN. À l’entrée, il n’y a pas d’encapsulation VXLAN.

    Il en va de même pour l'application d'un filtre à l'interface IRB d'un VLAN. Dans ce cas, le trafic en miroir ne contient pas non plus l’encapsulation VXLAN. Les filtres IRB capturent uniquement le trafic inter-VLAN au niveau de la couche IP. Ainsi, dans le cas du filtre IRB, seul le trafic IP de couche 3 encapsulé non VXLAN est mis en miroir.

    Le décodage montre que le tunnel GRE se situe entre la branche 2 (10.1.12.2) et la station de surveillance via l’underlay. La trame Ethernet et les paquets IP associés, tels qu’envoyés par le serveur 1, sont également décodés. Les adresses IP attribuées aux serveurs sont visibles (10.1.100.x/24), tout comme les détails des paquets IP/ICMP générés par le serveur 1. La réponse du serveur 2 est également mise en miroir, car l’instance de l’analyseur est appliquée bidirectionnellement dans notre exemple.

    Vous avez bien configuré la mise en miroir des ports sur votre topologie.

Documentation connexe