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

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

Cet exemple utilise le contexte d’un VPN L3 basé sur MPLS pour illustrer la fonctionnalité de mise en miroir des ports distants sur les routeurs PTX. Le VPN L3 est configuré pour prendre en charge le trafic IPv4 et IPv6 entre les routeurs CE (Customer Edge) et PE (Provider Edge).

Figure 1 : mise en miroir de 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 match-all 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 fournisseur (P).

Le routeur PE1 (R2) et le routeur P (R3) sont les routeurs sur lesquels la mise en miroir de 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 certains trafics. Une combinaison de filtres d’entrée et de sortie est utilisée pour mettre en miroir le trafic de requête et de réponse circulant entre les routeurs CE (R1 et R5).

La mise en miroir de ports distants utilise un tunnel pour l’encapsulation GRE afin d’envoyer le trafic en miroir à un périphérique d’analyse distant. Notre topologie comporte deux analyseurs. L’un est connecté 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 central P. 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 tunnelisation. Dans le cas des miroirs de ports distants, les tunnels GRE sont configurés sur des interfaces fti pour transporter le trafic en miroir vers un périphérique d’analyse distant. Dans le cadre de 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 l’interface de ligne de commande, 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 des configurations complètes pour tous les routeurs dans l’annexe. L’étape 1 résume la base de référence de l’exemple. Cette base se compose d’une connectivité IPv4 et IPv6, d’un 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 ligne de base VPN L3 sur le routeur PE1. Il s’agit des éléments suivants :

   1. Numérotation des interfaces IPv4 et IPv6 et prise family mpls en charge des interfaces centrales.

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

   3. RSVP et MPLS étiquetez les chemins de commutation (LSP) pour 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 référence couverte, les étapes restantes se concentrent sur la configuration du routeur R2/PE1 pour qu’il mette en miroir tous les ports du trafic envoyé et reçu sur son interface VRF CE1.

2. Vous commencez par configurer le tunnel GRE. Sur un routeur PTX, le tunnel est mis en œuvre via 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 ping de diagnostic provenant de la source du tunnel GRE ou à destination de celle-ci. La destination GRE pour le trafic mis en miroir par PE1 est le routeur de l’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é IGP aux réseaux d’analyseurs.

   L’adresse de destination correspond à l’appareil Analyzer 1 connecté à l’interface et-0/0/2 sur le routeur P/R3. Vous devez configurer l’interface logique fti avec family ccc pour prendre en charge la mise en miroir des ports distants sur le PTX. Cela est dû au fait que l’action miroir se produit au niveau de la couche 2.

   Note:

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

   De plus, nous avons configuré une route statique sur l’analyseur pour lui permettre de répondre aux pings afin d’aider aux tests de diagnostic. Strictement parlant, seule la connectivité ou le routage simplex est nécessaire entre les DUT 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 de 1 est laissée en place étant donné que tout le trafic correspondant est déjà échantillonné. Vous devez spécifier l’interface logique sur le routeur fti qui est utilisé 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é soient spécifiées comme interface de sortie dans l’instance de miroir.
   Note:

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

4. Définissez deux familles de any filtres de pare-feu pour qu’ils correspondent au trafic CE et le mettent en miroir. Deux filtres sont définis, l’un pour la mise en miroir du trafic CE1 vers CE2 et l’autre pour la mise en miroir CE2 vers CE1. Les filtres incluent une fonction de comptage pour aider à la vérification. L’action de mise en miroir de port dirige le trafic correspondant vers l’instance de mise en miroir de port que vous avez configurée précédemment.

   Les filtres familiaux any prennent en charge la correspondance de couche 2 et de couche 3. Pour le premier, vous pouvez faire correspondre l’ID de VLAN, l’interface, l’adresse MAC ou l’étiquette MPLS. Pour ces derniers, vous pouvez faire correspondre sur des champs d’en-têtes IPv4 ou IPv6 standard.

   Compte tenu de notre topologie, nous utilisons un terme « match all » qui capture tout le trafic envoyé ou reçu par les CE. Cela inclut IPv4, IPv6, ARP, LLDP et tous les protocoles de routage tels que OSPF.

   Les deux filtres se terminent par un terme « correspondance all accept » qui remplace l’action « refuser tout » par défaut à la fin d’un filtre Junos. De cette façon, le trafic qui n’est pas apparié dans le premier terme est accepté. Ce terme est ajouté à titre de sauvegarde 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 via 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 contrôle dans la direction de la sortie.
   Note:

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

