Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Création de routes VPN uniques à l’aide de tables VRF

Comprendre les tables de routage et de transfert virtuelles

Pour séparer les routes d’un VPN des routes de l’Internet public ou d’autres VPN, le routeur PE crée une table de routage distincte pour chaque VPN, appelée table de routage et de transfert VPN (VRF). Le routeur PE crée une table VRF pour chaque VPN connecté à un routeur CE. Tout client ou site appartenant au VPN ne peut accéder qu’aux routes de ce VPN dans les tables VRF.

La figure 1 illustre les tables VRF créées sur les routeurs PE. Les trois routeurs PE sont connectés à des routeurs CE qui se trouvent dans deux VPN différents, de sorte que chaque routeur PE crée deux tables VRF, une pour chaque VPN.

Figure 1 : tableaux Network topology diagram showing MPLS VPN with CE, PE, and P routers. Illustrates VPN sites connected to an MPLS network via VRF instances for secure VPN service. VRF

Chaque table VRF est renseignée à partir des routes reçues des sites CE directement connectés associés à cette instance de routage VRF et à partir des routes reçues d’autres routeurs PE qui ont passé le filtrage de communauté BGP et qui se trouvent dans le même VPN.

Chaque routeur PE gère également une table de routage globale (inet.0) pour atteindre les autres routeurs à l’intérieur et à l’extérieur du réseau central du fournisseur.

Chaque connexion client (c’est-à-dire chaque interface logique) est associée à une table VRF. Seule la table VRF associée à un site client est consultée pour les paquets provenant de ce site.

Vous pouvez configurer le routeur de telle sorte que si aucun saut suivant vers une destination n’est trouvé dans la table VRF, le routeur effectue une recherche dans la table de routage globale, qui est utilisée pour l’accès à Internet.

Junos OS utilise les tables de routage suivantes pour les VPN :

  • bgp.l3vpn.0 : stocke les routes apprises à partir d’autres routeurs PE. Les routes de la table de routage bgp.l3vpn.0 sont copiées dans un VRF de couche 3 lorsqu’une stratégie d’importation VRF correspondante existe dans le routeur PE. Ce tableau n’est présent que sur les routeurs PE et ne stocke pas les routes reçues des routeurs CE directement connectés.

    Lorsqu’un routeur PE reçoit une route d’un autre routeur PE, il place la route dans sa table de routage bgp.l3vpn.0 . L’itinéraire est résolu à l’aide des informations de la table de routage inet.3. L’itinéraire résultant est converti au format IPv4 et redistribué à toutes les routing-instance-nametables de routage .inet.0 sur le routeur PE si elle correspond à la stratégie d’importation VRF.

    La table bgp.l3vpn.0 est également utilisée pour résoudre les routes sur les tunnels MPLS qui relient les routeurs PE. Ces routes sont stockées dans la table de routage inet.3 . La connectivité du routeur PE-à-PE doit exister dans inet.3 (et pas seulement dans inet.0) pour que les routes VPN soient résolues correctement.

    Lorsqu’un routeur annonce des routes unicast VPN-IPv4 non locales et que le routeur est un réflecteur de route ou effectue un appairage externe, les routes unicast VPN-IPv4 sont automatiquement exportées dans la table de routage VPN (bgp.l3vpn.0). Cela permet au routeur d’effectuer la sélection de chemin et d’annoncer à partir de la table de routage bgp.l3vpn.0 .

    Pour déterminer s’il faut ajouter une route à la table de routage bgp.l3vpn.0 , Junos OS la compare aux stratégies d’importation d’instance VRF de tous les VPN configurés sur le routeur PE. Si la route VPN-IPv4 correspond à l’une des stratégies, elle est ajoutée à la table de routage bgp.l3vpn.0 . Pour afficher les routes dans la table de routage bgp.l3vpn.0 , utilisez la commande show route table bgp.l3vpn.0 .

  • routing-instance-name.inet.0 : stocke toutes les routes IPv4 unicast reçues des routeurs CE directement connectés dans une instance de routage (c’est-à-dire dans un VPN unique) et toutes les routes statiques explicitement configurées dans l’instance de routage. Il s’agit de la table VRF et elle n’est présente que sur les routeurs PE. Par exemple, pour une instance de routage nommée VPN-A, la table de routage de cette instance est nommée VPN-A.inet.0.

    Lorsqu’un routeur CE annonce à un routeur PE, le routeur PE place l’itinéraire dans la table de routage .inet.0 correspondante routing-instance-name et annonce l’itinéraire aux autres routeurs PE s’il passe une stratégie d’exportation VRF. Entre autres choses, cette politique marque la route avec le séparateur de route (route target) qui correspond au site VPN auquel appartient le CE. Une étiquette est également allouée et distribuée avec l’itinéraire. La table de routage bgp.l3vpn.0 n’est pas impliquée dans ce processus.

    La routing-instance-nametable .inet.0 stocke également les routes annoncées par un routeur PE distant qui correspondent à la stratégie d’importation VRF pour ce VPN. Le routeur PE a redistribué ces routes à partir de sa table bgp.l3vpn.0 .

    Les routes ne sont pas redistribuées de la routing-instance-nametable .inet.0 à la table bgp.l3vpn.0 ; elles sont directement annoncées aux autres routeurs PE.

    Pour chaque table de routage .inet.0, une table de transfert est gérée dans le moteur de transfert de paquets du routeur. routing-instance-name Cette table est gérée en plus des tables de transfert qui correspondent aux tables de routage inet.0 et mpls.0 du routeur. Comme pour les tables de routage inet.0 et mpls.0, les meilleurs itinéraires de la routing-instance-nametable de routage .inet.0 sont placés dans la table de transfert.

    Pour afficher les itinéraires dans la routing-instance-nametable .inet.0 , utilisez la commande show route table routing-instance-name.inet.0 .

  • inet.3 : stocke toutes les routes MPLS apprises à partir des signaux LDP et RSVP effectués pour le trafic VPN. La table de routage stocke les routes MPLS uniquement si l’option bgp-igp d’ingénierie du trafic n’est pas activée.

    Pour que les routes VPN soient résolues correctement, la table inet.3 doit contenir les routes vers tous les routeurs PE du VPN.

    Pour afficher les routes dans la table inet.3 , utilisez la commande show route table inet.3 .

  • inet.0 : stocke les routes apprises par les sessions IBGP entre les routeurs PE. Pour fournir un accès Internet aux sites VPN, configurez la routing-instance-nametable de routage .inet.0 de manière à ce qu’elle contienne un itinéraire par défaut vers la table de routage inet.0.

    Pour afficher les routes dans la table inet.0 , utilisez la commande show route table inet.0 .

