Exemple : configuration de la mise en miroir des ports distants sur les routeurs PTX

La présentation fonctionnelle de la mise en miroir des ports distants fournit un résumé rapide des protocoles et technologies déployés dans cet exemple.

Cet exemple utilise le contexte d’un VPN L3 basé sur MPLS pour démontrer la fonctionnalité de mise en miroir de ports distants sur les routeurs PTX. Le VPN L3 est configuré pour prendre en charge le trafic IPv4 et IPv6 entre les routeurs de périphérie client (CE) et de périphérie fournisseur (PE).

Figure 1 : mise en miroir des ports distants

Cet exemple illustre deux façons de mettre en miroir le trafic CE envoyé sur le réseau du fournisseur :

• La première méthode utilise un filtre de correspondance sur l’interface VRF PE-CE.

• La deuxième méthode illustre un filtre de correspondance d’étiquettes MPLS qui est appliqué sur le routeur du fournisseur (P).

Le routeur PE1 (R2) et le routeur P (R3) sont les routeurs sur lesquels la mise en miroir des ports distants est configurée et fonctionnent comme nos DUT. Ces routeurs utilisent des filtres de pare-feu familiaux any pour la mise en miroir de ports sur le trafic sélectionné. 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 routeurs CE (R1 et R5).

La mise en miroir des ports distants utilise un tunnel pour que l’encapsulation GRE envoie le trafic mis en miroir vers un équipement d’analyse à distance. Notre topologie comporte deux analyseurs. L’un est attaché au routeur R2/PE1 et l’autre au routeur R3/P. Cela nous permet de démontrer deux façons de mettre en miroir le trafic CE, l’une au niveau d’un PE et l’autre sur un routeur P central. Nous utilisons un hôte Centos avec Wireshark pour la capture et l’analyse des paquets.

Les plates-formes PTX utilisent l’infrastructure fti (Flexible Tunnel Interface) pour prendre en charge diverses applications de tunneling. Dans le cas des miroirs de port distants, les tunnels GRE sont configurés sur les interfaces FTI pour transporter le trafic mis en miroir vers un équipement d’analyse distant. Dans cet exemple, vous allez configurer des tunnels GRE basés sur FTI, une instance de mise en miroir et les filtres de pare-feu qui sélectionnent le trafic à mettre en miroir.

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

Cette section met en évidence les tâches de configuration nécessaires pour configurer le routeur PE1/R2 dans cet exemple. Nous fournissons les configurations complètes de tous les routeurs dans l’annexe. L'étape 1 résume la base de référence de l'exemple. Cette base se compose de la connectivité IPv4 et IPv6, du MPLS et d’un VPN de couche 3. Notre exemple met l’accent sur la configuration et la vérification de la mise en miroir des ports distants.

1. Configurez le routage IP et la base VPN L3 sur le routeur PE1. Il s’agit des éléments suivants :

   1. numérotation des interfaces IPv4 et IPv6 et inclusion family mpls de la prise en charge des interfaces centrales.

   2. Configurer les protocoles de routage OSPF et OSPFv3 pour assurer l’accessibilité entre toutes les interfaces réseau.

   3. Les chemins de commutation d’étiquettes RSVP et MPLS (LSP) permettent de prendre en charge le trafic VPN L3.

   4. Configuration de l’appairage VRF et BGP avec les familles d’adresses d’un inet-vpn and inet6-vpn routeur PE. Notre exemple VRF utilise OSPF et OSPF3 comme protocole de routage PE-CE.

   Une fois la base de référence couverte, les étapes restantes se concentrent sur la configuration du routeur R2/PE1 pour mettre en miroir tout le trafic envoyé et reçu sur son interface VRF orientée CE1.

2. Vous commencez par configurer le tunnel GRE. Sur un routeur PTX, le tunnel est implémenté sur une interface FTI. L’adresse source du tunnel GRE n’a pas besoin d’être routable, sauf si vous prévoyez d’effectuer des tests de diagnostic ping provenant de la source du tunnel GRE ou destinée à celle-ci. La destination GRE du trafic mis en miroir par PE1 est le routeur analyseur 1. Cette destination doit être accessible pour que le trafic miroir soit envoyé à l’analyseur. Nous utilisons une instance IGP passive pour garantir l’accessibilité de l’IGP aux réseaux d’analyse.

   L’adresse de destination est mappée au périphérique Analyzer 1 connecté à l’interface et-0/0/2 sur le routeur P/R3. Vous devez configurer l’interface logique fti avec pour family ccc prendre en charge la mise en miroir de ports distants sur le PTX. En effet, l’action de mise en miroir se produit au niveau de la couche 2.

   Remarque :

   Une instance IGP passive est provisionnée pour les interfaces attachées aux périphériques d’analyse. Cela confère une accessibilité IGP aux ports d’analyse pour le trafic en miroir encapsulé GRE. Le paramètre passif empêche la génération de paquets hello aux analyseurs car cela ne ferait qu’encombrer les captures.

   De plus, nous avons configuré une route statique sur l’appareil d’analyse pour lui permettre de répondre aux pings afin d’aider aux tests de diagnostic. À proprement parler, seule la connectivité ou le routage simplex est nécessaire entre les dispositifs de forage et l’analyseur pour que la mise en miroir des ports distants fonctionne.

