Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP multi-protocole

Comprendre le BGP multiprotocole

Le BGP multiprotocole (MP-BGP) est une extension de BGP qui permet à BGP de transporter des informations de routage pour plusieurs couches réseau et familles d’adresses. MP-BGP peut transporter les routes unicast utilisées pour le routage multicast séparément des routes utilisées pour le transfert IP unicast.

Pour activer MP-BGP, vous configurez BGP pour qu’il transporte les informations d’accessibilité de la couche réseau (NLRI) pour les familles d’adresses autres que IPv4 unicast en incluant l’énoncé family inet :

Pour permettre à MP-BGP de transporter NLRI pour la famille d’adresses IPv6, incluez la family inet6 déclaration :

Sur les routeurs uniquement, pour permettre à MP-BGP de transporter le NLRI du réseau privé virtuel (VPN) de couche 3 pour la famille d’adresses IPv4, incluez la family inet-vpn déclaration :

Sur les routeurs uniquement, pour permettre à MP-BGP de transporter des NLRI VPN de couche 3 pour la famille d’adresses IPv6, incluez la family inet6-vpn déclaration :

Sur les routeurs uniquement, pour permettre à MP-BGP de transporter des NLRI VPN multicast pour la famille d’adresses IPv4 et d’activer la signalisation VPN, incluez la family inet-mvpn déclaration :

Pour permettre à MP-BGP de transporter des NLRI VPN multicast pour la famille d’adresses IPv6 et d’activer la signalisation VPN, incluez la family inet6-mvpn déclaration :

Pour plus d’informations sur les VPN multicast basés sur BGP multiprotocoles, consultez le Guide de l’utilisateur des protocoles multicast Junos OS.

Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure ces déclarations, consultez les sections de synthèse de ces déclarations.

REMARQUE :

Si vous modifiez la famille d’adresses spécifiée au niveau de la [edit protocols bgp family] hiérarchie, toutes les sessions BGP actuelles sur l’équipement de routage sont abandonnées, puis rétablies.

Dans junos OS version 9.6 et versions ultérieures, vous pouvez spécifier une valeur de boucle pour une famille d’adresses BGP spécifique.

Par défaut, les pairs BGP n’ont que des routes unicast utilisées à des fins de transfert unicast. Pour configurer des pairs BGP de manière à ne transporter que des routes multicast, spécifiez l’option multicast . Pour configurer les pairs BGP pour qu’ils transportent à la fois des routes unicast et multicast, spécifiez l’option any .

Lorsque MP-BGP est configuré, BGP installe les routes MP-BGP dans différentes tables de routage. Chaque table de routage est identifiée par la famille de protocoles ou l’indicateur de famille d’adresses (AFI) et un identifiant de famille d’adresses (SAFI) ultérieur.

La liste suivante présente toutes les combinaisons AFI et SAFI possibles :

  • AFI=1, SAFI=1, unicast IPv4

  • AFI=1, SAFI=2, multicast IPv4

  • AFI=1, SAFI=128, unicast IPv4 L3VPN

  • AFI=1, SAFI=129, multicast IPv4 L3VPN

  • AFI=2, SAFI=1, unicast IPv6

  • AFI=2, SAFI=2, multicast IPv6

  • AFI=25, SAFI=65, BGP-VPLS/BGP-L2VPN

  • AFI=2, SAFI=128, unicast IPv6 L3VPN

  • AFI=2, SAFI=129, multicast IPv6 L3VPN

  • AFI=1, SAFI=132, RT-Contrainte

  • AFI=1, SAFI=133, spécifications de flux

  • AFI=1, SAFI=134, spécifications de flux

  • AFI=3, SAFI=128, CLNS VPN

  • AFI=1, SAFI=5, NG-MVPN IPv4

  • AFI=2, SAFI=5, NG-MVPN IPv6

  • AFI=1, SAFI=66, MDT-SAFI

  • AFI=1, SAFI=4, étiqueté IPv4

  • AFI=2, SAFI=4, étiqueté IPv6 (6PE)

Les routes installées dans la table de routage inet.2 ne peuvent être exportées vers des pairs MP-BGP que parce qu’elles utilisent le SAFI et les identifient comme des routes vers des sources multicast. Les routes installées dans la table de routage inet.0 ne peuvent être exportées que vers des pairs BGP standard.

La table de routage inet.2 doit être un sous-ensemble des routes que vous avez dans inet.0, car il est peu probable que vous disposiez d’un routage vers une source multicast vers laquelle vous ne pourriez pas envoyer de trafic unicast. La table de routage inet.2 stocke les routes unicast utilisées pour les vérifications de transfert inverse de chemin multicast, ainsi que les informations d’accessibilité supplémentaires apprises par MP-BGP à partir des mises à jour multicast NLRI. Une table de routage inet.2 est automatiquement créée lorsque vous configurez MP-BGP (en définissant NLRI sur any).

Lorsque vous activez MP-BGP, vous pouvez effectuer les opérations suivantes :

Limitation du nombre de préfixes reçus sur une session peer BGP

Vous pouvez limiter le nombre de préfixes reçus sur une session peer BGP et consigner les messages à débit limité lorsque le nombre de préfixes injectés dépasse une limite définie. Vous pouvez également démolir l’appairage lorsque le nombre de préfixes dépasse la limite.

Pour configurer une limite au nombre de préfixes pouvant être reçus sur une session BGP, incluez l’instruction prefix-limit :

Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.

Pour maximum number, spécifiez une valeur dans la plage de 1 à 4 294 967 295. Lorsque le nombre maximal de préfixes spécifié est dépassé, un message de journal système est envoyé.

Si vous incluez l’instruction teardown , la session est détruite lorsque le nombre maximal de préfixes est dépassé. Si vous spécifiez un pourcentage, les messages sont enregistrés lorsque le nombre de préfixes dépasse ce pourcentage de la limite maximale spécifiée. Une fois la session détruite, elle est rétablie dans un court laps de temps (à moins que vous n’incluiez la idle-timeout déclaration). Si vous incluez l’instruction idle-timeout , la session peut être maintenue hors service pendant un certain temps, ou pour toujours. Si vous spécifiez forever, la session n’est rétablie qu’après l’émission d’une clear bgp neighbor commande. Si vous incluez l’instruction drop-excess <percentage> et spécifiez un pourcentage, les routes excédentaires sont supprimées lorsque le nombre de préfixes dépasse le pourcentage. Si vous incluez l’instruction hide-excess <percentage> et spécifiez un pourcentage, les routes excédentaires sont masquées lorsque le nombre de préfixes dépasse le pourcentage. Si le pourcentage est modifié, les routes sont automatiquement réévaluées.

REMARQUE :

Dans Junos OS version 9.2 et versions ultérieures, vous pouvez également configurer une limite au nombre de préfixes acceptés sur une session pair BGP. Pour plus d’informations, reportez-vous à la section Limitation du nombre de préfixes acceptés sur une session peer BGP.

Limitation du nombre de préfixes acceptés sur une session peer BGP

Dans junos OS version 9.2 et versions ultérieures, vous pouvez limiter le nombre de préfixes pouvant être acceptés sur une session pair BGP. Lorsque la limite spécifiée est dépassée, un message de journal système est envoyé. Vous pouvez également spécifier de réinitialiser la session BGP si la limite du nombre de préfixes spécifiés est dépassée.

Pour configurer une limite au nombre de préfixes pouvant être acceptés sur une session pair BGP, incluez l’instruction accepted-prefix-limit :

Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.

Pour maximum number, spécifiez une valeur dans la plage de 1 à 4 294 967 295.

Incluez l’instruction teardown permettant de réinitialiser la session peer BGP lorsque le nombre de préfixes acceptés dépasse la limite configurée. Vous pouvez également inclure une valeur en pourcentage de 1 à 100 pour envoyer un message de journal système lorsque le nombre de préfixes acceptés dépasse ce pourcentage de la limite maximale. Par défaut, une session BGP réinitialisée est rétablie dans un court laps de temps. Incluez l’instruction idle-timeout pour empêcher la session BGP d’être rétablie pour une période de temps spécifiée. Vous pouvez configurer une valeur de délai d’expiration de 1 à 2 400 minutes. Incluez l’option forever permettant d’empêcher le rétablissement de la session BGP tant que vous n’avez pas passé la clear bgp neighbor commande. Si vous incluez l’instruction drop-excess <percentage> et spécifiez un pourcentage, les routes excédentaires sont supprimées lorsque le nombre de préfixes dépasse le pourcentage. Si vous incluez l’instruction hide-excess <percentage> et spécifiez un pourcentage, les routes excédentaires sont masquées lorsque le nombre de préfixes dépasse le pourcentage. Si le pourcentage est modifié, les routes sont automatiquement réévaluées.

REMARQUE :

Lorsque le routage actif sans interruption (NSR) est activé et qu’un basculement vers un moteur de routage de secours se produit, les pairs BGP qui sont en panne sont automatiquement redémarrés. Les pairs sont redémarrés même si l’instruction idle-timeout forever est configurée.

REMARQUE :

Vous pouvez également configurer une limite au nombre de préfixes pouvant être reçus (par opposition à acceptés) sur une session pair BGP. Pour plus d’informations, reportez-vous à la section Limitation du nombre de préfixes reçus sur une session peer BGP.

Configuration des groupes de tables de routage BGP

Lorsqu’une session BGP reçoit un NLRI unicast ou multicast, elle installe le routage dans la table appropriée (inet.0ou inet6.0 pour l’unicast, ou inet6.2inet.2 pour le multicast). Pour ajouter des préfixes unicast aux tables unicast et multicast, vous pouvez configurer des groupes de tables de routage BGP. Ceci est utile si vous ne pouvez pas effectuer de négociation NLRI multicast.

Pour configurer des groupes de tables de routage BGP, incluez l’énoncé rib-group :

Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.

Résolution de routes vers des équipements de routage PE situés dans d’autres ass

Vous pouvez autoriser les routes étiquetées à être placées dans la table de routage pour la résolution des inet.3 routes. Ces routes sont ensuite résolues pour les connexions d’équipements de routage de périphérie de fournisseur (PE) où le PE distant est situé sur un autre système autonome (AS). Pour qu’un équipement de routage PE installe un routage dans l’instance de routage et de transfert VPN (VRF), le saut suivant doit être résolu vers un routage stocké dans la inet.3 table.