Les stratégies de routage suivantes, qui sont définies dans les instructions d’importation et d’exportation VRF, sont spécifiques aux tables VRF.

  • Stratégie d’importation : appliquée aux routes VPN-IPv4 apprises à partir d’un autre routeur PE pour déterminer si la route doit être ajoutée à la table de routage bgp.l3vpn.0 du routeur PE. Chaque instance de routage sur un routeur PE dispose d’une stratégie d’importation VRF.

  • Stratégie d’exportation : appliquée aux routes VPN-IPv4 annoncées vers d’autres routeurs PE. Les routes VPN-IPv4 sont des routes IPv4 qui ont été annoncées par les routeurs CE connectés localement.

Le traitement de routage VPN diffère du traitement de routage BGP normal d’une certaine manière. Dans BGP, les routes sont acceptées si elles ne sont pas explicitement rejetées par la stratégie d’importation. Toutefois, étant donné que de nombreuses autres routes VPN sont attendues, Junos OS n’accepte pas (et ne stocke donc pas) les routes VPN à moins que la route ne corresponde à au moins une stratégie d’importation VRF. Si aucune stratégie d’importation VRF n’accepte explicitement l’itinéraire, celui-ci est ignoré et n’est même pas stocké dans la table bgp.l3vpn.0 . Par conséquent, si une modification VPN se produit sur un routeur PE, comme l’ajout d’une nouvelle table VRF ou la modification d’une stratégie d’importation VRF, le routeur PE envoie un message d’actualisation de la route BGP aux autres routeurs PE (ou au réflecteur de route s’il fait partie de la topologie VPN) pour récupérer toutes les routes VPN afin qu’elles puissent être réévaluées afin de déterminer si elles doivent être conservées ou supprimées.

Voir aussi

Comprendre la localisation VRF dans les VPN de couche 3

Dans un VPN de couche 3, pour séparer les routes d’un VPN des routes de l’Internet public ou d’autres VPN, le routeur PE crée une table de routage distincte pour chaque VPN, appelée table VRF (Virtual Routing and Forwarding). Chaque VRF utilise un séparateur de route et une cible de route pour différencier les autres VPN afin que chaque VRF obtienne un VPN dans un réseau public. Le routeur PE crée une table VRF pour chaque VPN connecté à un routeur CE. Tout client ou site appartenant au VPN ne peut accéder qu’aux routes de ce VPN dans les tables VRF.

Les routeurs PE d’un déploiement VPN de couche 3 disposent de deux types de cartes de ligne hébergeant les interfaces suivantes :

  • Interfaces orientées CE

  • Interfaces orientées vers le cœur

