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 des ports locaux sur des plates-formes PTX exécutant Junos Evolved. Les plates-formes PTX comprennent les châssis PTX10001-36MR, LC1201 et LC1202 dans les 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

Consultez l’explorateur de fonctionnalités pour obtenir la liste complète des plates-formes prises en charge et des versions de Junos OS.

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 voir les interactions entre les protocoles ou pour détection des anomalies.

En savoir plus

Pour mieux comprendre la mise en miroir des ports, consultez Mise en miroir des ports et analyseurs

Pour en savoir plus

 Portail de formation

Aperçu fonctionnel

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

Tableau 1 : présentation fonctionnelle de la mise en miroir des 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 équipements CE et PE/P font partie du même domaine de routage IGP. Par conséquent, plus besoin de tunnels entre les équipements PE pour transporter le trafic CE sur le cœur du réseau. 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 surveillance)

Centos et Wireshark

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

Présentation de la topologie

Dans cet exemple, l’équipement R3 fonctionne comme l’équipement sous test (DUT), car c’est ici que la mise en miroir des ports est configurée. L’équipement utilise des filtres de pare-feu pour faire correspondre les adresses IP associées aux appareils CE afin de déclencher l’action de mise en miroir des ports. Une combinaison de filtres entrants et de sortie est utilisée pour refléter le trafic de demande et de réponse circulant entre les équipements CE (R1 et R5).

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

Tableau 2 : Présentation de la topologie de la mise en miroir des ports locaux
Nom de l’appareil

Rôle

 Fonction
CE Appareil CE (Customer Edge) qui envoie du trafic de test pour confirmer le bon fonctionnement de l’échantillonnage. Ces équipements sont désignés comme équipements CE. Dans la plupart des cas, un appareil CE fait partie d’un service VPN. Ici, nous laissons les CE partager la même zone OSPF 0 que les appareils du fournisseur pour fournir la connectivité IP de l’instance principale.
PE Équipement PE (Provider Edge) qui se connecte au CE. Appareils en périphérie du réseau d’un fournisseur. Nos PE utilisent uniquement OSPF. Les protocoles BGP et 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 recevait le trafic miroir pour le stockage et l’analyse. Les spécificités de l’analyseur dépassent le cadre de ce 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
Network diagram showing routers R1 to R5 with IPs 172.16.1.1 and 172.16.2.1, connected via networks 10.0.12.0/24 to 10.0.45.0/24. Loopbacks 192.168.0.1/32 to 192.168.0.4/32. Switch S1 connects to R3. Used for CE-CE Lo0 pings.

Étapes de configuration R3

Pour plus d’informations sur la navigation dans la CLI, consultez Utilisation de l’éditeur CLI en mode Configuration

Remarque :

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

Cette section met en évidence les principales tâches de configuration nécessaires pour configurer le 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 routage IPv4 et IPv6. Cela inclut la numérotation des interfaces de bouclage et principales 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. L’interface est ainsi accessible à des fins de diagnostic sans que des paquets Hello ne soient générés sur l’interface. Une contiguïté OSPF n’est pas attendue ou nécessaire au dispositif d’analyse

    Remarque : Dans le cas d’utilisation du miroir local, la connectivité IP est uniquement nécessaire entre l’analyseur et l’appareil qui effectue la mise en miroir des ports. Dans cet exemple, nous exécutons un IGP passif sur l’interface attachée à l’analyseur. Nous configurons également une route par défaut sur l’analyseur pour assurer la 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 capacité est particulièrement utile dans le cas d’un miroir de port distant où l’accessibilité de la couche 3 doit être comprise entre l’appareil 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 0 est laissée en place car tout le trafic correspondant est déjà échantillonné. Vous devez également spécifier l’interface de sortie et l’adresse du saut suivant vers lesquelles le trafic mis 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.
    Remarque :

    Cette configuration suppose que l’analyseur répond aux requêtes ARP et ND envoyées par le pare-feu pour la résolution d’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 connecté au DUT.

  3. Définissez le filtre de pare-feu à appliquer aux paquets IPv4, puis mettez-les en miroir. Notez que l'action du filtre spécifie une action de mise en miroir des ports. Cette action dirige le trafic correspondant vers les instances de mise en miroir de ports que vous avez configurées précédemment. Deux filtres sont définis, un pour chacune des adresses source et 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 terme final accept-all 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 de filtrage. Pour chaque flux de trafic CE (IPv4 ou IPv6), nous appliquons un filtre comme entrant et l’autre comme sortant. Cette méthode d’application est compatible avec la façon dont les filtres sont écrits, compte tenu des affectations d’adresses et de la directionnalité du trafic.

Vérification

  1. Confirmez les voisins et les routes OSPF et OSPF3 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 l’interface de mise en miroir. Assurez-vous de confirmer l’état up des familles IPv4 et IPv6. Ici, c’est une bonne idée de confirmer la connectivité IP entre le pare-feu et l’analyseur. Dans notre configuration, une route par défaut est configurée sur l’analyseur pour permettre de tester ping depuis tous les points du réseau. Techniquement, l’analyseur doit être accessible uniquement par le DUT (R3), car il s’agit d’un exemple de mise en miroir de ports locaux.

  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 du pare-feu sur R3. Vérifiez que les filtres appliqués à R3 reflètent correctement le trafic de test.

  4. Affichez les compteurs du 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. Affiche les statistiques de 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 reflétons à la fois les requêtes 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 le centre 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 une correspondance de filtre de pare-feu, fonctionne comme prévu. Notez que le trafic des demandes et des réponses 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 pare-feu (R3) lors du transfert du trafic en miroir vers 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 devez conserver la trame de couche 2 d’origine.

Annexe : Définir 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 à votre configuration réseau, puis copiez-collez les commandes dans la CLI au niveau de la hiérarchie [modifier].

R1 (CE)

R2 (PE)

R3 (DUT)

R4 (PE)

R5 (CE)