3. Configurez l’instance d’échantillonnage. Nous utilisons un taux de 1 pour échantillonner tous les paquets correspondants. La valeur par défaut run-length 1 est laissée en place, car tout le trafic correspondant est déjà échantillonné. Vous devez spécifier l’interface logique sur le routeur fti utilisée pour transporter le trafic miroir. Vous avez configuré unit 1 l’interface fti0 pour le tunnel GRE à l’étape précédente, de sorte que la même interface et la même unité sont spécifiées comme interface de sortie dans l’instance miroir.
   Remarque :

   Vous pouvez spécifier une longueur maximale de paquet pour le trafic mis en miroir dans la hiérarchie avec l’option [edit forwarding-options port-mirroring instance instance-name input] maximum-packet-length . Par défaut, la longueur du paquet est de 0, ce qui signifie que le paquet entier est mis en miroir.

4. Définissez deux filtres de pare-feu de famille any pour correspondre et refléter le trafic CE. Deux filtres sont définis, l’un pour mettre en miroir le trafic CE1 vers CE2 et l’autre pour mettre en miroir CE2 vers CE1. Les filtres comprennent une fonction de comptage pour faciliter la vérification. L’action de mise en miroir des ports dirige le trafic correspondant vers l’instance de mise en miroir des ports que vous avez configurée précédemment.

   Les filtres de famille any prennent en charge la correspondance de couche 2 et de couche 3. Pour le premier, vous pouvez faire correspondre l’ID VLAN, l’interface, l’adresse MAC ou l’étiquette MPLS. Pour ce dernier, vous pouvez faire correspondre les champs d’en-tête IPv4 ou IPv6 standard.

   Pour notre topologie, nous utilisons un terme de correspondance qui intercepte tout le trafic envoyé ou reçu par les CE. Cela inclut IPv4, IPv6, ARP, LLDP et tout protocole de routage tel qu’OSPF.

   Les deux filtres se terminent par un terme d’acceptation correspond à tous pour remplacer l’action de refus de tout par défaut à la fin d’un filtre Junos. De cette façon, le trafic qui n’est pas mis en correspondance dans le premier terme est accepté. Ce terme est ajouté à titre de garantie dans le cas où ultérieurement une condition de correspondance spécifique est ajoutée au premier terme.

   Si vous le souhaitez, vous pouvez évoquer une action de contrôle dans votre filtre pour limiter le nombre de paquets en miroir envoyés sur le tunnel GRE. Le mécanisme de contrôle est défini avec une limite de bande passante et de rafale, ainsi qu’une action de rejet pour le trafic qui dépasse le mécanisme de contrôle.

   Vous ne pouvez pas appliquer un filtre PM avec une action de policer dans le sens de sortie.
   Remarque :

   Si vous souhaitez faire correspondre uniquement le trafic ICMP envoyé entre les adresses de bouclage IPv4 des équipements CE, ajoutez des critères de correspondance de couche 3 à votre filtre.

5. Appliquez les filtres à l’interface orientée CE sur R2/PE1. Pour notre exemple, cela signifie l’application des filtres à l’interface et-0/0/0 sur PE1. Notez la directionnalité de l’application de filtrage. Un filtre entrant et sortant est nécessaire pour refléter les deux sens du flux de trafic CE.

Par souci d’exhaustivité, nous montrons la configuration de R2/PE1 sous forme d’accolades.

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

Cette section met en évidence les principales tâches de configuration nécessaires pour configurer le routeur P/R3 dans cet exemple. Nous commençons par la base VPN L3 basée sur le MPLS. Ensuite, nous montrons les étapes nécessaires pour configurer la mise en miroir des ports distants sur un routeur P afin de faire correspondre et de mettre en miroir le trafic MPLS.