Note:

Un FPC peut être orienté core ou CE.

Les VRF sont présents sur ces cartes de ligne et actuellement, dans Junos OS, toutes les routes de tous les VRF sont présentes sur toutes les cartes de ligne avec les sauts suivants composites chaînés sur tous les FPC. Cela consomme de la mémoire dans chaque carte de ligne. Étant donné que le trafic provenant des interfaces orientées CE provient uniquement des FPC correspondants, il n’est pas nécessaire que toutes les routes et tous les sauts suivants soient présents sur toutes les cartes de ligne. La localisation VRF fournit un mécanisme permettant de localiser les routes du VRF vers des cartes de ligne spécifiques afin d’optimiser le nombre de routes qu’un routeur peut gérer. Les interfaces CE localisent toutes les routes de type d’instance VRF sur une carte de ligne spécifique. Si les interfaces CE sont des interfaces logiques de type AE, RLSQ ou IRB, un numéro de carte de ligne doit être configuré pour localiser les routes. Les cartes de ligne orientées vers le noyau stockent toutes les routes VRF. Ces cartes doivent être configurées en tant que cartes VPN core par défaut ou VPN core uniquement. Les cartes de ligne orientées vers le cœur stockent les routes de tous les VRF, et elles sont des types suivants :

  • vpn-core-facing-default — Le FPC orienté cœur installe toutes les routes et les sauts suivants des routes VRF.

  • vpn-core-facing-only — Le FPC orienté cœur installe toutes les routes et ne stocke pas les sauts suivants des routes VRF.

Note:

Les FPC orientés cœur peuvent être configurés en mode cœur par défaut ou cœur uniquement.

Optimisation des routes VPN à l’aide de la localisation VRF pour les VPN de couche 3

La localisation VRF (Virtual routing and forwarding) fournit un mécanisme permettant de localiser les routes du VRF vers des cartes de ligne spécifiques afin d’optimiser le nombre de routes qu’un routeur peut gérer. Les interfaces CE localisent toutes les routes de type d’instance VRF sur une carte de ligne spécifique. Si les interfaces CE sont des interfaces logiques de type AE/RLSQ/IRB, la carte de ligne doit être configurée pour localiser les routes. Les cartes de ligne orientées vers le noyau stockent toutes les routes VRF. Ces cartes doivent être configurées en tant que cartes VPN core uniquement ou VPN core par défaut. Pour configurer la localisation VRF, configurez l’instruction localized-fib au niveau hiérarchique [edit routing-instances instance-name routing-options] et configurez l’instruction vpn-localization au niveau hiérarchique [edit chassis fpc fpc-slot] . La show route vpn-localization commande affiche les informations de localisation de tous les VRF du système.

Avant de commencer à localiser la table VRF :

  • Configurez les interfaces.

  • Configurez les protocoles de routage et de signalisation.

Pour configurer la localisation VRF :

  1. Configurez le châssis du routeur.

    1. Configurez l’emplacement FPC en tant qu’emplacement VPN core uniquement ou VPN core par défaut pour stocker les routes VRF.

  2. Configurez le service de réseau IP amélioré sur le châssis.
  3. Créez un type d’instance, configurez le séparateur de route, et configurez la communauté cible VRF et l’étiquette cible VRF.
  4. Configurez l’option de routage par trajets multiples pour équilibrer la charge indépendamment du protocole.
  5. Configurez le FPC spécifique des interfaces physiques orientées CE ou spécifiez le numéro de slot FPC si les interfaces CE sont des interfaces logiques de type AE ou RSQL ou IRB pour localiser les routes d’instance de routage VRF.

    • Configurez le FPC spécifique des interfaces physiques orientées CE pour localiser les routes d’instance de routage VRF.

    • Configurez le numéro de slot FPC des interfaces logiques CE telles que AE ou RSQL ou IRB pour localiser les routes d’instance de routage VRF.

  6. Configurez le groupe homologue du protocole BGP pour l’instance de routage.
  7. Configurez le protocole MVPN pour l’instance de routage.

Exemple : Amélioration de l’évolutivité à l’aide de la localisation VRF pour les VPN de couche 3

Cet exemple montre comment configurer la localisation VRF sur les routeurs MX Series, ce qui vous permet d’améliorer l’évolutivité VPN sur les routeurs MX Series.

Exigences

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

  • Cinq plates-formes de routage universelles 5G MX Series

  • Junos OS version 14.2 ou ultérieure s’exécute sur tous les équipements

Avant de commencer :

  1. Configurez les interfaces des appareils.

  2. Configurez le protocole BGP.

Aperçu

