Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Exemple : Configuration de la mise en miroir des ports locaux sur les routeurs PTX

Cet exemple vous montre comment configurer et vérifier la mise en miroir de ports locaux sur les plates-formes PTX exécutant Junos Evolved. Les plates-formes PTX comprennent PTX10001-36MR, LC1201 et LC1202 en châssis PTX10004, PTX10008 et PTX10016

Avant de commencer

Exigences matérielles et logicielles

Junos OS Evolved version 22.2R1.12-EVO ou ultérieure.

PTX10001-36MR

Voir Explorateur de fonctionnalités pour obtenir la liste complète des plates-formes et des versions de Junos OS prises en charge.

Temps de lecture estimé

Quinze minutes.

Temps de configuration estimé

 Trente minutes

Impact sur l’entreprise

Utilisez cet exemple de configuration pour configurer la fonctionnalité de mise en miroir des ports locaux. Le miroir de port est un outil essentiel pour le débogage et les tâches liées à la sécurité. Le trafic miroir peut être analysé hors ligne par divers outils pour observer les interactions de protocole ou détecter des anomalies.

En savoir plus

Pour mieux comprendre la mise en miroir de ports, reportez-vous à la section Mise en miroir de ports et analyseurs

Pour en savoir plus

 Portail de formation

Vue d’ensemble fonctionnelle

Le Tableau 1 fournit un résumé rapide des protocoles et technologies déployés dans cet exemple.

Tableau 1 : présentation fonctionnelle de la mise en miroir de ports locaux

Protocoles de routage et de signalisation

OSPF et OSPF3

Tous les routeurs exécutent OSPF et OSPF3 en tant qu’IGP. Tous les routeurs appartiennent à la zone 0 (également appelée zone dorsale). Les domaines de routage OSPF/OSPF3 offrent une accessibilité interne à tous les réseaux et interfaces de la topologie.

Dans cet exemple, les appareils CE et PE/P font partie du même domaine de routage IGP. Par conséquent, il n’est pas nécessaire d’établir des tunnels entre les équipements PE pour transporter le trafic CE sur le réseau central. De plus, comme il s’agit d’un cas d’utilisation de miroir local, l’encapsulation GRE n’est pas nécessaire lors de l’envoi de trafic en miroir à la station de surveillance.

Protocoles de routage

IPv4 et IPv6

Tous les équipements sont configurés pour prendre en charge le routage IPv4 et IPv6.

Analyseur (station de télésurveillance)

Centos et Wireshark

L’analyseur exécute Centos 7.x avec une version GUI de Wireshark.

Vue d’ensemble de la topologie

Dans cet exemple, le périphérique R3 fonctionne comme le périphérique sous test (DUT) car c’est là que la mise en miroir des ports est configurée. Le périphérique utilise des filtres de pare-feu pour faire correspondre les adresses IP associées aux périphériques CE afin de déclencher l’action de mise en miroir du port. Une combinaison de filtres d’entrée et de sortie est utilisée pour mettre en miroir le trafic de demande et de réponse circulant entre les périphériques CE (R1 et R5).

Les filtres de pare-feu qui évoquent l’échantillonnage de paquets sont appliqués à une ou plusieurs interfaces de transit sur le périphérique R3.

Tableau 2 : Vue d’ensemble de la topologie de mise en miroir des ports locaux
Nom de l’appareil

Rôle

 Fonction