Pour résoudre les routes dans la inet.3 table de routage, incluez l’instruction resolve-vpn :

Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.

Autoriser les routes étiquetées et non étiquetées

Vous pouvez autoriser l’échange de routes étiquetées et non étiquetées en une seule session. Les routes étiquetées sont placées dans la table de routage inet.3 ou inet6.3, et les routes unicast étiquetées et non étiquetées peuvent être envoyées ou reçues par l’équipement de routage.

Pour permettre l’échange de routes étiquetées et non étiquetées, incluez l’énoncé rib :

Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.

Exemple : Configuration des routes BGP IPv6 sur le transport IPv4

Cet exemple montre comment exporter les préfixes IPv6 et IPv4 sur une connexion IPv4 où les deux côtés sont configurés avec une interface IPv4.

Conditions préalables

Aucune configuration spéciale au-delà de l’initialisation de l’équipement n’est requise avant de configurer cet exemple.

Présentation

Gardez à l’esprit les éléments suivants lors de l’exportation des préfixes BGP IPv6 :

  • BGP tire des préfixes de saut suivant à l’aide du préfixe IPv4 mappé IPv6. Par exemple, le préfixe IPv4 se traduit par le préfixe 10.19.1.1 de saut suivant IPv6 ::ffff:10.19.1.1.

    REMARQUE :

    Il doit y avoir une route active vers le saut suivant IPv6 mappé IPv4 pour exporter les préfixes BGP IPv6.

  • Une connexion IPv6 doit être configurée sur la liaison. La connexion doit être soit un tunnel IPv6, soit une configuration double pile. Le double empilage est utilisé dans cet exemple.

  • Lors de la configuration des préfixes IPv6 mappés IPv4, utilisez un masque de plus de 96 bits.

  • Configurez un routage statique si vous souhaitez utiliser des préfixes IPv6 normaux. Cet exemple utilise des routes statiques.

Figure 1 affiche la topologie de l’exemple.

Figure 1 : Topologie pour la configuration des routes BGP IPv6 sur le transport IPv4Topologie pour la configuration des routes BGP IPv6 sur le transport IPv4

Configuration

Configuration rapide cli

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, puis copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie.

Équipement R1

Équipement R2

Équipement R3

Configuration de l’équipement R1

Procédure étape par étape

Dans l’exemple suivant, vous devez parcourir différents niveaux de la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.

Pour configurer l’équipement R1 :

  1. Configurez les interfaces, y compris une adresse IPv4 et une adresse IPv6.

  2. Configurez EBGP.

  3. Activez BGP pour transporter des routes unicast IPv4 et IPv6.

    Les routes unicast IPv4 sont activées par défaut. Toutefois, lorsque vous configurez d’autres familles d’adresses NLRI, l’unicast IPv4 doit être explicitement configuré.

  4. Configurez la stratégie de routage.

  5. Configurez des routes statiques.

  6. Configurez le numéro du système autonome (AS).

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant le show interfaces, show policy-options, show protocolset les show routing-options commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration. Répétez la configuration sur les équipements R2 et R3, en modifiant les noms d’interface et les adresses IP, selon les besoins.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification de l’état du voisin

But

Assurez-vous que BGP est activé pour transporter des routes unicast IPv6.

Action

Depuis le mode opérationnel, saisissez la show bgp neighbor commande.

Sens

Les différentes occurrences de inet6-unicast la sortie montrent que BGP est activé pour transporter des routes unicast IPv6.

Vérification de la table de routage

But

Assurez-vous que l’équipement R2 dispose de routes BGP dans sa table de routage inet6.0.

Action

Depuis le mode opérationnel, saisissez la show route protocol bgp inet6.0 commande.

Présentation des routes IPv4 publicitaires sur les sessions IPv6 BGP

Dans un réseau IPv6, BGP annonce généralement les informations d’accessibilité de la couche réseau IPv6 sur une session IPv6 entre pairs BGP. Dans les versions précédentes, Junos OS ne supportait que l’échange de familles d’adresses unicast inet6, multicast inet6 ou inet6 labeled-unicast uniquement. Cette fonctionnalité permet d’échanger toutes les familles d’adresses BGP. Dans un environnement double pile avec IPv6 en son cœur. cette fonctionnalité permet à BGP de promouvoir l’accessibilité unicast IPv4 avec le saut suivant IPv4 sur une session BGP IPv6.

Cette fonctionnalité est uniquement pour les sessions IPv6 BGP, où IPv4 est configuré sur les deux points de terminaison. Il local-ipv4-address peut s’agir d’une adresse de bouclage ou d’une adresse ipv4 pour une session IBGP ou EBGP à sauts multiples. Pour les haut-parleurs BGP externes à saut unique qui ne font pas partie des confédérations BGP, si l’adresse IPv4 locale configurée n’est pas directement connectée, la session BGP est fermée et reste inactive et une erreur est générée, qui s’affiche dans la sortie de la show bgp neighbor commande.

Pour activer la publicité de routage IPv4 sur une session IPv6, configurez local-ipv4-address comme suit :

REMARQUE :

Vous ne pouvez pas configurer cette fonctionnalité pour les familles d’adresses unicast inet6, multicast inet6 ou inet6 labeled-unicast, car BGP est déjà en mesure d’annoncer ces familles d’adresses sur une session BGP IPv6.

La configuration local-ipv4-address est utilisée uniquement lorsque BGP annonce des routes avec un saut automatique. Lorsque IBGP annonce des routes apprises auprès de pairs EBGP ou que le réflecteur de route annonce des routes BGP à ses clients, BGP ne modifie pas le saut suivant de route, ignore la configuration local-ipv4-addresset utilise le saut suivant IPv4 d’origine.

Exemple : Routes IPv4 publicitaires sur les sessions BGP IPv6

Cet exemple montre comment annoncer des routes IPv4 sur une session BGP IPv6. Dans un environnement double pile avec IPv6 en son cœur, il est nécessaire d’atteindre les hôtes IPv4 distants. Par conséquent, BGP annonce les routes IPv4 avec les sauts suivants IPv4 aux pairs BGP sur les sessions BGP à l’aide d’adresses source et de destination IPv6. Cette fonctionnalité permet à BGP de promouvoir l’accessibilité unicast IPv4 avec le saut suivant IPv4 sur les sessions BGP IPv6.

Conditions préalables

Cet exemple utilise les composants matériels et logiciels suivants :

  • Trois routeurs avec double capacité d’empilage

  • Junos OS Version 16.1 ou ultérieure s’exécutant sur tous les équipements

Avant d’activer les publicités IPv4 sur les sessions BGP IPv6, assurez-vous de :

  1. Configurez les interfaces de l’équipement.

  2. Configurez l’empilement double sur tous les équipements.

Présentation

À partir de la version 16.1, Junos OS permet à BGP de promouvoir l’accessibilité unicast IPv4 avec le saut suivant IPv4 sur une session BGP IPv6. Dans les versions précédentes de Junos OS, BGP ne pouvait faire la publicité que des familles d’adresses unicast inet6, inet6 multicast et inet6 étiquetées unicast sur des sessions BGP IPv6. Cette fonctionnalité permet à BGP d’échanger toutes les familles d’adresses BGP sur une session IPv6. Vous pouvez activer BGP pour annoncer les routes IPv4 avec les sauts suivants IPv4 auprès de pairs BGP sur une session IPv6. La configuration local-ipv4-address est utilisée uniquement lorsque BGP annonce des routes avec un saut automatique.

REMARQUE :

Vous ne pouvez pas configurer cette fonctionnalité pour les familles d’adresses unicast inet6, multicast inet6 ou inet6 labeled-unicast, car BGP est déjà en mesure d’annoncer ces familles d’adresses sur une session BGP IPv6.

topologie

Dans Figure 2, une session BGP externe IPv6 s’exécute entre les routeurs R1 et R2. Une session IBGP IPv6 est établie entre le routeur R2 et le routeur R3. Les routes statiques IPv4 sont redistribuées au BGP sur R1. Pour redistribuer les routes IPv4 sur la session BGP IPv6, la nouvelle fonctionnalité doit être activée sur tous les routeurs au niveau de la [edit protocols bgp address family] hiérarchie.

Figure 2 : Routes IPv4 publicitaires sur les sessions BGP IPv6Routes IPv4 publicitaires sur les sessions BGP IPv6

Configuration

Configuration rapide cli

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à la configuration de votre réseau, copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie, puis entrez commit à partir du mode de configuration.

Routeur R1

Routeur R2

Routeur R3

Configuration du routeur R1

Procédure étape par étape

L’exemple suivant exige que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation sur l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le guide de l’utilisateur CLI.

Pour configurer le routeur R1 :

REMARQUE :

Répétez cette procédure pour les autres routeurs après avoir modifié les noms d’interface, adresses et autres paramètres appropriés.

  1. Configurez les interfaces avec des adresses IPv4 et IPv6.

  2. Configurez l’adresse de bouclage.

  3. Configurez un routage statique IPv4 qui doit être annoncé.

  4. Configurez le système autonome pour les hôtes BGP.

  5. Configurez EBGP sur les routeurs de périphérie externes.

  6. Activez la fonctionnalité pour faire la publicité de l’adddress IPv4 140.1.1.1 sur les sessions IPv6 BGP.

  7. Définissez une stratégie p1 pour accepter toutes les routes statiques.

  8. Appliquez la stratégie p1 sur le groupe EBGP ebgp-v6.

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant le show interfaces, show protocols, show routing-optionset les show policy-options commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez fini de configurer l’équipement, validez la configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérifier que la session BGP est en cours

But

Vérifiez que BGP s’exécute sur les interfaces configurées et que la session BGP est active pour chaque adresse voisine.

Action

À partir du mode opérationnel, exécutez la commande sur le show bgp summary routeur R1.

Sens

La session BGP est opérationnelle et l’appairage BGP est établi.

Vérifier que l’adresse IPv4 est annoncée

But