À partir de la version 14.2 de Junos OS, la localisation VRF fournit un mécanisme permettant de localiser les routes du VRF vers des cartes de ligne spécifiques, ce qui permet d’optimiser le nombre de routes qu’un routeur peut gérer. Les interfaces CE localisent toutes les routes de type d’instance VRF sur une carte de ligne spécifique. Si les interfaces CE sont des interfaces logiques de type AE, RLSQ ou IRB, la carte de ligne doit être configurée pour localiser les routes. Les cartes de ligne orientées vers le noyau stockent toutes les routes VRF. Ces cartes doivent être configurées en tant que cartes VPN core uniquement ou VPN core par défaut. Pour configurer la localisation VRF, configurez l’instruction de localized-fib configuration au niveau hiérarchique [edit routing-instances instance-name routing-options] et configurez vpn-localization au niveau hiérarchique [edit chassis fpc fpc-slot] . La show route vpn-localization commande affiche les informations de localisation de tous les VRF du système.

Topologie

Dans la topologie illustrée à la Figure 2, la localisation VRF est configurée sur l’équipement PE1.

Figure 2 : exemple de Network topology diagram with CE routers CE1 192.0.2.2/24 and CE2 198.51.100.4/24, PE routers PE1 192.0.2.3/24, PE2 198.51.100.3/24, and a core P router. Aggregated Ethernet links ae0 and ae1 connect PE1, P, and PE2. localisation VRF

Configuration

Configuration rapide de la CLI

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, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis entrez commit à partir du mode de configuration.

CE1

PE1

L

PE2

CE2

Configuration de l’équipement PE1

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode Configuration.

Pour configurer l’équipement PE1 :

  1. Spécifiez le nombre d’interfaces Ethernet agrégées à créer, configurez les FPC en mode vpn-core uniquement et activez les services réseau IP améliorés.

  2. Configurez les interfaces.

  3. Configurez les options de stratégie pour équilibrer la charge des paquets.

  4. Configurez le protocole RSVP sur l’interface.

  5. Configurez le protocole MPLS.

  6. Configurez le protocole BGP pour le groupe mpbg.

  7. Configurez le protocole OSPF.

  8. Configurez le protocole LDP sur l’interface.

  9. Créez un type d’instance et configurez les instances de routage sur l’interface.

  10. Configurez le séparateur de route et configurez le LSP statique pour le tunnel fournisseur RSVP-TE.

  11. Configurez la cible VRF et le libellé de la cible VRF pour l’instance de routage.

  12. Configurez l’option de routage multichemin pour une instance de routage et configurez l’option de routage FIB localisé pour l’instance de routage.

  13. Configurez le groupe de protocoles BGP pour une instance de routage.

  14. Configurez les protocoles MVPN.

  15. Configurez le routage actif ininterrompu et le numéro du système autonome pour une option de routage.

  16. Configurez la stratégie d’équilibrage de charge pour la table de transfert et l’espace étendu pour le saut suivant composite chaîné pour le L3VPN de la table de transfert.

Résultats

En mode configuration, confirmez votre configuration en entrant les show chassiscommandes , show interfaces, show policy-options, show protocolsshow routing-instances, et show routing-options . 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 terminé de configurer l’appareil, passez commit en mode de configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification de la localisation VRF

But

Vérifiez la localisation du VRF dans un VPN de couche 3.

Action

À partir du mode opérationnel, exécutez la commande pour l’appareil show route vpn-localization PE1.

Signification

La sortie affiche les informations de localisation de tous les VRF.

Vérification de la localisation VRF d’un VPN

But

Vérifiez la localisation VRF d’un VPN.

Action

À partir du mode opérationnel, exécutez la show route vpn-localization vpn-name vpn-name commande.

Signification

La sortie montre la localisation VPN d’un VPN.

Filtrage des paquets dans les VPN de couche 3 en fonction des en-têtes IP