CE Dispositif CE (Customer Edge) qui envoie du trafic de test pour confirmer que l’échantillonnage fonctionne correctement. Ces appareils sont désignés comme des dispositifs CE. Dans la plupart des cas, un appareil CE fait partie d’un service VPN. Ici, nous laissons le CE partager la même zone OSPF 0 que les périphériques du fournisseur pour fournir la connectivité IP de l’instance principale.
PE Périphérique Provider Edge (PE) qui se connecte au CE. Appareils à la périphérie d’un réseau de fournisseur. Nos PE fonctionnent uniquement avec OSPF. BGP et les VPN ne sont pas déployés.
P Un routeur central Provider (P). Nous choisissons de faire une démonstration de la mise en miroir des ports sur un routeur P. Vous pouvez configurer la mise en miroir des ports sur n’importe quel appareil du fournisseur selon vos besoins.
Analyseur L’appareil d’analyse a reçu le trafic miroir pour le stockage et l’analyse. Les spécificités de l’analyseur sortent du cadre du présent document. Il existe un certain nombre d’options open source et commerciales disponibles. Il se trouve que notre analyseur exécute Centos 7.x avec un bureau Gnome prenant en charge une version GUIO de Wireshark.

Illustrations de topologie

Figure 1 : mise en miroir des ports locaux

Étapes de configuration R3

Pour plus d’informations sur la navigation dans l’interface de ligne de commande, consultez Utilisation de l’éditeur CLI en mode configuration

Note:

Pour une configuration complète sur tous les appareils, reportez-vous à l’annexe 2 : Définir les commandes sur tous les appareils

Cette section met en évidence les principales tâches de configuration nécessaires à la configuration du DUT, qui est le périphérique P (R3) dans cet exemple. À l’exception des spécificités utilisées pour l’échantillonnage, tous les équipements ont une configuration de base similaire qui prend en charge la connectivité IPv6 et IPv4 de l’instance principale.

  1. Configurez la base de référence du routage IPv4 et IPv6. Cela inclut la numérotation des interfaces de bouclage et de cur pour IPv4 et IPv6. Vous définissez également les protocoles de routage OSPF et OSPFv3 pour assurer l’accessibilité entre toutes les interfaces réseau.

    Une instance IGP passive est provisionnée pour l’interface attachée à l’analyseur. Cela permet d’être accessible à des fins de diagnostic sans que des paquets hello ne soient générés sur l’interface. Aucune contiguïté OSPF n’est attendue ou nécessaire pour l’analyseur

    Note: Pour le cas d’utilisation du miroir local, la connectivité IP n’est nécessaire qu’entre l’analyseur et l’appareil effectuant la mise en miroir des ports. Dans cet exemple, nous exécutons un IGP passif sur l’interface connectée à l’analyseur. Nous configurons également une route par défaut sur l’analyseur pour fournir une connectivité IP entre celui-ci et les autres appareils. Cela permet de tester la connectivité entre l’analyseur et tous les autres appareils. dans la topologie.

    Cette fonctionnalité est particulièrement utile dans un cas miroir de port distant où il est nécessaire d’avoir une accessibilité de couche 3 entre le dispositif d’échantillonnage et l’analyseur.
  2. Configurez la fréquence d’échantillonnage. Nous utilisons un taux de 1 pour sélectionner et échantillonner tous les paquets correspondants. La valeur par défaut run-length de 0 est laissée en place étant donné que tout le trafic correspondant est déjà échantillonné. Vous devez également spécifier l’interface de sortie et l’adresse du tronçon suivant vers lequel le trafic en miroir est envoyé. Dans cet exemple de miroir de port local, il convient de noter que les adresses d’interface et de saut suivant spécifiées sont directement attachées au DUT. Par conséquent, aucun tunnel n’est nécessaire ou utilisé pour envoyer le trafic en miroir à l’analyseur.
    Note:

    Cette configuration suppose que l’analyseur répond aux demandes ARP et ND envoyées par le DUT pour la résolution de l’adresse MAC. Si ce n’est pas le cas, ou si vous souhaitez que le trafic ARP ne fasse pas partie de vos captures de paquets, vous devez configurer une entrée ARP statique. Assurez-vous de spécifier l’adresse MAC correcte pour l’interface sur le périphérique d’analyse qui est connecté au DUT.

  3. Définissez le filtre de pare-feu à mettre en correspondance sur les paquets IPv4, puis mettez-les en miroir. Notez que l'action du filtre spécifie une action de mise en miroir de port. Cette action dirige le trafic correspondant vers les instances de mise en miroir de port que vous avez configurées précédemment. Deux filtres sont définis, un pour les adresses source et un pour les adresses de destination de CE1 et CE2, respectivement. Les filtres comprennent une fonction de comptage pour aider à confirmer le bon fonctionnement.

    Ne négligez pas le dernier accept-all terme qui remplace l'action par défaut deny-all d'un filtre de pare-feu Junos !

  4. Définissez le filtre de pare-feu pour qu’il corresponde aux paquets IPv6 et les mette en miroir.

  5. Appliquez les filtres IPv4 et IPv6 aux interfaces souhaitées. Dans notre exemple, nous appliquons les deux filtres à l’interface et-0/0/0. Notez la directionnalité de l’application du filtre. Pour chaque flux de trafic CE (IPv4 ou IPv6), nous appliquons un filtre en entrée et l’autre en sortie. Cette méthode d’application est compatible avec la façon dont les filtres sont écrits, compte tenu de l’affectation des adresses et de la directionnalité du trafic.