Vérifiez que l’adresse IPv4 configurée est annoncée par le routeur R1 aux voisins BGP configurés.

Action

À partir du mode opérationnel, exécutez la commande sur le show route advertising-protocol bgp ::150.1.1.2 routeur R1.

Sens

Le routage statique IPv4 est annoncé au routeur voisin BGP R2.

Vérifier que le routeur voisin BGP R2 reçoit l’adresse IPv4 annoncée

But

Vérifiez que le routeur R2 reçoit l’adresse IPv4 que le routeur R1 annonce au voisin BGP sur IPv6.

Action
Sens

La présence du routage IPv4 statique dans la table de routage du routeur R2 indique qu’il reçoit les routes IPv4 annoncées du routeur R1.

Comprendre la redistribution des routes IPv4 avec le saut suivant IPv6 dans BGP

Dans un réseau qui transporte principalement le trafic IPv6, il est nécessaire de router des routes IPv4 si nécessaire. Par exemple, un fournisseur d’accès Internet qui dispose d’un réseau IPv6 uniquement, mais dont les clients continuent de router le trafic IPv4. Dans ce cas, il est nécessaire de répondre aux besoins de ces clients et de transférer le trafic IPv4 sur un réseau IPv6. Comme décrit dans la RFC 5549, les informations publicitaires sur l’accessibilité de la couche réseau IPv4 avec un trafic IPv6 de saut IPv4 sont tunnelisées depuis les équipements des locaux clients (CPE) vers les passerelles IPv4-over-IPv6. Ces passerelles sont annoncées aux équipements CPE via des adresses anycast. Les équipements de passerelle créent ensuite des tunnels IPv4 sur IPv6 dynamiques vers les équipements CPE distants et annoncent des routes agrégées IPv4 pour orienter le trafic.

REMARQUE :

La fonctionnalité de tunnel IPv4 sur IPv6 dynamique ne prend pas en charge la norme ISSU unifiée dans la version 17.3R1 de Junos OS.

Les réflecteurs de route (RR) dotés d’une interface programmable sont connectés via IBGP aux routeurs de passerelle et aux routes hôtes avec l’adresse IPv6 comme saut suivant. Ces RR annoncent les adresses IPv4/32 pour injecter des informations sur le tunnel dans le réseau. Les routeurs de passerelle créent des tunnels IPv4 sur IPv6 dynamiques vers la périphérie du fournisseur distant. Le routeur de passerelle annonce également les routes agrégées IPv4 pour orienter le trafic. Le RR annonce ensuite les routes source des tunnels au FAI. Lorsque le RR retire la route du tunnel, BGP retire également la route, ce qui entraîne le démontage du tunnel et le CPE inaccessible. Le routeur de passerelle retire également les routes d’agrégation IPv4 et les routes source de tunnel IPv6 lorsque toutes les routes agrégées sont supprimées. Le routeur de passerelle envoie un retrait de route lorsque la carte d’interface du moteur de transfert de paquets d’ancrage tombe en panne, de sorte qu’il redirige le trafic vers d’autres routeurs de passerelle.

Les extensions suivantes sont introduites pour prendre en charge les routes IPv4 avec un saut suivant IPv6 :

Codage du saut suivant BGP

BGP est étendu avec la fonctionnalité d’encodage du saut suivant qui est utilisée pour envoyer des routes IPv4 avec les sauts suivants IPv6. Si cette fonctionnalité n’est pas disponible sur l’homologue distant, BGP les regroupe en fonction de cette capacité d’encodage et supprime la famille BGP sans capacité d’encodage de la liste d’informations d’accessibilité de la couche réseau (NLRI) négociée. Junos OS n’autorise qu’une seule table de résolution telle que inet.0. Pour autoriser les routes BGP IPv4 avec les sauts suivants IPv6, BGP crée un nouvel arbre de résolution. Cette fonctionnalité permet à une table de routage Junos OS d’avoir plusieurs arbres de résolution.

Outre la RFC 5549, des informations d’accessibilité de la couche réseau IPv4 publicitaires avec un saut suivant IPv6 , une nouvelle communauté d’encapsulation spécifiée dans la RFC 5512, l’identifiant saFI (Next Address Family Identifier) BGP et l’attribut d’encapsulation du tunnel BGP est introduite pour déterminer la famille d’adresses de l’adresse du saut suivant. La communauté d’encapsulation indique le type de tunnels que le nœud d’entrée doit créer. Lorsque BGP reçoit des routes IPv4 avec l’adresse de saut suivant IPv6 et la communauté d’encapsulation V4oV6, alors BGP crée des tunnels dynamiques IPv4-over-IPv6. Lorsque BGP reçoit des routes sans la communauté d’encapsulation, les routes BGP sont résolues sans créer le tunnel V4oV6.

Une nouvelle action dynamic-tunnel-attributes dyan-attribute de stratégie est disponible au niveau de la [edit policy-statement policy name term then] hiérarchie pour prendre en charge la nouvelle encapsulation étendue.

Localisation de tunnel

L’infrastructure de tunnel dynamique est améliorée grâce à la localisation des tunnels pour prendre en charge un plus grand nombre de tunnels. La localisation des tunnels est nécessaire pour assurer la résilience nécessaire pour gérer le trafic en cas de défaillance de l’ancre. Un ou plusieurs châssis se sauvegardent les uns les autres et permettent au processus de protocole de routage (rpd) d’éloigner le trafic du point de défaillance vers le châssis de secours. Le châssis annonce uniquement ces préfixes agrégés au lieu des adresses de bouclage individuelles dans le réseau.

Gestion des tunnels

Les tunnels IPv4 sur IPv6 utilisent l’infrastructure de tunnel dynamique et l’ancrage de tunnel pour prendre en charge le châssis requis à grande échelle. L’état du tunnel est localisé dans un moteur de transfert de paquets et les autres moteurs de transfert de paquets orientent le trafic vers l’ancre du tunnel.

Entrée de tunnel

L’entrée de tunnel ou l’encapsulation de tunnel transfère le trafic réseau vers le site du client. Lorsque l’état du tunnel est présent sur le moteur de transfert de paquets sur lequel le trafic est entré dans le châssis, le processus de protocole de routage (rpd) utilise la procédure suivante pour redistribuer les routes IPv4 sur les tunnels IPv6 :
Figure 3 : Gestion de l’entrée de tunnel lorsque l’état du tunnel est disponible sur le même PFEGestion de l’entrée de tunnel lorsque l’état du tunnel est disponible sur le même PFE
Figure 4 : Gestion de l’entrée de tunnel lorsque l’état du tunnel est sur un PFE différentGestion de l’entrée de tunnel lorsque l’état du tunnel est sur un PFE différent
  1. Encapsule le trafic IPv4 dans l’en-tête IPv6.

    L’application maximale des unités de transmission (MTU) est effectuée avant l’encapsulation. Si la taille du paquet encapsulé dépasse le MTU du tunnel et que le paquet IPv4 n’est DF-bit pas défini, alors le paquet est fragmenté et ces fragments sont encapsulés.

  2. Utilise l’équilibrage de charge du trafic basé sur le hachage sur les en-têtes de paquets internes.

  3. Transfère le trafic à l’adresse IPv6 de destination. L’adresse IPv6 est tirée de l’en-tête IPv6.

Sortie de tunnel

Les tunnels sortants transfèrent le trafic de l’équipement des locaux du client vers le côté réseau.
Figure 5 : Gestion des sorties de tunnel lorsque l’état du tunnel est disponible sur le même PFEGestion des sorties de tunnel lorsque l’état du tunnel est disponible sur le même PFE
Figure 6 : Gestion de la sortie de tunnel lorsque l’état du tunnel est disponible sur un PFE distantGestion de la sortie de tunnel lorsque l’état du tunnel est disponible sur un PFE distant
  1. Décapite le paquet IPv4 présent à l’intérieur du paquet IPv6.

  2. Effectue une vérification anti-usurpage pour s’assurer que la paire IPv6 et IPv4 correspond aux informations utilisées pour configurer le tunnel.

  3. Recherche l’adresse de destination IPv4 à partir de l’en-tête IPv4 du paquet décapité et transfère le paquet à l’adresse IPv4 spécifiée.

Gestion des défaillances du moteur d’équilibrage de charge des tunnels et de transfert de paquets d’ancrage

La défaillance du moteur de transfert de paquets doit être traitée rapidement pour éviter le filtrage de route null du trafic de tunnel ancré sur le moteur de transfert de paquets. La localisation de tunnel implique l’utilisation de publicités BGP pour réparer la défaillance dans le monde entier. Le trafic du tunnel est détourné du point de défaillance vers un autre châssis de secours contenant l’état du tunnel identique. Pour l’équilibrage de charge du trafic, le châssis est configuré pour annoncer différentes valeurs med (multiple exit discriminator) pour chacun des ensembles de préfixes, de sorte que seul le trafic d’un quart des tunnels passe par chaque châssis. Le trafic CPE est également géré de la même manière en configurant le même ensemble d’adresses anycast sur chaque châssis et en orientant seulement un quart du trafic vers chaque châssis.

Le moteur de transfert de paquets d’ancre est l’entité unique qui traite tous les tunnels. La sélection du moteur de transfert de paquets d’ancrage passe par un provisionnement statique et lié aux interfaces physiques du moteur de transfert de paquets. Lorsque l’un des moteurs de transfert de paquets tombe en panne, le démon marque tous les moteurs de transfert de paquets vers le bas sur la carte de ligne et communique ces informations au processus de protocole de routage du protocole de routage et à d’autres processus. Le processus de protocole de routage envoie des retraits BGP pour les préfixes qui sont ancrés sur le moteur de transfert de paquets défaillant et les adresses IPv6 attribuées au moteur de transfert de paquets en panne. Ces publicités redirigent le trafic vers d’autres châssis de secours. Lorsque le moteur de transfert de paquets défaillant est à nouveau opérationnel, le châssis marque le moteur de transfert de paquets comme up et met à jour le processus de protocole de routage. Le processus de protocole de routage déclenche des mises à jour BGP pour ses pairs que les tunnels ancrés au moteur de transfert de paquets spécifiques sont désormais disponibles pour le routage du trafic. La configuration d’un tunnel à grande échelle peut prendre quelques minutes. Par conséquent, le Ack mécanisme est intégré au système pour garantir une perte de trafic minimale tout en ramenant le trafic au châssis d’origine.