L’inclusion de l’instruction vrf-table-label dans la configuration d’une instance de routage permet de mapper l’étiquette interne à une table de routage VRF spécifique ; ce mappage permet d’examiner l’en-tête IP encapsulé au niveau d’un routeur VPN de sortie. Vous pouvez activer cette fonctionnalité afin de pouvoir effectuer l’une des opérations suivantes :

  • Transférez le trafic sur une interface PE-routeur-équipement CE, sur un support partagé, où le périphérique CE est un commutateur de couche 2 sans capacités IP (par exemple, un commutateur Ethernet urbain).

    La première recherche est effectuée sur l’étiquette VPN pour déterminer la table VRF à laquelle se référer, et la seconde recherche est effectuée sur l’en-tête IP pour déterminer comment transférer les paquets vers les hôtes finaux appropriés sur le support partagé.

  • Effectuez un filtrage de sortie au niveau du routeur PE de sortie.

    La première recherche sur l’étiquette VPN est effectuée pour déterminer la table de routage VRF à laquelle se référer, et la deuxième recherche est effectuée sur l’en-tête IP pour déterminer comment filtrer et transférer les paquets. Vous pouvez activer cette fonctionnalité en configurant des filtres de sortie sur les interfaces VRF.

    Lorsque vous incluez l’instruction vrf-table-label dans la configuration d’une table de routage VRF, une étiquette d’interface logique LSI (Label-switched interface) est créée et mappée à la table de routage VRF. Tous les itinéraires d’une telle table de routage VRF sont annoncés avec l’étiquette d’interface logique LSI attribuée à la table de routage VRF. Lorsque les paquets de ce VPN arrivent sur une interface centrale, ils sont traités comme si le paquet IP inclus arrivait sur l’interface LSI, puis sont transférés et filtrés en fonction de la table correcte.

Pour filtrer le trafic en fonction de l’en-tête IP, incluez l’instruction vrf-table-label suivante :

Vous pouvez inclure l’instruction aux niveaux hiérarchiques suivants :

  • [edit routing-instances routing-instance-name]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name]

Vous pouvez inclure l’instruction vrf-table-label pour les VPN de couche 3 IPv4 et IPv6. Si vous incluez l’instruction d’une table de routage VRF à double pile (où les routes IPv4 et IPv6 sont prises en charge), l’instruction s’applique aux routes IPv4 et IPv6 et le même libellé est annoncé pour les deux ensembles de routes.

Vous pouvez également configurer la comptabilisation SCU pour les VPN de couche 3 configurés avec l’instruction vrf-table-label en incluant également l’option source-class-usage . Incluez l’instruction source-class-usage au niveau de la [edit routing-instances routing-instance-name vrf-table-label] hiérarchie. L’instruction source-class-usage à ce niveau hiérarchique n’est prise en charge que pour le type d’instance vrf (VPN de couche 3). DCU n’est pas pris en charge pour l’instruction vrf-table-label . Pour plus d’informations, consultez Activation de l’utilisation de la classe source et de la classe de destination.

Les sections suivantes fournissent plus d’informations sur le filtrage du trafic en fonction de l’en-tête IP :

Options de filtrage sortant

Vous pouvez activer le filtrage sortant (qui permet aux routeurs PE VPN de couche 3 sortants d’effectuer des recherches sur l’étiquette VPN et l’en-tête IP en même temps) en incluant l’instruction vrf-table-label au niveau de la [edit routing-instances instance-name] hiérarchie. Il n’y a aucune restriction quant à l’inclusion de cette déclaration pour les interfaces de routeur CE vers routeur PE, mais il existe plusieurs limitations sur les autres types d’interfaces, comme décrit dans les sections suivantes de cette rubrique.

Vous pouvez également activer le filtrage sortant en configurant une interface de tunnel VPN (VT) sur des plates-formes de routage équipées d’une carte d’interface physique (PIC) des services de tunnel. Lorsque vous activez le filtrage sortant de cette manière, il n’y a aucune restriction sur le type d’interface principale utilisé. Il n’y a pas non plus de restriction sur le type d’interface routeur-routeur PE utilisé.

Prise en charge des interfaces agrégées et VLAN pour le filtrage IP

La prise en charge de l’instruction vrf-table-label sur les interfaces agrégées et VLAN est disponible sur les routeurs résumés dans le Tableau 1.

Tableau 1 : prise en charge des interfaces agrégées et VLAN

Interfaces

Routeur M Series sans FPC amélioré

Routeur M Series avec FPC amélioré

Routeur M320

Routeur T Series

Agrégées

Non

Oui

Oui

Oui

VLAN (en anglais)

Non

Oui

Oui

Oui
Note:

L’instruction vrf-table-label n’est pas prise en charge pour les interfaces physiques Gigabit Ethernet agrégées, 10 Gigabit Ethernet et VLAN sur les routeurs M120.

Prise en charge sur les interfaces ATM et Frame Relay pour le filtrage IP

La prise en charge de l’instruction vrf-table-label sur les interfaces ATM (Asynchronous Transfer Mode) et Frame Relay est disponible sur les routeurs résumés dans le Tableau 2.

Tableau 2 : Prise en charge des interfaces ATM et Frame Relay

Interfaces

Routeur M Series sans FPC amélioré

Routeur M Series avec FPC amélioré

Routeur M320

Routeur T Series

ATM1

Non

Non

Non

Non

File d’attente intelligente (IQ) ATM2

Non