Vérification

  1. Confirmez les voisins OSPF et OSPF3 et les routes vers toutes les adresses de bouclage.

  2. Confirmez l’instance de mise en miroir des ports sur R3. Vérifiez que l’état de mise en miroir des ports correspond up à celui de l’interface de mise en miroir. Veillez à vérifier l’état up des familles IPv4 et IPv6. Pendant que vous êtes ici, c’est une bonne idée de confirmer la connectivité IP entre le DUT et l’analyseur. Dans notre configuration, une route par défaut est configurée sur l’analyseur pour permettre les tests ping à partir de tous les points du réseau. Techniquement, l’analyseur ne doit être accessible que par le DUT (R3), car il s’agit d’un exemple de mise en miroir de port local.

  3. Effacez les compteurs de pare-feu et les statistiques d’interface sur R3. Ensuite, générez du trafic de test IPv4 et IPv6 entre les appareils CE et affichez les compteurs de pare-feu sur R3. Vérifiez que les filtres appliqués à R3 reflètent correctement le trafic de test.

  4. Affichez les compteurs de pare-feu sur R3. Vérifiez si les filtres appliqués à R3 reflètent correctement le trafic de test que vous avez généré.

  5. Afficher les statistiques de l'interface pour l'interface et-0/0/2.0 de R3 qui est attachée à l'analyseur. L’objectif est de confirmer les compteurs de trafic de sortie qui correspondent au trafic de test généré. Avec dix pings pour IPv4 et IPv6, et étant donné que nous mettons en miroir à la fois la requête et les réponses, vous pouvez vous attendre à voir environ 40 paquets de sortie.

  6. Exécutez tcpdump ou l’application d’analyse de votre choix sur la station de surveillance pour confirmer la réception et le traitement du trafic de test en miroir. Pour réduire la taille de la capture, nous avons généré un nouveau trafic de test avec seulement deux requêtes ping pour chaque IPv4 et IPv6. La capture et le décodage confirment que la mise en miroir des ports IPv4 et IPv6, basée sur la correspondance d’un filtre de pare-feu, fonctionne comme prévu. Notez que le trafic de requête et de réponse est affiché.

    De plus, dans la capture, notez que seul le trafic de couche 3 est mis en miroir. L’encapsulation de couche 2 illustrée est générée par le DUT (R3) lors du transfert du trafic en miroir à l’analyseur. Vous pouvez configurer la mise en miroir des ports pour les services de couche 2 tels que la commutation Ethernet ou VXLAN lorsque vous avez besoin de préserver la trame de couche 2 d’origine.

Annexe : Définition des commandes sur tous les appareils

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la hiérarchie [modifier].

R1 (CE)

R2 (PE)

R3 (DUT)

R4 (PE)

R5 (CE)