1. Configurez le routage IPv4 et IPv6 et la base de référence MPLS sur le routeur P/R3. Cela implique plusieurs choses :

   1. numérotation des interfaces IPv4 et IPv6 et inclusion family mpls de la prise en charge des interfaces centrales.

   2. Configurez les protocoles de routage OSPF et OSPFv3 pour assurer l’accessibilité entre toutes les interfaces réseau.

   3. RSVP et MPLS pour prendre en charge le plan de données VPN L3. En tant que routeur P, l’appairage BGP et les définitions VRF ne sont pas présents.

      Le routeur P1/R3 se connecte à l’analyseur 1 via l’interface et-0/0/2 . Nous désactivons le protocole RSVP et la prise en charge de MPLS sur cette interface, car le trafic en miroir arrive au format IPv4 à l’aide de l’encapsulation GRE. Les LSP ne s'étendent pas à l'analyseur.

      Remarque :

      La configuration d’interface et-0/0/2 utilisée ici suppose que l’analyseur répond aux requêtes ARP et ND envoyées par le DUT 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.

   Une fois la base de référence couverte, les étapes suivantes se concentrent sur la configuration de la mise en miroir des ports distants pour le trafic MPLS sur un routeur P.

2. Vous commencez par définir le tunnel GRE. Sur les plateformes PTX, les tunnels sont implémentés sur une interface FTI . L’adresse source du tunnel GRE n’a pas besoin d’être routable, sauf si vous prévoyez d’effectuer des tests de diagnostic ping provenant de la source du tunnel GRE ou destinée à celle-ci. La destination GRE du trafic en miroir est le périphérique Analyzer 2 connecté à PE2/R4. Cette destination doit être accessible pour que le trafic miroir soit envoyé à l’analyseur. Nous utilisons une instance IGP passive pour garantir l’accessibilité de l’IGP aux réseaux d’analyse.

   Vous devez configurer l’interface logique fti avec pour family ccc prendre en charge la mise en miroir de ports distants sur le PTX. En effet, l’action de mise en miroir se produit au niveau de la couche 2.

   Remarque :

   Une instance IGP passive est provisionnée pour les interfaces attachées aux périphériques d’analyse. Cela confère une accessibilité IGP aux ports d’analyse pour le trafic en miroir encapsulé GRE. Le paramètre passif empêche la génération de paquets hello aux analyseurs, car cela ne ferait qu’encombrer les captures de paquets.

   En outre, nous avons configuré une route statique sur l’appareil d’analyse afin qu’il puisse répondre aux pings pour faciliter les tests de diagnostic. À proprement parler, seule la connectivité ou le routage simplex est nécessaire entre les dispositifs de forage et l’analyseur pour que la mise en miroir des ports distants fonctionne.

3. Configurez l’instance d’échantillonnage. Nous utilisons un taux de 1 pour sélectionner et échantillonner tous les paquets correspondants. Par défaut, le est run-length 1. C’est bien étant donné que tout le trafic correspondant est échantillonné avec un taux de 1. Vous devez spécifier l’interface logique sur le routeur fti qui est utilisée pour envoyer le trafic miroir. Vous avez configuré l’unité 1 pour l’interface fti à l’étape précédente afin que la même unité soit spécifiée comme interface de sortie pour l’instance miroir.