Statistiques de flux de bouclage de tunnel

L’infrastructure de tunnel dynamique utilise des flux de bouclage dans le moteur de transfert de paquets pour boucler le paquet après l’encapsulation. Étant donné que la bande passante de ce flux de bouclage est limitée, il est nécessaire de surveiller les performances des flux de bouclage de tunnel.

Pour surveiller les statistiques du flux de bouclage, utilisez la commande show pfe statistics traffic detail opérationnelle qui affiche les statistiques agrégées du flux de bouclage, y compris le taux de transfert, le taux de perte de paquets et le taux d’octets.

Configuration de BGP pour redistribuer des routes IPv4 avec des adresses de saut suivant IPv6

À partir de la version 17.3R1, les équipements Junos OS peuvent transférer le trafic IPv4 sur un réseau IPv6 uniquement, qui ne peut généralement pas transférer le trafic IPv4. Comme décrit dans la RFC 5549, le trafic IPv4 est tunnelisé des équipements CPE aux passerelles IPv4-over-IPv6. Ces passerelles sont annoncées aux équipements CPE via des adresses anycast. Les équipements de passerelle créent ensuite des tunnels IPv4 sur IPv6 dynamiques vers les équipements des clients distants et annoncent des routes agrégées IPv4 pour orienter le trafic. Les réflecteurs de route avec interfaces programmables injectent des informations sur le tunnel dans le réseau. Les réflecteurs de route sont connectés via IBGP aux routeurs de passerelle, qui annoncent les adresses IPv4 des routes hôtes avec des adresses IPv6 comme saut suivant.

REMARQUE :

La fonctionnalité de tunnel IPv4 sur IPv6 dynamique ne prend pas en charge la norme ISSU unifiée dans la version 17.3R1 de Junos OS.

Avant de commencer à configurer BGP pour distribuer des routes IPv4 avec des adresses de saut suivant IPv6, effectuez les opérations suivantes :

  1. Configurez les interfaces de l’équipement.

  2. Configurez OSPF ou tout autre protocole IGP.

  3. Configurez MPLS et LDP.

  4. Configurez BGP.

Pour configurer BGP pour distribuer des routes IPv4 avec des adresses de saut suivant IPv6 :

  1. Configurez l’option d’encodage de saut suivant étendue pour les groupes BGP avec des pairs IPv6 pour acheminer les familles d’adresses IPv4 sur une session IPv6.
  2. Configurez des tunnels IPv4 sur IPv6 dynamiques et définissez leurs attributs pour transférer le trafic IPv4 vers un réseau IPv6 uniquement. Le trafic IPv4 est tunnelisé des équipements CPE aux passerelles IPv4-over-IPv6.
  3. Configurez les attributs du tunnel.

    Par exemple, configurez un tunnel dynamique, first_tunnel avec les attributs suivants :

  4. Définissez une stratégie pour associer le profil d’attribut de tunnel dynamique configuré à une liste de préfixes ou à un filtre de routage.

    Par exemple, définissez dynamic_tunnel_policy une stratégie pour associer les attributs de tunnel first_tunnel dynamique uniquement au titre du trafic à une route spécifique 2.2.2.2/32.

  5. Exportez la stratégie définie.

    Par exemple, exportez la stratégie configurée dynamic_tunnel_policy .

Activation de la signalisation VPN de couche 2 et VPLS

Vous pouvez activer BGP pour transporter des messages VPN de couche 2 et VPLS NLRI.

Pour activer la signalisation VPN et VPLS, incluez la family déclaration :

Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.

Pour configurer un nombre maximal de préfixes, incluez l’instruction prefix-limit :

Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.

Lorsque vous définissez le nombre maximal de préfixes, un message est journalisé lorsque ce nombre est atteint. Si vous incluez l’instruction teardown , la session est détruite lorsque le nombre maximal de préfixes est atteint. Si vous spécifiez un pourcentage, les messages sont enregistrés lorsque le nombre de préfixes atteint ce pourcentage. Une fois la session détruite, elle est rétablie dans un court laps de temps. Incluez l’instruction idle-timeout permettant de maintenir la session en panne pendant un certain temps, ou pour toujours. Si vous spécifiez forever, la session n’est rétablie qu’après avoir utilisé la clear bgp neighbor commande. Si vous incluez l’instruction drop-excess <percentage> et spécifiez un pourcentage, les routes excédentaires sont supprimées lorsque le nombre de préfixes dépasse le pourcentage. Si vous incluez l’instruction hide-excess <percentage> et spécifiez un pourcentage, les routes excédentaires sont masquées lorsque le nombre de préfixes dépasse le pourcentage. Si le pourcentage est modifié, les routes sont automatiquement réévaluées.

Comprendre les routes de flux BGP pour le filtrage du trafic

Un routage de flux est une agrégation des conditions de correspondance pour les paquets IP. Les routes de flux sont installées en tant que filtres de table de transfert d’entrée (implicitement) et sont propagées à travers le réseau à l’aide de messages NLRI (Network-specification-layer reachability information) et installées dans la table instance-name.inetflow.0de routage de flux . Les paquets peuvent traverser des routes de flux uniquement si des conditions de correspondance spécifiques sont remplies.

Les routes de flux et les filtres de pare-feu sont similaires en ce qu’ils filtrent les paquets en fonction de leurs composants et effectuent une action sur les paquets correspondant. Les routes de flux fournissent des fonctionnalités de filtrage du trafic et de limitation de débit, comme les filtres de pare-feu. En outre, vous pouvez propager des routes de flux sur différents systèmes autonomes.

Les routes de flux sont propagées par BGP via des messages NLRI de spécification de flux. Vous devez activer BGP pour propager ces NLRIs.

À partir de la version 15.1 de Junos OS, les modifications sont mises en œuvre pour étendre la prise en charge du routage actif sans interruption (NSR) aux familles inet-flow et inetvpn-flow existantes, et étendre la validation du routage pour les flux BGP par draft-ietf-idr-bgp-flowspec-oid-01. Deux nouvelles déclarations sont introduites dans le cadre de cette amélioration. Découvrez l’application avant tout et la non-installation.

REMARQUE :

À partir de la version 16.1 de Junos OS, la prise en charge d’IPv6 est étendue à la spécification de flux BGP qui permet de propager les règles de spécification des flux de trafic pour les paquets IPv6 et VPN-IPv6. Les spécifications de flux BGP automatisent la coordination des règles de filtrage du trafic afin d’atténuer les attaques par déni de service distribué pendant le routage actif sans interruption (NSR).

À partir de la version 16.1R1 de Junos OS, la spécification de flux BGP prend en charge l’action de filtrage du trafic extended-community . Pour le trafic IPv4, Junos OS modifie les bits de point de code DiffServ (DSCP) d’un paquet IPv4 en transit à la valeur correspondante de la communauté étendue. Pour les paquets IPv6, Junos OS modifie les six premiers bits du traffic class champ du paquet IPv6 de transmission à la valeur correspondante de la communauté étendue.

À partir de la version 17.1R1 de Junos OS, BGP peut transporter des messages NLRI (Network Layer Reachability Information) sur les routeurs PTX Series équipés de SPC de troisième génération (FPC3-PTX-U2 et FPC3-PTX-U3 sur PTX5000 et FPC3-SFF-PTX-U0 et FPC3-SFF-PTX-U1 sur PTX3000). La propagation des informations des filtres de pare-feu dans le cadre de BGP vous permet de propager dynamiquement les filtres de pare-feu contre les attaques par déni de service (DOS) sur les systèmes autonomes.

À partir de la version 17.2R1 de Junos OS, BGP peut transporter des messages NLRI (Network Layer Reachability Information) de spécifications de flux sur les routeurs PTX1000 équipés de PFC de troisième génération. La propagation des informations des filtres de pare-feu dans le cadre de BGP vous permet de propager dynamiquement les filtres de pare-feu contre les attaques par déni de service (DOS) sur les systèmes autonomes.

À partir de la version 20.3R1 de cRPD, les routes de flux et les règles de contrôle propagées via la spécification de flux BGP NLRI sont téléchargées sur le noyau Linux via l’infrastructure Linux Netfilter sur les environnements cRPD.

Conditions de correspondance pour les routes de flux

Vous spécifiez les conditions auxquelles le paquet doit correspondre avant que l’action de l’instruction then ne soit prise pour un routage de flux. Toutes les conditions de l’instruction from doivent correspondre pour que l’action soit prise. L’ordre dans lequel vous spécifiez des conditions de correspondance n’est pas important, car un paquet doit correspondre à toutes les conditions d’un terme pour qu’une correspondance se produise.

Pour configurer une condition de correspondance, incluez l’instruction match au niveau de la [edit routing-options flow] hiérarchie.

Tableau 1 décrit les conditions de correspondance du routage de flux.

Tableau 1 : Conditions de correspondance du routage de flux

Condition de correspondance

Description

destination prefix prefix-offset number

Champ adresse de destination IP.

Vous pouvez utiliser le prefix-offset champ facultatif, disponible uniquement sur les équipements Junos avec des MPC améliorés configurés pour enhanced-ip le mode, pour spécifier le nombre de bits qui doivent être ignorés avant que Junos OS ne commence à correspondre à un préfixe IPv6.

destination-port number

Champ de port de destination TCP ou UDP (User Datagram Protocol). Vous ne pouvez pas spécifier les conditions et destination-port les port correspondre dans le même terme.

Au lieu de la valeur numérique, vous pouvez spécifier l’un des synonymes de texte suivants (les numéros de port sont également répertoriés) : afs(1483), bgp (179), biff (512), bootpc (68), (67), bootpscmd (514), cvspserver (2401), dhcp (67), domain (53), eklogin (2105), ekshell (2106), exec (512), finger (79), ftp (21), ftp-data (20), http (80), https (443), ident (113), imap (143), kerberos-sec (88), klogin (543), kpasswd (761), krb-prop (754), krbupdate (760), kshell (544), ldap (389), login (513), mobileip-agent (434), (435), msdpmobilip-mn (639), (138), netbios-nsnetbios-dgm (137), (139), netbios-ssn (2049), nntpnfsd (119), ntalk (518), ntp (123), pop3 (110), pptp (1723), printer (515), radacct (1813), radius (1812), rip (520), rkinit (2108), smtp (25), snmp (161), snmptrap (162), snpp (444), socks (108) ( ssh 22), sunrpc (111), (514), syslogtacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), xdmcp (177), zephyr-clt (2103) ou zephyr-hm (2104).