5. Appliquez les filtres sur l’interface 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 du filtre. Un filtre d’entrée et de sortie est nécessaire pour refléter les deux sens du flux de trafic CE.

Pour être complet, nous montrons la configuration de R2/PE1 au format accolade.

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

Cette section met en évidence les principales tâches de configuration nécessaires à la configuration du routeur P/R3 dans cet exemple. Commençons par la base de référence du VPN L3 basé sur MPLS. Ensuite, nous montrons les étapes nécessaires pour configurer la mise en miroir de 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 ligne de base MPLS sur le routeur P/R3. Cela implique plusieurs choses :

   1. Numérotation des interfaces IPv4 et IPv6 et prise family mpls 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, les définitions d’appairage BGP et VRF ne sont pas présentes.

      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 en tant qu’IPv4 à l’aide de l’encapsulation GRE. Les LSP ne s’étendent pas à l’analyseur.

      Note:

      La configuration de l’interface et-0/0/2 utilisée ici 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.

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

2. Commençons par la définition du tunnel GRE. Sur les plates-formes 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 ping de diagnostic provenant de la source du tunnel GRE ou à destination de celle-ci. La destination GRE pour le 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é IGP aux réseaux d’analyseurs.

   Vous devez configurer l’interface logique fti avec family ccc pour prendre en charge la mise en miroir des ports distants sur le PTX. Cela est dû au fait que l’action miroir se produit au niveau de la couche 2.

   Note:

   Une instance IGP passive est provisionnée pour les interfaces attachées aux périphériques de l’analyseur. Cela permet d’accéder aux ports de l’analyseur 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.

   De plus, nous avons configuré une route statique sur l’analyseur afin qu’il puisse répondre aux pings pour faciliter les tests de diagnostic. Strictement parlant, seule la connectivité ou le routage simplex est nécessaire entre les DUT 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, la run-length valeur est 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é pour envoyer le trafic miroir. Vous avez configuré l’unité 1 pour l’interface fti à l’étape précédente afin que cette même unité soit spécifiée comme interface de sortie pour l’instance de 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 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 flux de trafic entre les CE.

   Étant donné notre objectif de mise en miroir du trafic VPN au niveau d’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 sur 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 la direction CE2 vers CE1 correspond sur l’étiquette VRF annoncée par PE1 à PE2. Le trafic correspondant évoque l’action de mise en miroir de port aux 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 des commandes suivantes :

   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 attribuée RSVP utilisée par PE1 pour atteindre PE2 à l’aide de 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 attribué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 faire correspondre 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 le 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 sur quelles étiquettes RSVP/VRF faire correspondre dans le filtre du pare-feu.

      Les filtres se terminent par un terme « correspondance all accept » qui remplace le terme « tout » par défaut « tout » à la fin d’un filtre Junos. De cette façon, le trafic qui n’est pas apparié dans le premier terme est accepté. C’est essentiel pour éviter de perturber tout le reste du trafic utilisant cette interface !

      Note:

      Les étiquettes RSVP peuvent changer en raison de la resignalisation LSP causée par des interruptions de liaison ou d’autres changements de configuration. Nous montrons comment un filtre peut être utilisé pour faire correspondre des étiquettes spécifiques afin de contraindre le trafic mis en miroir. Vous pouvez toujours appliquer un filtre « Correspondance 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 centraux 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 vers CE2, et dans le sens de sortie pour le trafic CE2 vers CE1. Étant donné qu’il s’agit de filtres de la famille, ils sont appliqués au niveau de l’unité, indépendamment d’IPv4 ou d’IPv6. Tous les filtres fonctionnent au niveau du niveau 2, qui est indépendant de toute famille de protocoles.

Pour être complet, nous montrons la configuration de R2/PE1 au format accolade.

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 (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 que la nouvelle configuration ne soit ajoutée.

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

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

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

5. Les interfaces de sortie multiples 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 baisses de trafic en miroir en cas d’événement GRES ou de redémarrage du mirrord processus.

7. Le trafic du tunnel qui se termine sur le routeur local ne peut pas être mis en miroir dans le sens sortant.

8. Vous ne pouvez pas utiliser la mise en miroir de ports avec un filtre qui évoque une action du mécanisme de contrôle dans la direction de la 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.