4. Définissez les filtres de pare-feu pour refléter le trafic envoyé entre les routeurs CE.

   Les filtres familiaux any n’autorisent que les types de correspondance de couche 2. Par exemple, ID de VLAN, interface, adresse MAC ou étiquette MPLS. Par conséquent, vous ne pouvez pas utiliser IPv4 ou des conditions de correspondance spécifiques à IPv4.

   Deux filtres sont définis, un pour chaque sens de circulation entre les CE.

   Étant donné notre objectif de mettre en miroir le trafic VPN sur un routeur P, les filtres sont écrits pour correspondre sur les étiquettes spécifiques qui identifient les flux de trafic MPLS entre les deux routeurs PE.

   Pour la direction CE1 à CE2, le filtre correspond à l’étiquette de transport RSVP utilisée par PE1 pour atteindre PE2. En raison de PHP et de l’application de sortie, le filtre utilisé dans le sens CE2 à CE1 correspond à l’étiquette VRF annoncée par PE1 à PE2. Le trafic correspondant évoque l’action de mise en miroir des ports sur les instances de mise en miroir définies précédemment. Les filtres comprennent une fonction de comptage pour aider à confirmer le bon fonctionnement.

   Nous avons déterminé les étiquettes correctes à l’aide de ces commandes :

   1. Pour le trafic envoyé par CE1 à CE2, l’étiquette de transport RSVP actuelle s’affiche avec une show rsvp session ingress detail commande. Il s’agit de l’étiquette RSVP attribuée par PE1 pour atteindre PE2 en utilisant MPLS. Il convient de noter que tout le trafic VPN envoyé entre cette paire PE utilise le même transport RSVP. Le filtre résultant n’est pas spécifique au VRF CE1 sur le routeur PE.

      Dans ce cas, la sortie indique que l’étiquette RSVP 22 est affectée au routeur PE1/R2 pour atteindre la sortie LSP au niveau du routeur PE2/R4.

   2. Pour le trafic envoyé par CE2 à CE1, vous devez correspondre sur l’étiquette VRF. En effet, le routeur P est l’avant-dernier nœud de saut et sur l’interface de sortie, il aura fait apparaître l’étiquette de transport RSVP. Cela laisse sur l’étiquette VRF en bas de la pile. Vous confirmez l’étiquette VRF annoncée par PE1 au PE2 à l’aide d’une show route advertising-protocol bgp remote-peer-address detail commande. Cette commande affiche les routes annoncées par le PE local ainsi que l’étiquette VRF liée à l’instance de routage.

      La sortie montre que PE1 a signalé l’étiquette VRF 16 au routeur PE2 pour les routes associées à l’instance de routage CE1.

      À l’aide des informations des commandes précédentes, nous savons quelles étiquettes RSVP/VRF rechercher dans le filtre du pare-feu.

      Les filtres se terminent par un terme d’acceptation correspond à tous pour remplacer le terme de refus tout par défaut à la fin d’un filtre Junos. De cette façon, le trafic qui n’est pas mis en correspondance dans le premier terme est accepté. Ceci est essentiel pour éviter d’interrompre tout autre trafic à l’aide de cette interface !

      Remarque :

      Les étiquettes RSVP peuvent changer en raison d’une nouvelle signalisation LSP causée par des pannes de liaison ou d’autres changements de configuration. Nous montrons comment utiliser un filtre pour faire correspondre des étiquettes spécifiques afin de limiter le trafic mis en miroir. Vous pouvez toujours appliquer un filtre Correspondance de tout pour vous assurer que les modifications d’étiquette MPLS n’affectent pas la mise en miroir. L’inconvénient de l’approche « match all » est que vous mettrez en miroir tout le trafic reçu sur l’interface du routeur P pour inclure les protocoles de base et le trafic non VPN.

5. Appliquez les filtres à l’interface PE1 du routeur P/R3. La directionnalité de l’application du filtre est importante. Nos filtres sont conçus pour fonctionner dans le sens d’entrée pour le trafic CE1 à CE2, et dans le sens de sortie pour le trafic CE2 à CE1. Comme il s’agit de filtres de famille, ils sont appliqués au niveau de l’unité indépendamment d’IPv4 ou d’IPv6. Famille Tous les filtres fonctionnent au niveau de la couche 2, qui est indépendante de toute famille de protocoles.

Par souci d’exhaustivité, nous montrons la configuration de R2/PE1 sous forme d’accolades.

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 (CE1)
• R2 (PE1) DUT1
• R3 (routeur P) DUT 2
• R4 (PE2)
• R5 (CE2)

Cette section répertorie les mises en garde et les limitations de la mise en miroir de ports distants sur les plates-formes PTX.

1. Si la partie de sortie de la configuration de l’instance de mise en miroir des ports doit être modifiée, la configuration de sortie existante doit d’abord être supprimée et la modification validée, avant d’ajouter la nouvelle configuration.

2. Au total, 15 instances de miroir sont prises en charge. Il n’y a pas d’erreur de commit si le nombre d’instances de miroir de port distant dépasse 15.

3. Un paquet en miroir donné ne peut être envoyé qu’à un seul analyseur distant.

4. La longueur maximale des paquets peut être configurée en multiple de 128 octets. Le paquet exporté sera inférieur de 22 octets à la valeur configurée.

5. Plusieurs interfaces de sortie ne sont pas prises en charge dans une instance de mise en miroir donnée. Il n’y a pas d’erreur de commit si plusieurs interfaces de sortie sont configurées.

6. Le processus d’échantillonnage n’est pas pris en charge par GRES. Il y aura des pertes de trafic en miroir en cas d’événement GRES ou de redémarrage du mirrord processus.

7. Le trafic de tunnel qui arrive sur le routeur local ne peut pas être mis en miroir dans le sens de sortie.

8. Vous ne pouvez pas utiliser la mise en miroir des ports avec un filtre qui évoque une action de contrôle dans le sens de sortie.

9. Les statistiques relatives aux paquets mis en miroir doivent être vérifiées à l’aide de compteurs de pare-feu ou de statistiques d’interface FTI.