Oui

Oui

Oui

Relais de trame

Non

Oui

Oui

Oui

Canalisé

Non

Non

Non

Non

Lorsque vous incluez l’instruction vrf-table-label , tenez compte des limitations suivantes avec les interfaces ATM ou Frame Relay :

  • L’instruction vrf-table-label est prise en charge sur les interfaces ATM, mais avec les limitations suivantes :

    • Les interfaces ATM peuvent être configurées sur le routeur M320 et les routeurs T Series, ainsi que sur les routeurs M Series dotés d’un FPC amélioré.

    • Il ne peut s’agir que d’une interface de routeur PE recevant le trafic d’un routeur P.

    • Le routeur doit disposer d’un ATM2 IQ PIC.

  • L’instruction vrf-table-label est également prise en charge sur les interfaces encapsulées Frame Relay, mais avec les limitations suivantes :

    • Les interfaces Frame Relay peuvent être configurées sur le routeur M320 et les routeurs T Series, ainsi que sur les routeurs M Series dotés d’un FPC amélioré.

    • Il ne peut s’agir que d’une interface de routeur PE recevant le trafic d’un routeur P.

Prise en charge des interfaces Ethernet, SONET/SDH et T1/T3/E3 pour le filtrage IP

La prise en charge de l’instruction vrf-table-label via les interfaces Ethernet, SONET/SDH et T1/T3/E3 est disponible sur les routeurs résumés dans le Tableau 3.

Tableau 3 : prise en charge des interfaces Ethernet, SONET/SDH et T1/T3/E3

Interfaces

Routeur M Series sans FPC amélioré

Routeur M Series avec FPC amélioré

Routeur M320

Routeur T Series

Ethernet

Oui

Oui

Oui

Oui

SONET/SDH

Oui

Oui

Oui

Oui

T1/T3/E3

Oui

Oui

Oui

Oui

Seuls les PIC Ethernet suivants prennent en charge cette vrf-table-label déclaration sur les routeurs M Series sans FPC amélioré :

  • 1 port Gigabit Ethernet

  • 2 ports Gigabit Ethernet

  • Fast Ethernet à 4 ports

Prise en charge des interfaces de file d’attente intelligentes améliorées et canalisées SONET/SDH et DS3/E3 pour le filtrage IP

La prise en charge de l’instruction vrf-table-label pour les interfaces IQE canalisées spécifiées n’est disponible que sur les routeurs M120 et M320 équipés de FPC Enhanced III, comme résumé dans le Tableau 4.

Tableau 4 : Prise en charge des interfaces IQE canalisées sur les routeurs M320 avec FPC Enhanced III

Interfaces

Routeurs M120 avec FPC Enhanced III

Routeurs M320 avec FPC Enhanced III

OC12

Oui

Oui

STM4

Oui

Oui

OC3

Oui

Oui

STM1 (en anglais seulement)

Oui

Oui

DS3

Oui

Oui

L’E3

Oui

Oui

Les PIC IQE de type 1 suivants sont pris en charge :

  • 1 port OC12/STM4 IQE avec SFP

  • 4 ports OC3/STM1 IQE avec SFP

  • DS3/E3 IQE à 4 ports avec BNC

  • IQE OC3/STM1 canalisé à 2 ports avec SFP, sans partitions SONET

  • 1 port OC12/STM4 IQE canalisé avec SFP, sans partitions SONET

Les contraintes suivantes s’appliquent à une configuration de routeur utilisant des systèmes logiques :

  • Contraintes des interfaces PIC IQE multiports : sur les PIC IQE multiports, tels que l’IQE OC3/STM1 canalisé à 2 ports avec SFP, si l’interface du port 1 est configurée comme un système logique avec sa propre instance de routage et que l’interface du port 2 est configurée comme un système logique différent avec ses propres instances de routage, de sorte qu’il existe des interfaces logiques orientées cœur sur les ports 1 et 2, alors vous ne pouvez pas configurer l’instruction vrf-table-label sur routing-instance dans les deux systèmes logiques. Un seul jeu d’étiquettes LSI est pris en charge ; La dernière instance de routage pour laquelle l’instruction vrf-table-label est configurée est validée.

  • Encapsulation du relais de trames et interfaces logiques sur les contraintes des systèmes logiques : comme pour le PIC multiport avec les systèmes logiques, si vous essayez de configurer une interface logique d’un PIC IQE avec l’encapsulation du relais de trames dans un système logique et de configurer une autre interface logique sur le même PIC IQE dans le second système logique, la configuration ne fonctionnera pas pour toutes les instances configurées pour l’instruction vrf-table-label . Cela ne fonctionnera que pour les instances configurées dans l’un des systèmes logiques.