dscp number

Point de code de services différenciés (DSCP). Le protocole DiffServ utilise l’octet de type de service (ToS) dans l’en-tête IP. Les six bits les plus importants de cet octet forment le DSCP.

Vous pouvez spécifier le DSCP sous forme hexadécimale ou décimale.

flow-label numeric-expression

Correspondez à la valeur de l’étiquette de flux. La valeur de ce champ varie de 0 à 1048575.

Cette condition de correspondance n’est prise en charge que sur les équipements Junos avec des MPC améliorés configurés pour enhanced-ip le mode. Cette condition de correspondance n’est pas prise en charge pour IPv4.

fragment type

Champ de type de fragment. Les mots clés sont regroupés par type de fragment auquel ils sont associés :

  • dont-fragment

    REMARQUE :

    Cette option n’est pas prise en charge pour IPv6.

  • first-fragment

  • is-fragment

  • last-fragment

  • not-a-fragment

Cette condition de correspondance n’est prise en charge que sur les équipements Junos OS avec des MPC améliorés configurés pour enhanced-ip le mode. .

icmp-code numbericmp6-code icmp6-code-value;

Champ de code ICMP. Cette valeur ou mot-clé fournit des informations plus spécifiques que icmp-type. Étant donné que la signification de la valeur dépend de la valeur associée icmp-type , vous devez spécifier icmp-type avec icmp-code.

Au lieu de la valeur numérique, vous pouvez spécifier l’un des synonymes de texte suivants (les valeurs de champ sont également répertoriées). Les mots clés sont regroupés par type ICMP auquel ils sont associés :

  • problème de paramètres : ip-header-bad (0), required-option-missing (1)

  • Rediriger: redirect-for-host(1), redirect-for-network (0), redirect-for-tos-and-host (3), redirect-for-tos-and-net (2)

  • dépassement de temps : ttl-eq-zero-during-reassembly(1), ttl-eq-zero-during-transit (0)

  • Inaccessible: communication-prohibited-by-filtering(13), destination-host-prohibited (10), destination-host-unknown (7), destination-network-prohibited (9), destination-network-unknown (6), fragmentation-needed (4), host-precedence-violation (14), (14), host-unreachable (12 host-unreachable-for-TOS ), network-unreachable (0), network-unreachable-for-TOS (11), port-unreachable (3), precedence-cutoff-in-effect (15), protocol-unreachable (2), source-host-isolated (8), source-route-failed (5)

icmp-type number icmp6-type icmp6-type-value

Champ de type de paquet ICMP. Normalement, vous spécifiez cette correspondance conjointement avec l’instruction protocol de correspondance pour déterminer quel protocole est utilisé sur le port.

Au lieu de la valeur numérique, vous pouvez spécifier l’un des synonymes de texte suivants (les valeurs de champ sont également répertoriées) : echo-reply(0), echo-request (8), info-reply (16), info-request (15), mask-request (17), mask-reply (18), parameter-problem (12), redirect (5), router-advertisement (9), router-solicit (10), source-quench (4), time-exceeded (11), timestamp (13), timestamp-reply (14) ou unreachable (3).

packet-length number

Longueur totale du paquet IP.

port number

Champ source ou port de destination TCP ou UDP. Vous ne pouvez pas spécifier à la fois la port correspondance et la destination-port condition de source-port correspondance dans le même terme.

Au lieu de la valeur numérique, vous pouvez spécifier l’un des synonymes de texte répertoriés sous destination-port.

protocol number

Champ protocole IP. Au lieu de la valeur numérique, vous pouvez spécifier l’un des synonymes de texte suivants (les valeurs de champ sont également répertoriées) : ah, egp(8), esp (50), gre (47), icmp (1), igmp (2), ipip (4 ipv6 ), (41), ospf (89), pim (103), rsvp (46), tcp (6) ou udp (17).

Cette condition de correspondance est prise en charge pour IPv6 uniquement sur les équipements Junos avec des MPC améliorés configurés pour enhanced-ip le mode.

source prefixprefix-offset number

Champ adresse source IP.

Vous pouvez utiliser le prefix-offset champ facultatif, disponible uniquement sur les équipements Junos avec des MPC améliorés configurés pour enhanced-ip le mode, pour spécifier le nombre de bits qui doivent être ignorés avant que Junos OS ne commence à correspondre à un préfixe IPv6.

source-port number

Champ de port source TCP ou UDP. Vous ne pouvez pas spécifier les port conditions et source-port les assortir dans le même terme.

Au lieu du champ numérique, vous pouvez spécifier l’un des synonymes de texte répertoriés sous destination-port.

tcp-flag type

Format d’en-tête TCP.

Actions pour les routes de flux

Vous pouvez spécifier l’action à entreprendre si le paquet correspond aux conditions que vous avez configurées dans le routage de flux. Pour configurer une action, incluez l’instruction then au niveau de la [edit routing-options flow] hiérarchie.

Tableau 2 décrit les actions de routage de flux.

Tableau 2 : Modificateurs d’action de routage de flux

Action ou modificateur d’action

Description

Actions

accept

Accepter un paquet. C’est la valeur par défaut.

discard

Jeter un paquet en silence, sans envoyer de message ICMP (Internet Control Message Protocol).

community

Remplacez les communautés de la route par les communautés spécifiées.

Marque value

Définissez une valeur DSCP pour le trafic qui correspond à ce flux. Spécifiez une valeur de 0 à 63. Cette action est prise en charge uniquement sur les équipements Junos avec des MPC améliorés configurés pour enhanced-ip le mode.

next term

Passez à la condition de correspondance suivante pour l’évaluation.

routing-instance extended-community

Spécifiez une instance de routage vers laquelle les paquets sont transférés.

rate-limit bits-per-second

Limitez la bande passante sur le routage de flux. Exprimez la limite en bits par seconde (bps). À partir de la version 16.1R4 de Junos OS, la plage de débit-limite est de [0 à 1000000000000000].

sample

Échantillonner le trafic sur le routage de flux.

Validation des routes de flux

Junos OS installe des routes de flux dans la table de routage de flux uniquement si elles ont été validées à l’aide de la procédure de validation. Le moteur de routage effectue la validation avant d’installer des routes dans la table de routage de flux.

Les routes de flux reçues à l’aide des messages NLRI (Network Layer Reachability Information) BGP sont validées avant leur installation dans la table instance.inetflow.0de routage des instances primaires de flux . La procédure de validation est décrite dans le draft-ietf-idr-flow-spec-09.txt, Diffusion des règles de spécification de flux. Vous pouvez contourner le processus de validation des routes de flux à l’aide de messages BGP NLRI et utiliser votre propre stratégie d’importation spécifique.

Pour suivre les opérations de validation, incluez l’instruction validation au niveau de la [edit routing-options flow] hiérarchie.

Prise en charge de l’algorithme de spécification de flux BGP version 7 et versions ultérieures

Par défaut, Junos OS utilise l’algorithme de classement défini dans la version 6 du projet de spécification de flux BGP. Dans junos OS version 10.0 et versions ultérieures, vous pouvez configurer le routeur pour qu’il se conforme à l’algorithme de commande de termes défini pour la première fois dans la version 7 de la spécification de flux BGP et pris en charge par le biais de la RFC 5575, Dissemination of Flow Specification Routes.

bonnes pratiques :

Nous vous recommandons de configurer Junos OS pour qu’il utilise l’algorithme de classement des termes défini pour la première fois dans la version 7 du projet de spécification de flux BGP. Nous vous recommandons également de configurer Junos OS pour qu’il utilise le même algorithme de commande de termes sur toutes les instances de routage configurées sur un routeur.

Pour configurer BGP de manière à utiliser l’algorithme de spécification de flux défini pour la première fois dans la version 7 du projet Internet, incluez l’instruction standard au niveau de la [edit routing-options flow term-order] hiérarchie.

Pour revenir à l’algorithme de classement des termes défini dans la version 6, incluez l’instruction legacy au niveau de la [edit routing-options flow term-order] hiérarchie.

REMARQUE :

L’ordre des termes configuré n’a qu’une signification locale. Autrement dit, l’ordre des termes ne se propage pas avec les routes de flux envoyées aux pairs BGP distants, dont l’ordre de termes est entièrement déterminé par leur propre configuration d’ordre de termes. Par conséquent, vous devez être prudent lors de la configuration de l’action next term dépendante de l’ordre lorsque vous n’avez pas connaissance du terme configuration d’ordre des pairs distants. Le local next term peut être différent de celui next term configuré sur l’homologue distant.

REMARQUE :

Sur Junos OS Evolved, next term ne peut pas apparaître comme le dernier terme de l’action. Un terme de filtre où next term est spécifié en tant qu’action mais sans aucune condition de correspondance configurée n’est pas pris en charge.

À partir de la version 16.1 de Junos OS, vous pouvez ne pas appliquer le flowspec filtre au trafic reçu sur des interfaces spécifiques. Un nouveau terme est ajouté au début du flowspec filtre qui accepte tout paquet reçu sur ces interfaces spécifiques. Le nouveau terme est une variable qui crée une liste d’exclusion des termes joints au filtre de table de transfert dans le cadre du filtre de spécification de flux.

Pour exclure l’application du flowspec filtre au trafic reçu sur des interfaces spécifiques, vous devez d’abord configurer a group-id sur ces interfaces en incluant l’instruction de groupe group-id de filtres de la famille inet au niveau de la [edit interfaces] hiérarchie, puis joindre le flowspec filtre au groupe d’interfaces en incluant l’instruction flow interface-group group-id exclude au niveau de la [edit routing-options] hiérarchie. Vous ne pouvez configurer qu’une group-id seule instance de routage avec l’instruction set routing-options flow interface-group group-id .

Exemple : Permettre à BGP de transporter des routes de spécification de flux

Cet exemple montre comment permettre à BGP de porter des messages nlRI (Network Reachability Information) de spécifications de flux.

Conditions préalables

Avant de commencer :

  • Configurez les interfaces de l’équipement.

  • Configurez un protocole IGP (Interior Gateway Protocol).

  • Configurez BGP.

  • Configurez une stratégie de routage qui exporte des routes (telles que des routes directes ou des routes IGP) de la table de routage vers BGP.

Présentation

La propagation des informations des filtres de pare-feu dans le cadre de BGP vous permet de propager dynamiquement les filtres de pare-feu contre les attaques par déni de service (DOS) sur les systèmes autonomes. Les routes de flux sont encapsulées dans la spécification de flux NLRI et propagées via un réseau ou des réseaux privés virtuels (VPN), partageant des informations de type filtre. Les routes de flux sont une agrégation des conditions de correspondance et des actions qui en résultent pour les paquets. Ils vous fournissent un filtrage du trafic et des capacités de limitation de débit, comme les filtres de pare-feu. Les routes de flux unicast sont prises en charge pour l’instance par défaut, les instances de routage et de transfert VPN (VRF) et les instances de routeur virtuel.

Les stratégies d’importation et d’exportation peuvent être appliquées à la famille inet flow ou à la famille inet-vpn flow NLRI, affectant les routes de flux acceptées ou annoncées, de la même manière que les stratégies d’importation et d’exportation sont appliquées à d’autres familles BGP. La seule différence est que la configuration de la stratégie de flux doit inclure l’instruction from rib inetflow.0 . Cette déclaration entraîne l’application de la stratégie aux routes de flux. Une exception à cette règle se produit si la stratégie n’a que l’instruction then reject ou then accept et aucune from instruction. Ensuite, la stratégie affecte tous les routes, y compris l’unicast IP et le flux IP.

Les filtres de routage de flux sont d’abord configurés statiquement sur un routeur, avec un ensemble de critères de correspondance suivis des actions à effectuer. Ensuite, en plus de family inet unicast, family inet flow (ou family inet-vpn flow) est configuré entre cet équipement compatible BGP et ses pairs.

Par défaut, les routes de flux à configuration statique (filtres de pare-feu) sont annoncées aux autres équipements compatibles BGP qui prennent en charge le nlRI ou family inet-vpn flow le ou le family inet flow nlri.

L’équipement récepteur compatible BGP effectue un processus de validation avant d’installer le filtre de pare-feu dans la table instance-name.inetflow.0de routage de flux . La procédure de validation est décrite dans la RFC 5575, Diffusion des règles de spécification de flux.

L’équipement récepteur compatible BGP accepte un routage de flux s’il passe les critères suivants :

  • L’auteur d’une route de flux correspond à l’auteur de la meilleure correspondance unicast route pour l’adresse de destination intégrée à la route.

  • Il n’existe plus de routes unicast spécifiques par rapport à l’adresse de destination de la route de flux, pour laquelle la route active a été reçue d’un autre système autonome de sauts suivants.

Le premier critère garantit que le filtre est annoncé par le saut suivant utilisé par le transfert unicast pour l’adresse de destination intégrée à la route de flux. Par exemple, si un routage de flux est donné en tant que 10.1.1.1, proto=6, port=80, l’équipement récepteur compatible BGP sélectionne le routage unicast plus spécifique dans la table de routage unicast qui correspond au préfixe de destination 10.1.1.1/32. Sur une table de routage unicast contenant 10.1/16 et 10.1.1/24, cette dernière est choisie comme route unicast pour la comparaison. Seule l’entrée de route unicast active est prise en compte. Cela suit le concept qu’une route de flux est valable si elle est annoncée par l’auteur de la meilleure route unicast.

Le deuxième critère répond aux situations dans lesquelles un bloc d’adresses donné est alloué à différentes entités. Les flux qui se résolvent à un routage unicast qui correspond le mieux à un routage agrégé ne sont acceptés que s’ils ne couvrent pas des routes plus spécifiques qui sont acheminées vers différents systèmes autonomes de saut suivant.

Vous pouvez contourner le processus de validation des routes de flux à l’aide de messages BGP NLRI et utiliser votre propre stratégie d’importation spécifique. Lorsque BGP transporte des messages NLRI de spécification de flux, l’instruction no-validate au niveau de la [edit protocols bgp group group-name family inet flow] hiérarchie omet la procédure de validation du routage de flux une fois que les paquets sont acceptés par une stratégie. Vous pouvez configurer la stratégie d’importation pour qu’elle corresponde à l’adresse de destination et aux attributs de chemin, tels que la communauté, le saut suivant et le chemin AS. Vous pouvez spécifier l’action à entreprendre si le paquet correspond aux conditions que vous avez configurées dans le routage de flux. Pour configurer une action, incluez l’instruction au niveau de la [edit routing-options flow] hiérarchie. Le type NLRI de spécification de flux comprend des composants tels que le préfixe de destination, le préfixe source, le protocole et les ports définis dans la RFC 5575. La stratégie d’importation peut filtrer une route entrante à l’aide des attributs de chemin et de l’adresse de destination dans la spécification de flux NLRI. La stratégie d’importation ne peut pas filtrer les autres composants de la RFC 5575.

La spécification de flux définit les extensions de protocole requises pour répondre aux applications les plus courantes de l’unicast IPv4 et du filtrage unicast VPN. Le même mécanisme peut être réutilisé et de nouveaux critères de correspondance peuvent être ajoutés pour traiter un filtrage similaire pour d’autres familles d’adresses BGP (par exemple, unicast IPv6).

Une fois qu’un routage de flux est installé dans la inetflow.0 table, il est également ajouté à la liste des filtres de pare-feu du noyau.

Sur les routeurs uniquement, les messages NLRI de spécification de flux sont pris en charge dans les VPN. Le VPN compare la communauté étendue cible de routage dans le NLRI à la politique d’importation. S’il y a une correspondance, le VPN peut commencer à utiliser les routes de flux pour filtrer et limiter le trafic de paquets. Les routes de flux reçues sont installées dans la table instance-name.inetflow.0de routage de flux . Les routes de flux peuvent également être propagées sur un réseau VPN et partagées entre VPN. Pour permettre à BGP multiprotocole (MP-BGP) de porter la spécification de flux NLRI pour la inet-vpn famille d’adresses, incluez l’instruction flow au niveau de la [edit protocols bgp group group-name family inet-vpn] hiérarchie. Les routes de flux VPN sont uniquement prises en charge pour l’instance par défaut. Les routes de flux configurées pour les VPN avec famille inet-vpn ne sont pas automatiquement validées, de sorte que l’instruction no-validate n’est pas prise en charge au niveau hiérarchique [edit protocols bgp group group-name family inet-vpn] . Aucune validation n’est nécessaire si les routes de flux sont configurées localement entre les équipements dans un seul AS.

Les stratégies d’importation et d’exportation peuvent être appliquées au family inet flow NLRI, family inet-vpn flow ce qui affecte les routes de flux acceptées ou annoncées, de la même manière que les stratégies d’importation et d’exportation sont appliquées à d’autres familles BGP. La seule différence est que la configuration de la stratégie de flux doit inclure l’instruction from rib inetflow.0 . Cette déclaration entraîne l’application de la stratégie aux routes de flux. Une exception à cette règle se produit si la stratégie n’a que l’instruction then reject ou then accept et aucune from instruction. Ensuite, la stratégie affecte tous les routes, y compris l’unicast IP et le flux IP.

Cet exemple montre comment configurer les stratégies d’exportation suivantes :

  • Stratégie qui autorise la publicité des routes de flux spécifiées par un filtre de routage. Seules les routes de flux couvertes par le bloc 10.13/16 sont annoncées. Cette stratégie n’affecte pas les routes unicast.

  • Une stratégie qui permet d’annoncer tous les routes unicast et de flux au voisin.

  • Une politique qui ne permet pas à tous les itinéraires (unicast ou flux) d’être annoncés au voisin.

topologie

Configuration

Configuration d’un routage de flux statique

Configuration rapide cli

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, puis copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie.

Procédure étape par étape

L’exemple suivant exige que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.

Pour configurer les sessions peer BGP :

  1. Configurez les conditions de correspondance.

  2. Configurez l’action.

  3. (Recommandé) Pour l’algorithme de spécification de flux, configurez l’ordre de termes basé sur la norme.

    Dans l’algorithme de commande des termes par défaut, comme spécifié dans le projet de RFC flowspec version 6, un terme avec des conditions de correspondance moins spécifiques est toujours évalué avant un terme avec des conditions de correspondance plus spécifiques. Cela fait que le terme avec des conditions de correspondance plus spécifiques ne peut jamais être évalué. La version 7 de la RFC 5575 a fait une révision de l’algorithme afin que les conditions de correspondance les plus spécifiques soient évaluées avant les conditions de correspondance moins spécifiques. En matière de rétrocompatibilité, le comportement par défaut n’est pas modifié dans Junos OS, même si le nouvel algorithme est plus logique. Pour utiliser le nouvel algorithme, incluez l’instruction term-order standard dans la configuration. Cette déclaration est prise en charge dans Junos OS version 10.0 et versions ultérieures.

Résultats

À partir du mode configuration, confirmez votre configuration en entrant la show routing-options commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.

Routes de flux publicitaires spécifiées par un filtre de routage

Configuration rapide cli

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, puis copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie.

Procédure étape par étape

L’exemple suivant exige que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.

Pour configurer les sessions peer BGP :

  1. Configurez le groupe BGP.

  2. Configurez la stratégie de flux.

  3. Configurez le numéro du système autonome local (AS).

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant le show protocols, show policy-optionset show routing-options les commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.

Publicité de toutes les routes unicast et de flux

Configuration rapide cli

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, puis copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie.

Procédure étape par étape

L’exemple suivant exige que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.

Pour configurer les sessions peer BGP :

  1. Configurez le groupe BGP.

  2. Configurez la stratégie de flux.

  3. Configurez le numéro du système autonome local (AS).

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant le show protocols, show policy-optionset show routing-options les commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.