Les deux contraintes ci-dessus sont dues au fait que la configuration du routeur gère une arborescence LSI dans le moteur de transfert de paquets par système logique, ce qui est commun à tous les flux. La recherche de la table des canaux de flux est ensuite ajustée pour pointer vers l’arborescence LSI. Dans le cas des PIC IQE multiports de type 1, toutes les interfaces physiques partagent le même flux. Par conséquent, les interfaces logiques (multiports ou non) partagent évidemment le même flux. Par conséquent, la liaison LSI se fait au niveau du flux. Par conséquent, le provisionnement d’interfaces logiques sous le même flux provisionné pour être orienté vers le cœur et la prise en charge d’un ensemble différent d’instances de routage avec l’instruction vrf-table-label n’est pas pris en charge.

Prise en charge des interfaces PPP multiliaisons et relais de trames multiliaisons pour le filtrage IP

La prise en charge de l’instruction vrf-table-label sur les interfaces MLPPP (Multilink Point-to-Point Protocol) et MLFR (Multilink Frame Relay) est disponible sur les routeurs résumés dans le Tableau 5.

Tableau 5 : Prise en charge des interfaces PPP multiliaisons et relais de trames multiliaisons

Interfaces

Routeur M Series sans FPC amélioré

Routeur M Series avec FPC amélioré

Réf. M320

Routeur T Series

Routeur MX Series

Le MLPPP (en anglais seulement)

Non

Oui

Non

Non

Non

MLFR de bout en bout (FRF.15)

Non

Oui

Non

Non

Non

UNI/NNI MLFR (FRF.16)

Non

Non

Non

Non

Non

Les routeurs M Series doivent disposer d’un AS PIC pour prendre en charge l’instruction sur les vrf-table-label interfaces MLPPP et MLFR. L’instruction vrf-table-label sur les interfaces MLPPP n’est pas prise en charge sur les routeurs M120.

Prise en charge du filtrage IP des paquets avec des étiquettes supérieures nulles

Vous pouvez inclure l’instruction vrf-table-label dans la configuration pour les interfaces centrales recevant des paquets MPLS avec une étiquette supérieure nulle, qui peut être transmise par l’équipement de certains fournisseurs. Ces paquets peuvent être reçus uniquement sur le routeur M320, le routeur M10i et les routeurs centraux T Series à l’aide de l’un des PIC suivants :

  • 1 port Gigabit Ethernet avec SFP

  • 2 ports Gigabit Ethernet avec SFP

  • 4 ports Gigabit Ethernet avec SFP

  • 10 ports Gigabit Ethernet avec SFP

  • 1 port SONET STM4

  • 4 ports SONET STM4

  • 1 port SONET STM16

  • 1 port SONET STM16 (non-SFP)

  • 4 ports SONET STM16

  • 1 port SONET STM64

Les PIC suivants peuvent recevoir des paquets avec des étiquettes supérieures nulles, mais uniquement lorsqu’ils sont installés dans un routeur M120 ou un routeur M320 avec un FPC Enhanced III :

  • 1 port 10 Gigabit Ethernet

  • 1 port 10 Gigabit Ethernet IQ2

Limitations générales du filtrage basé sur IP

Les limitations suivantes s’appliquent lorsque vous incluez l’instruction vrf-table-label :

  • Les filtres de pare-feu ne peuvent pas être appliqués aux interfaces incluses dans une instance de routage sur laquelle vous avez configuré l’instruction vrf-table-label .

  • La durée de vie (TTL) dans l’en-tête MPLS n’est pas recopiée dans l’en-tête IP des paquets envoyés par le routeur PE au routeur CE.

  • Vous ne pouvez pas inclure l’instruction vrf-table-label dans une configuration d’instance de routage qui inclut également une interface de tunnel de bouclage virtuel ; l’opération de validation échoue dans ce cas.

  • Lorsque vous incluez l’instruction, les paquets MPLS avec des étiquettes d’interface à commutation d’étiquettes (LSI) qui arrivent sur les interfaces orientées cœur ne sont pas comptés au niveau de l’interface logique si l’interface orientée cœur est l’une des suivantes :

    • ATM

    • Relais de trame

    • Ethernet configuré avec des VLAN

    • Ethernet agrégé configuré avec des VLAN

  • Pour les moteurs de transfert de paquets basés sur LMNR, Stoli et I-Chip, vous ne pouvez pas inclure l’instruction dans la configuration d’une instance de routage VRF si l’interface routeur-routeur PE vers routeur P est l’une des interfaces suivantes :

    Note:

    L’instruction vrf-table-label est prise en charge lorsque l’interface routeur-routeur PE vers routeur P est une interface tunnel sur un moteur de transfert de paquets basé sur Junos Trio, de sorte qu’aucune limitation ne s’applique.

    • Interface SONET/SDH agrégée

    • Interface canalisée

    • Interface de tunnel (par exemple, encapsulation de routage générique [GRE] ou sécurité IP [IPsec])

    • Interface encapsulée par connexion croisée de circuit (CCC) ou connexion croisée translationnelle (TCC)

    • Interface de tunnel logique

    • Interface encapsulée VPLS (Virtual Private LAN Service)

      Note:

      Toutes les interfaces routeur-routeur-PE et routeur-routeur PE-routeur CE sont prises en charge.

  • Vous ne pouvez pas inclure l’instruction vrf-table-label dans la configuration d’une instance de routage VRF si le PIC PE-routeur-routeur P est l’un des PIC suivants :

    • 10 ports E1

    • Fast Ethernet à 8 ports

    • Fast Ethernet à 12 ports

    • Fast Ethernet 48 ports

    • PIC ATM autre que l’ATM2 IQ

  • Les statistiques de trafic de l’interface à commutation d’étiquettes (LSI) ne sont pas prises en charge pour les PIC IQ2 (Intelligent Queuing 2), IQE (IQE) et IQ2 amélioré (IQ2E) sur les routeurs M Series.

Voir aussi

Configuration d’une stratégie d’attribution et de substitution d’étiquettes pour les VPN

Vous pouvez contrôler les annonces d’étiquettes sur les routeurs MPLS d’entrée et les routeurs de bordure AS (ASBR). Les étiquettes peuvent être attribuées par saut suivant (par défaut) ou par table (en configurant l’instruction vrf-table-label ). Ce choix affecte toutes les routes d’une instance de routage donnée. Vous pouvez également configurer une stratégie pour générer des étiquettes par route en spécifiant une stratégie d’attribution d’étiquettes.

Pour spécifier une stratégie d’attribution d’étiquettes pour l’instance de routage, configurez l’instruction label et spécifiez une stratégie d’attribution d’étiquettes à l’aide de l’option d’allocation :

Vous pouvez configurer cette instruction aux niveaux hiérarchiques suivants :

  • [edit routing-instances routing-instance-name routing-options]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options]

Note:

Le [edit logical-systems] niveau hiérarchique ne s’applique pas aux routeurs ACX Series.

Pour configurer la stratégie d’attribution d’étiquettes, incluez l’instruction label-allocation au niveau de la [edit policy-options policy-statement policy-statement-name term term-name then] hiérarchie. Vous pouvez configurer le mode d’attribution des étiquettes en tant que per-nexthop ou per-table.

Pour un ASBR VPN option B, les étiquettes des routes de transit sont remplacées par une étiquette de tunnel virtuel local ou une étiquette vrf-table-label. Lorsqu’une table VRF est configurée sur l’ASBR (ce type de configuration est rare pour le modèle de l’option B), l’ASBR ne génère pas d’état d’échange MPLS ou d’échange et de push pour les routes de transit. Au lieu de cela, l’ASBR publie à nouveau une étiquette de tunnel virtuel local ou vrf-table-label et transfère ce trafic de transit en fonction des tables de transfert IP. La substitution d’étiquettes permet de conserver les étiquettes sur les routeurs Juniper Networks.

Toutefois, ce type de substitution d’étiquettes interrompt effectivement le chemin de transfert MPLS, qui devient visible lors de l’utilisation d’une commande MPLS OAM telle que LSP ping. Vous pouvez configurer la manière dont les étiquettes sont substituées par route en spécifiant une stratégie de substitution d’étiquettes.

Pour spécifier une stratégie de substitution d’étiquettes pour l’instance de routage, configurez l’instruction label et spécifiez une stratégie de substitution d’étiquettes à l’aide de l’option de substitution :

Vous pouvez configurer cette instruction aux niveaux hiérarchiques suivants :

  • [edit routing-instances routing-instance-name routing-options]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options]

Note:

Le [edit logical-systems] niveau hiérarchique ne s’applique pas aux routeurs ACX Series.

La stratégie de substitution d’étiquettes est utilisée pour déterminer si une étiquette doit être remplacée ou non sur un routeur ASBR. Les résultats de l’opération de stratégie sont soit accepter (la substitution d’étiquettes est effectuée), soit rejeter (la substitution d’étiquettes n’est pas effectuée). Le comportement par défaut est accept. L’exemple de commande d’ensemble suivant illustre comment vous pouvez configurer une stratégie de substitution d’étiquette de rejet : set policy-options policy-statement no-label-substitution term default then reject.