Pas de routes unicast ou de flux publicitaires

Configuration rapide cli

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, puis copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie.

Procédure étape par étape

L’exemple suivant exige que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.

Pour configurer les sessions peer BGP :

  1. Configurez le groupe BGP.

  2. Configurez la stratégie de flux.

  3. Configurez le numéro du système autonome local (AS).

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant le show protocols, show policy-optionset show routing-options les commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.

Limitation du nombre de routes de flux installées dans une table de routage

Configuration rapide cli

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, puis copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie.

Procédure étape par étape

L’exemple suivant exige que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.

REMARQUE :

L’application d’une limite de route peut entraîner un comportement imprévisible du protocole de routage dynamique. Par exemple, une fois que la limite est atteinte et que les routes sont rejetées, BGP ne tente pas nécessairement de réinstaller les routes rejetées après que le nombre de routes soit inférieur à la limite. Les sessions BGP devront peut-être être être bloquées pour résoudre ce problème.

Pour limiter les routes de flux :

  1. Définissez une limite supérieure pour le nombre de préfixes installés dans inetflow.0 la table.

  2. Définissez une valeur seuil de 50 % : lorsque 500 routes sont installées, un avertissement est enregistré dans le journal système.

Résultats

À partir du mode configuration, confirmez votre configuration en entrant la show routing-options commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.

Limitation du nombre de préfixes reçus sur une session d’appairage BGP

Configuration rapide cli

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, puis copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie.

REMARQUE :

Vous pouvez inclure l’option teardown <percentage>, drop-excess <percentage>ou hide-excess<percentage> d’instruction une à la fois.

Procédure étape par étape

L’exemple suivant exige que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.

La configuration d’une limite de préfixe pour un voisin spécifique offre un contrôle plus prévisible sur l’homologue qui peut annoncer le nombre de routes de flux.

Pour limiter le nombre de préfixes :

  1. Définissez une limite de 1 000 routes BGP à partir du voisin 10.12.99.2.

  2. Configurez la ou les préfixes voisins pour qu’ils teardown <percentage>exécutent soit , drop-excess <percentage>ou hide-excess<percentage> l’option d’instruction lorsque la ou les sessions atteignent leurs limites.

    Si vous spécifiez l’instruction teardown <percentage> et spécifiez un pourcentage, les messages sont consignés lorsque le nombre de préfixes atteint ce pourcentage. Une fois la session terminée, la session est rétablie dans un court laps de temps, à moins que vous n’incluiez la idle-timeout déclaration.

    Si vous spécifiez l’instruction drop-excess <percentage> et spécifiez un pourcentage, les routes excédentaires sont supprimées lorsque le nombre de préfixes dépasse ce pourcentage

    Si vous spécifiez l’instruction hide-excess <percentage> et spécifiez un pourcentage, les routes excédentaires sont masquées lorsque le nombre de préfixes dépasse ce pourcentage.

Résultats

À partir du mode configuration, confirmez votre configuration en entrant la show protocols commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification du NLRI

But

Regardez le NLRI activé pour le voisin.

Action

À partir du mode opérationnel, exécutez la show bgp neighbor 10.12.99.5 commande. inet-flow Recherchez dans la sortie.

Vérification des routes

But

Regardez les routes de flux. L’exemple de sortie montre un routage de flux appris par BGP et un routage de flux configuré statiquement.

Pour les routes de flux configurées localement (configurées au niveau de [edit routing-options flow] la hiérarchie), les routes sont installées par le protocole de flux. Par conséquent, vous pouvez afficher les routes de flux en spécifiant la table, comme dans show route table inetflow.0 ou show route table instance-name.inetflow.0, où instance-name est le nom de l’instance de routage. Vous pouvez également afficher toutes les routes de flux configurées localement sur plusieurs instances de routage en exécutant la show route protocol flow commande.

Si un routage de flux n’est pas configuré localement, mais qu’il est reçu de l’homologue BGP du routeur, ce routage de flux est installé dans la table de routage par BGP. Vous pouvez afficher les routes de flux en spécifiant la table ou en exécutant show route protocol bgp, qui affiche toutes les routes BGP (flux et non-flux).

Action

À partir du mode opérationnel, exécutez la show route table inetflow.0 commande.

Sens

Un routage de flux représente un terme de filtre de pare-feu. Lorsque vous configurez un routage de flux, vous spécifiez les conditions de correspondance et les actions. Dans les attributs de correspondance, vous pouvez faire correspondre une adresse source, une adresse de destination et d’autres qualificatifs tels que le port et le protocole. Pour un routage de flux unique qui contient plusieurs conditions de correspondance, toutes les conditions de correspondance sont encapsulées dans le champ de préfixe de la route. Lorsque vous émettez la show route commande sur un routage de flux, le champ préfixe de la route s’affiche avec toutes les conditions de correspondance, 10.12.44.1,* ce qui signifie que la condition correspondante est match destination 10.12.44.1/32. Si le préfixe de la sortie était *,10.12.44.1, cela signifierait que la condition de correspondance était match source 10.12.44.1/32. Si les conditions correspondantes contiennent à la fois une source et une destination, l’astérisque est remplacé par l’adresse.

Les nombres d’ordre des termes indiquent la séquence des termes (routes de flux) évaluées dans le filtre de pare-feu. La show route extensive commande affiche les actions de chaque terme (route).

Vérification de la validation des flux

But

Affichez les informations sur le routage du flux.

Action

À partir du mode opérationnel, exécutez la show route flow validation detail commande.

Vérification des filtres de pare-feu

But

Affichez les filtres de pare-feu installés dans le noyau.

Action

À partir du mode opérationnel, exécutez la show firewall commande.

Vérification de la journalisation du système en cas de dépassement du nombre de routes de flux autorisées

But

Si vous configurez une limite du nombre de routes de flux installées, comme décrit dans Limitation du nombre de routes de flux installées dans une table de routage, consultez le message du journal système lorsque le seuil est atteint.

Action

À partir du mode opérationnel, exécutez la show log <message> commande.

Vérification de la journalisation du système en cas de dépassement du nombre de préfixes reçus sur une session d’appairage BGP

But

Si vous configurez une limite du nombre de routes de flux installées, comme décrit dans Limitation du nombre de préfixes reçus sur une session d’appairage BGP, consultez le message du journal système lorsque le seuil est atteint.

Action

À partir du mode opérationnel, exécutez la show log message commande.

Si vous spécifiez l’option d’instruction teradown <percentage> :

Si vous spécifiez l’option d’instruction drop-excess <percentage> :

Si vous spécifiez l’option d’instruction hide-excess <percentage> :

Exemple : Configuration de BGP pour transporter des routes de spécification de flux IPv6

Cet exemple montre comment configurer la spécification de flux IPv6 pour le filtrage du trafic. Les spécifications de flux BGP peuvent être utilisées pour automatiser la coordination inter-domaine et intra-domaine des règles de filtrage du trafic afin d’atténuer les attaques par déni de service.

Conditions préalables

Cet exemple utilise les composants matériels et logiciels suivants :

  • Deux routeurs MX Series

  • Junos OS Version 16.1 ou ultérieure

Avant d’activer BGP pour transporter des routes de spécification de flux IPv6 :

  1. Configurez les adresses IP sur les interfaces de l’équipement.

  2. Configurez BGP.

  3. Configurez une stratégie de routage qui exporte des routes (telles que des routes statiques, des routes directes ou des routes IGP) à partir de la table de routage vers BGP.

Présentation

Les spécifications de flux offrent une protection contre les attaques par déni de service et limitent le trafic défectueux qui consomme la bande passante et l’arrête près de la source. Dans les versions précédentes de Junos OS, les règles de spécification des flux ont été propagées pour IPv4 sur BGP en tant qu’informations d’accessibilité de la couche réseau. À partir de la version 16.1 de Junos OS, la fonctionnalité de spécification de flux est prise en charge sur la famille IPv6 et permet de propager les règles de spécification des flux de trafic pour IPv6 et VPN IPv6.

topologie

Figure 7 affiche la topologie de l’exemple. Les routeurs R1 et R2 appartiennent à différents systèmes autonomes. La spécification de flux IPv6 est configurée sur le routeur R2. Tout le trafic entrant est filtré en fonction des conditions de spécification du flux, et le trafic est traité différemment en fonction de l’action spécifiée. Dans cet exemple, tout le trafic vers abcd:11:11:11:10/128 qui correspond aux conditions de spécification du flux est rejeté ; que le trafic destiné à abcd::11:11:11:30/128 et correspondant aux conditions de spécification du flux est accepté.

Figure 7 : Configuration de BGP pour transporter des routes de flux IPv6Configuration de BGP pour transporter des routes de flux IPv6

Configuration

Configuration rapide cli

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à la configuration de votre réseau, copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie, puis entrez commit à partir du mode de configuration.

Routeur R1

Routeur R2

Configuration du routeur R2

Procédure étape par étape

L’exemple suivant exige que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation sur l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le guide de l’utilisateur CLI.

Pour configurer le routeur R2 :

REMARQUE :

Répétez cette procédure pour le routeur R1 après avoir modifié les noms d’interface, adresses et autres paramètres appropriés.

  1. Configurez les interfaces avec des adresses IPv6.

  2. Configurez l’adresse de bouclage IPv6.

  3. Configurez l’ID du routeur et le numéro du système autonome (AS).

  4. Configurez une session d’appairage EBGP entre le routeur R1 et le routeur R2.

  5. Configurez un routage statique et un saut suivant. Ainsi, un routage est ajouté à la table de routage pour vérifier la fonctionnalité de cet exemple.

  6. Spécifiez les conditions de spécification de flux.

  7. Configurez une discard action pour éliminer les paquets qui correspondent aux conditions de correspondance spécifiées.

  8. Spécifiez les conditions de spécification de flux.

  9. Configurer une accept action pour accepter les paquets qui correspondent aux conditions de correspondance spécifiées

  10. Définissez une stratégie qui permet à BGP d’accepter des routes statiques.

Résultats

À partir du mode de configuration, confirmez votre configuration en entrant le show interfaces, show protocols, show routing-optionset les show policy-options commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérifier la présence de routes de spécification de flux IPv6 dans la table inet6flow

But

Affichez les routes dans le inet6flow tableau des routeurs R1 et R2, et vérifiez que BGP a appris les routes de flux.

Action

À partir du mode opérationnel, exécutez la commande sur le show route table inet6flow.0 extensive routeur R1.

À partir du mode opérationnel, exécutez la show route table inet6flow.0 extensive commande sur le routeur R2.

Sens

La présence des routes abcd::11:11:11:10/128 et abcd::11:11:11:30/128 dans le inet6flow tableau confirme que BGP a appris les routes de flux.

Vérification des informations de synthèse BGP

But

Vérifiez que la configuration BGP est correcte.

Action

À partir du mode opérationnel, exécutez la commande sur les show bgp summary routeurs R1 et R2.

Sens

Vérifiez que la inet6.0 table contient l’adresse du voisin BGP et qu’une session d’appairage a été établie avec son voisin BGP.

Vérification de la validation des flux

But

Affichez les informations sur le routage du flux.

Action

À partir du mode opérationnel, exécutez la commande sur le show route flow validation routeur R1.

Sens

La sortie affiche les routes de flux dans la inet6.0 table.

Vérification des spécifications de flux des routes IPv6

But

Affichez le nombre de paquets qui sont rejetés et acceptés en fonction des routes de spécification de flux spécifiées.

Action

À partir du mode opérationnel, exécutez la show firewall filter_flowspec_default_inet6_ commande sur le routeur R2.

Sens

La sortie indique que les paquets destinés à abcd::11:11:10/128 sont éliminés et que les paquets 88826 ont été acceptés pour la route abcd::11:11:11:11:11:30/128.

Configuration des actions de spécification de flux BGP rediriger vers IP pour filtrer le trafic DDoS

À partir de la version 18.4R1 de Junos OS, la spécification de flux BGP telle que décrite dans BGP Flow-Spec Internet draft-ietf-idr-flowspec-redirect-ip-02.txt, la redirection vers l’action IP est prise en charge. Rediriger vers l’action IP utilise la communauté BGP étendue pour fournir des options de filtrage du trafic pour atténuer les DDoS dans les réseaux des fournisseurs de services. Rediriger les spécifications de flux héritées vers IP utilise l’attribut BGP nexthop. Junos OS affiche une redirection vers une action de spécification de flux IP à l’aide de la communauté étendue par défaut. Cette fonctionnalité est nécessaire pour prendre en charge le chaînage de services dans la passerelle de contrôle des services virtuels (vSCG). Rediriger vers l’action IP permet de détourner le trafic correspondant aux spécifications de flux vers une adresse globalement accessible qui pourrait être connectée à un équipement de filtrage capable de filtrer le trafic DDoS et d’envoyer le trafic propre à l’équipement sortant.

Avant de commencer à rediriger le trafic vers ip pour les routes de spécification de flux BGP, effectuez les opérations suivantes :

  1. Configurez les interfaces de l’équipement.

  2. Configurez OSPF ou tout autre protocole IGP.

  3. Configurez MPLS et LDP.

  4. Configurez BGP.

Configurez la redirection vers la fonctionnalité IP à l’aide de la communauté étendue BGP.

  1. Configurez la redirection vers l’action IP pour les routes statiques de spécification de flux IPv4 comme spécifié dans le projet BGP Flow-Spec Internet draft-ietf-idr-flowspec-redirect-ip-02.txt, Redirect to IP Action .

    Junos OS annonce une redirection vers une action de spécification de flux IP en utilisant la redirection de la communauté étendue vers IP par défaut. L’équipement entrant détecte et envoie le trafic DDoS à l’adresse IP spécifiée.

    Par exemple, redirigez le trafic DDoS vers l’adresse IPv4 10.1.1.1.

  2. Configurez la redirection vers l’action IP pour les routes statiques de spécification de flux IPv6.

    Par exemple, redirigez le trafic DDoS vers l’adresse IPv6 1002:db8::

  3. Définissez une stratégie pour filtrer le trafic d’une communauté BGP spécifique.

    Par exemple, définissez une stratégie p1 pour filtrer le trafic de la communauté BGP redirip.

  4. Définissez une stratégie pour définir, ajouter ou supprimer une communauté BGP et spécifiez la communauté étendue.

    Par exemple, définissez une stratégie p1 pour définir, ajouter ou supprimer un reidirip communautaire et une communauté étendue pour rediriger le trafic vers l’adresse IP 10.1.1.1.

  5. Configurez BGP pour utiliser la table VRF.inet.0 pour résoudre les spécifications de flux VRF les routes incluent une déclaration au niveau de la hiérarchie.

Configurez la redirection des spécifications de flux héritées vers la fonctionnalité IP à l’aide de l’attribut nexthop.

REMARQUE :

Vous ne pouvez pas configurer des stratégies pour rediriger le trafic vers une adresse IP à l’aide de la communauté étendue BGP et de la redirection héritée vers l’adresse IP du saut suivant.

  1. Configurez la redirection des spécifications de flux héritées vers l’ADRESSE IP spécifiée dans le projet Internet draft-ietf-idr-flowspec-redirect-ip-00.txt , BGP Flow-Spec Extended Community pour la redirection du trafic vers IP Next Hop inclure au niveau de la hiérarchie.

  2. Définissez une stratégie correspondant à l’attribut de saut suivant.

    Par exemple, définissez une stratégie p1 pour rediriger le trafic vers l’adresse IP 10.1.1.1.1.

  3. Définissez une stratégie pour définir, ajouter ou supprimer la communauté BGP à l’aide de la spécification de flux héritée rediriger l’attribut de saut suivant vers l’action IP.

    Par exemple, définissez une stratégie p1 et définissez, ajoutez ou supprimez une communauté BGP redirnh pour rediriger le trafic DDoS vers le saut suivant adresse IP 10.1.1.1.

Transfert du trafic à l’aide de la spécification de flux BGP action DSCP

Configurez l’action DSCP De flux BGP (FlowSpec) pour transférer efficacement les paquets à l’aide de la classe de transfert et des informations de priorité de perte sur le réseau.

Avantages de l’action BGP FlowSpec DSCP pour transférer des paquets

  • Transfère le trafic vers les files d’attente COS prévues, où les stratégies COS sont appliquées correctement au trafic.

  • Influence le comportement de transfert local (par exemple, la sélection du tunnel) en fonction de la valeur DSCP provisionné.

  • Aide à gérer efficacement le trafic sur votre réseau.

Lorsqu’un paquet pénètre dans un routeur, le paquet passe par les fonctionnalités (pare-feu, COS, etc.) appliquées à l’interface entrante. Lorsque vous configurez le filtre BGP FlowSpec sur l’interface entrante, le filtre est appliqué aux paquets par instance de routage en fonction de l’action DSCP. L’action DSCP classe et réécrit les paquets, ainsi que la modification du code DSCP via le filtre BGP FlowSpec. En fonction de la classe de transfert et des informations de priorité de perte, les paquets sont placés dans la file d’attente de transfert correcte. Les paquets passent par des routes de flux uniquement si des conditions de correspondance spécifiques sont remplies. Les conditions de correspondance peuvent être l’adresse IP source et de destination, le port source et de destination, DSCP, le numéro de protocole, etc. La classe de transfert et les informations de priorité des pertes sont mises à jour via la table de mappage inverse.

Voici la topologie d’une session BGP établie entre les réseaux du fournisseur de services et du client d’entreprise.

Avantages de l’action BGP FlowSpec DSCP pour transférer des paquets

Dans cette topologie, une session BGP est configurée entre le fournisseur de services et le réseau client d’entreprise pour BGP FlowSpec. Le filtre BGP FlowSpec est appliqué aux routeurs PE1 et PE2. Les paquets entrant dans ces routeurs sont réécrits en fonction du filtre BGP FlowSpec et de l’action DSCP.

Pour activer le filtre BGP FlowSpec sur un équipement, vous devez ajouter l’énoncé de dscp-mapping-classifier configuration au niveau de la hiérarchie [edit forwarding-options family (inet | inet6)] :

L’exemple de configuration de service suivant mappe les points de code DSCP à la classe de transfert et à la priorité de perte :

Tableau de l'historique des versions
Version
Description
20.3R1
À partir de la version 20.3R1 de cRPD, les routes de flux et les règles de contrôle propagées via la spécification de flux BGP NLRI sont téléchargées sur le noyau Linux via l’infrastructure Linux Netfilter sur les environnements cRPD.
17.2R1
À partir de la version 17.2R1 de Junos OS, BGP peut transporter des messages NLRI (Network Layer Reachability Information) de spécifications de flux sur les routeurs PTX1000 équipés de PFC de troisième génération.
17.1R1
À partir de la version 17.1R1 de Junos OS, BGP peut transporter des messages NLRI (Network Layer Reachability Information) sur les routeurs PTX Series équipés de SPC de troisième génération (FPC3-PTX-U2 et FPC3-PTX-U3 sur PTX5000 et FPC3-SFF-PTX-U0 et FPC3-SFF-PTX-U1 sur PTX3000).
16.1R4
À partir de la version 16.1R4 de Junos OS, la plage de débit-limite est de [0 à 1000000000000000].
16.1
À partir de la version 16.1 de Junos OS, la prise en charge d’IPv6 est étendue à la spécification de flux BGP qui permet de propager les règles de spécification des flux de trafic pour les paquets IPv6 et VPN-IPv6.
16.1
À partir de la version 16.1R1 de Junos OS, la spécification de flux BGP prend en charge l’action de filtrage du trafic extended-community .
16.1
À partir de la version 16.1 de Junos OS, vous pouvez ne pas appliquer le flowspec filtre au trafic reçu sur des interfaces spécifiques.
15.1
À partir de la version 15.1 de Junos OS, les modifications sont mises en œuvre pour étendre la prise en charge du routage actif sans interruption (NSR) aux familles inet-flow et inetvpn-flow existantes, et étendre la validation du routage pour les flux BGP par draft-ietf-idr-bgp-flowspec-oid-01.