Configuration des tunnels du fournisseur de signalisation et du plan de données

P-PIM et C-PIM sur le routeur PE de l’expéditeur

Le routeur PE émetteur installe une entrée de jointure locale dans sa base de données P-PIM pour chaque table VRF configurée pour utiliser PIM comme tunnel fournisseur. La liste des interfaces sortantes (OIL) de cette entrée pointe vers l’interface orientée vers le cœur. Étant donné que l’entrée P-PIM est installée sous la forme Local, le routeur PE émetteur définit l’adresse source sur son adresse IP de bouclage principale.

Utilisez la show pim join extensive commande pour vérifier que le routeur PE1 a installé l’état suivant dans sa base de données P-PIM.

Du côté VRF du routeur PE émetteur, C-PIM installe une Local Source entrée dans sa base de données C-PIM pour la source VPN locale active. L’OIL de cette entrée pointe vers Pseudo-MVPN, ce qui indique que l’interface en aval pointe vers les récepteurs du réseau MVPN de nouvelle génération. Les routeurs référencés dans cette rubrique sont présentés dans la section Présentation de la topologie de réseau MVPN nouvelle génération.

Utilisez la show pim join extensive instance vpna 224.1.1.1 commande pour vérifier que le routeur PE1 a installé l’entrée suivante dans sa base de données C-PIM.

L’entrée de transfert correspondant au C-PIM Local Source (ou Local RP) sur le routeur PE émetteur pointe vers la sous-interface d’encapsulation du tunnel multicast en tant qu’interface en aval. Cela indique que les paquets de données multicast locaux sont encapsulés au fur et à mesure qu’ils sont transmis au protocole P-PIM.

Utilisez la show multicast route extensive instance vpna group 224.1.1.1 commande pour vérifier que le routeur PE1 dispose de l’entrée de transfert multicast suivante pour le groupe 224.1.1.1. L’interface amont est l’interface PE-CE et l’interface aval est la sous-interface d’encapsulation de tunnel multicast :

P-PIM et C-PIM sur le routeur PE du récepteur

Sur le routeur PE récepteur, les paquets de données multicast reçus du réseau sont désencapsulés au fur et à mesure qu’ils passent par l’interface de désencapsulation du tunnel multicast.

La base de données P-PIM sur le routeur PE récepteur contient deux jointures P. L’un est destiné au P-RP et l’autre au routeur PE de l’émetteur. Pour les deux entrées, l’OIL contient l’interface de désencapsulation du tunnel multicast à partir de laquelle l’en-tête GRE est détaché. L’interface en amont pour les jointures P est l’interface orientée vers le cœur qui fait face au routeur PE émetteur.

Utilisez la show pim join extensive commande pour vérifier que le routeur PE3 a l’état suivant dans sa base de données P-PIM. L’interface voisine en aval pointe vers la sous-interface de désencapsulation GRE :

Du côté VRF du routeur PE récepteur, C-PIM installe une entrée de jointure dans sa base de données C-PIM. L’OIL de cette entrée pointe vers l’interface VPN locale, indiquant les récepteurs locaux actifs. Le protocole, l’interface et le voisin en amont de ce point d’entrée vers le réseau MVPN de nouvelle génération. Les routeurs référencés dans cette rubrique sont présentés dans la section Présentation de la topologie de réseau MVPN nouvelle génération.

Utilisez la show pim join extensive instance vpna 224.1.1.1 commande pour vérifier que le routeur PE3 a l’état suivant dans sa base de données C-PIM :

L’entrée de transfert correspondant à l’entrée C-PIM sur le routeur PE du récepteur utilise la sous-interface de désencapsulation du tunnel multicast comme interface en amont.

Utilisez la show multicast route extensive instance vpna group 224.1.1.1 commande pour vérifier que le routeur PE3 a installé l’entrée de transfert multicast suivante pour le récepteur local :

Tunnels inclus : Configuration du LSP point à multipoint du routeur PE entrant

Le LSP point à multipoint et les sous-LSP associés sont signalés par le routeur PE entrant. Les informations relatives au LSP point à multipoint sont annoncées aux routeurs PE sortants dans l’attribut PMSI via BGP.

Le routeur PE entrant signale les sous-LSP point à multipoint en envoyant des messages de chemin RSVP point à multipoint vers les routeurs PE sortants. Le routeur PE entrant apprend l’identité des routeurs PE sortants à partir des routes de type 1 installées dans sa <routing-instance-name>.mvpn.0 table. Chaque message de chemin RSVP comporte un S2L_Sub_LSP objet avec l’objet de session point à multipoint. L’objet S2L_Sub_LSP porte une adresse IP de destination (sortie) sous-LSP de 4 octets.

Sous Junos OS, les sous-LSP associés à un LSP point à multipoint peuvent être signalés automatiquement par le système ou via une configuration de sous-LSP statique. Lorsqu’ils sont signalés automatiquement, le système choisit un nom pour le LSP point à multipoint et chaque sous-LSP qui lui est associé à l’aide de la convention de nommage suivante.

Convention de nommage des LSP point-à-multipoint :

< d’entrée PE rid> :<a par numéro unique VRF> :mvpn :<nom-instance-de-routage>

Convention de nommage des sous-LSP :

<egress PE rid> :<ingress PE rid> :<a par numéro unique VRF> :mvpn :<routing-instance-name>

Utilisez la show mpls lsp p2mp commande pour vérifier que les LSP suivants ont été créés par le routeur PE1 :

LSP P2MP parent : 10.1.1.1:65535 :mvpn :vpna

Sous-LSP : 10.1.1.2:10.1.1.1:65535 :mvpn :vpna (routeur PE1 vers routeur PE2) et

10.1.1.3:10.1.1.1:65535 :mvpn :vpna (routeur PE1 vers routeur PE3)

Les valeurs de cet exemple sont les suivantes :

• Nom LSP I-PMSI P2MP : 10.1.1.1:65535 :mvpn :vpna

• Nom du sous-LSP I-PMSI P2MP (vers PE2) : 10.1.1.2:10.1.1.1:65535 :mvpn :vpna

• Nom du sous-LSP I-PMSI P2MP (vers PE3) : 10.1.1.3:10.1.1.1:65535 :mvpn :vpna

Tunnels inclus : Configuration du LSP point à multipoint du routeur PE sortant

Un routeur PE de sortie répond à un message de chemin RSVP en émettant un message de réservation RSVP (RESV) conformément aux procédures normales de RSVP. Le message RESV contient l’étiquette MPLS allouée par le routeur PE de sortie pour ce sous-LSP et est transféré saut par saut vers le routeur PE d’entrée, ce qui permet de configurer l’état sur le réseau. Les routeurs référencés dans cette rubrique sont présentés dans la section Présentation de la topologie de réseau MVPN nouvelle génération.

Utilisez la show rsvp session commande pour vérifier que le routeur PE2 a attribué une étiquette 299840 pour le sous-LSP 10.1.1.2:10.1.1.1:65535:mvpn:vpna:

Utilisez la show mpls lsp p2mp commande pour vérifier que le routeur PE3 a attribué une étiquette 16 pour le sous-LSP 10.1.1.3:10.1.1.1:65535:mvpn:vpna:

Tunnels inclus : configuration du plan de données du routeur PE sortant

Le routeur PE de sortie installe une entrée de transfert dans sa mpls table pour l’étiquette qu’il a allouée au sous-LSP. L’étiquette MPLS est installée à l’aide d’une opération pop (une opération pop supprime l’étiquette MPLS supérieure) et le paquet est transmis à la table VRF pour une deuxième recherche de route. La deuxième recherche sur le routeur PE de sortie est nécessaire pour que les paquets de données multicast VPN soient traités à l’intérieur de la table VRF à l’aide des procédures C-PIM normales.

Utilisez la show route table mpls label 16 commande pour vérifier que le routeur PE3 a installé l’entrée d’étiquette suivante dans sa table de transfert MPLS :

Sous Junos OS, les entrées de routage de multicast VPN sont stockées dans la <routing-instance-name>.inet.1 table, où la deuxième recherche de route a lieu. Dans l’exemple ci-dessus, même si vpna.inet.0 est répertorié comme la table de routage où la deuxième recherche se produit après l’opération pop, en interne, la recherche est pointée vers la vpna.inet.1 table. Les routeurs référencés dans cette rubrique sont présentés dans la section Présentation de la topologie de réseau MVPN nouvelle génération.

Utilisez la show route table vpna.inet.1 commande pour vérifier que le routeur PE3 contient l’entrée suivante dans sa table de routage de multidiffusion VPN :

Utilisez la show multicast route extensive instance vpna commande pour vérifier que le routeur PE3 contient l’entrée de transfert de multicast VPN suivante correspondant à l’entrée de routage multicast pour la jointure locale. L’interface en amont pointe vers l’interface et l’interface en aval (OIL) pointe vers lsi.0 l’interface (vers les so-0/2/0.0 récepteurs locaux). La Upstream protocol valeur réside MVPN dans le fait que la source de multicast VPN est accessible via le réseau MVPN de nouvelle génération. L’interface lsi.0 est similaire à l’interface de tunnel multicast utilisée lorsque des tunnels fournisseur basés sur PIM sont utilisés. L’interface lsi.0 permet de supprimer l’en-tête MPLS supérieur.

L’exigence d’une double recherche de route sur l’en-tête du paquet VPN nécessite deux instructions de configuration supplémentaires sur les routeurs PE de sortie lorsque les tunnels fournisseur sont signalés par RSVP-TE.

Tout d’abord, étant donné que l’étiquette MPLS supérieure utilisée pour le sous-LSP point à multipoint est en fait liée à la table VRF sur les routeurs PE de sortie, l’opération d’éclatement par saut d’avant-dernier saut (PHP) n’est pas utilisée pour les MVPN de nouvelle génération. Seul le popping ultime-hop est utilisé. PHP permet à l’avant-dernier routeur (routeur avant le routeur PE sortant) de supprimer l’étiquette MPLS supérieure. PHP fonctionne bien pour les paquets de données unicast VPN car ils portent généralement deux étiquettes MPLS : une pour le VPN et une pour le LSP de transport.

Une fois l’étiquette LSP supprimée, les paquets VPN unicast ont toujours une étiquette VPN qui peut être utilisée pour déterminer le VPN auquel les paquets appartiennent. Les paquets de données multicast VPN, en revanche, ne portent qu’une seule étiquette MPLS directement liée au VPN. Par conséquent, l’étiquette MPLS portée par les paquets de multicast VPN doit être conservée jusqu’à ce que les paquets atteignent le routeur PE de sortie. Normalement, PHP doit être désactivé par une configuration manuelle.

Pour simplifier la configuration, PHP est désactivé par défaut sur les routeurs PE de Juniper Networks lorsque vous incluez l’instruction mvpn au niveau de la [edit routing-instances routing-interface-name interface] hiérarchie. PHP est également désactivé par défaut lorsque vous incluez l’instruction vrf-table-label au niveau de la [edit routing-instances routing-instance-name] hiérarchie.

Deuxièmement, sous Junos OS, les étiquettes VPN associées à une table VRF peuvent être allouées de deux manières.

• Attribuez une étiquette unique à chaque saut suivant du VPN (interface PE-CE). Il s’agit du comportement par défaut.

• Allouez une étiquette pour l’ensemble de la table VRF, ce qui nécessite une configuration supplémentaire. L’attribution d’une étiquette pour l’ensemble de la table VRF permet une deuxième recherche sur l’en-tête du paquet VPN. Par conséquent, les routeurs PE prenant en charge les services MVPN nouvelle génération doivent être configurés pour allouer des étiquettes à la table VRF. Il existe deux façons de le faire, comme illustré à la figure 1.

  • L’une d’entre elles consiste à inclure une interface de tunnel virtuel nommée vt au niveau de la [edit routing-instances routing-instance-name interfaces] hiérarchie, ce qui nécessite un PIC de tunnel.

  • La seconde consiste à inclure l’instruction vrf-table-label au niveau de la [routing-instances routing-instance-name] hiérarchie, ce qui ne nécessite pas de PIC de tunnel.

Ces deux options permettent à un routeur PE sortant d’effectuer deux recherches d’itinéraire. Cependant, il existe quelques différences dans la façon dont la deuxième recherche est effectuée

Si l’interface vt est utilisée, l’étiquette allouée est installée dans la mpls table avec une pop opération et un saut suivant de transfert pointant vers l’interface vt .

Utilisez la show route table mpls label 299840 commande pour vérifier que le routeur PE2 a installé l’entrée suivante et utilise une vt interface dans le mpls tableau. L’étiquette associée au sous-LSP point à multipoint (299840) est installée à l’aide d’une opération pop et d’une opération de transfert, l’interface vt-0/1/0.0 étant le saut suivant. Les paquets de multicast VPN reçus du cur quittent l’interface vt-0/1/0.0 sans leur en-tête MPLS, et le routeur de sortie PE2 effectue une deuxième recherche sur l’en-tête du paquet dans la vpna.inet.1 table.

Si le vrf-table-label est configuré, l’étiquette allouée est installée dans la mpls table avec une opération pop, et le transfert des entrées pointe vers la <routing-instance-name>.inet.0 table (ce qui déclenche en interne la deuxième recherche à effectuer dans la <routing-instance-name>.inet.1 table).

Utilisez la show route table mpls label 16 commande pour vérifier que le routeur PE3 a installé l’entrée suivante dans sa mpls table et utilise l’instruction vrf-table-label :

La configuration de l’attribution d’étiquettes pour chaque table VRF affecte à la fois les routes VPN unicast et MVPN. Toutefois, vous ne pouvez activer l’allocation d’étiquettes VRF pour les routes MVPN que si l’allocation par VRF est configurée via vt. Cette fonctionnalité est configurée via des mots-clés multicast et unicast au niveau de la [edit routing-instances routing-instance-name interface vt-x/y/z.0] hiérarchie.

Notez que l’inclusion de l’instruction active l’attribution d’étiquettes vrf-table-label VRF pour les routes unicast et MVPN et ne peut pas être désactivée pour l’un ou l’autre type de routes (elle est activée ou désactivée pour les deux).

Si un routeur PE est un routeur bud, c’est-à-dire qu’il possède des récepteurs locaux et transfère également des paquets MPLS reçus via un LSP point à multipoint en aval vers d’autres routeurs P et PE, alors il existe une différence dans le fonctionnement des vrf-table-label instructions and vt . Lorsque l’instruction vrf-table-label est incluse, le routeur Bud PE reçoit deux copies du paquet de l’avant-dernier routeur : l’une pour être transférée vers les récepteurs locaux et l’autre pour être transférée vers les routeurs P et PE en aval. Lorsque l’instruction vt est incluse, le routeur PE reçoit une seule copie du paquet.

Tunnels inclus : configuration du plan de données du routeur PE entrant et de branche

Sur le routeur PE entrant, les paquets de données VPN locaux sont encapsulés avec l’étiquette MPLS reçue du réseau pour les sous-LSP.

Utilisez la show rsvp session commande pour vérifier que sur le routeur PE1 entrant, les paquets de données multicast VPN sont encapsulés avec une étiquette 300016 MPLS (annoncée par le routeur P1 selon les procédures RSVP RESV normales) et transférés vers le routeur P1 via les 10.1.1.3:10.1.1.1:65535:mvpn:vpna sous-LSP et 10.1.1.2:10.1.1.1:65535:mvpn:vpna.

user@PE1> show rsvp session
Ingress RSVP: 2 sessions
To          From        State     Rt Style   Labelin   Labelout   LSPname
10.1.1.3   10.1.1.1 Up 0 1 SE         -      300016 
10.1.1.3:10.1.1.1:65535:mvpn:vpna
10.1.1.2 10.1.1.1   Up 0 1 SE         -      300016 
10.1.1.2:10.1.1.1:65535:mvpn:vpna
Total 2 displayed, Up 2, Down 0

Egress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

La RFC 4875 décrit un nœud de branche comme « un LSR qui réplique les données entrantes sur une ou plusieurs interfaces sortantes ». Sur un Rrouter de filiale, les données entrantes portant une étiquette MPLS sont répliquées sur une ou plusieurs interfaces sortantes qui peuvent utiliser différentes étiquettes MPLS. Les nuds de branche assurent le suivi des étiquettes entrantes et sortantes associées aux LSP point à multipoint. Les routeurs référencés dans cette rubrique sont présentés dans Présentation de la topologie de réseau MVPN nouvelle génération.

Utilisez la show rsvp session commande pour vérifier que le nœud de branche P1 possède l’étiquette 300016 entrante et les étiquettes 16 sortantes pour le sous-LSP 10.1.1.3:10.1.1.1:65535:mvpn:vpna (vers le routeur PE3) et 299840 pour le sous-LSP 10.1.1.2:10.1.1.1:65535:mvpn:vpna (vers le routeur PE2).

Utilisez la show route table mpls label 300016 commande pour vérifier que l’entrée de transfert correspondante sur le routeur P1 indique que les paquets entrants avec une étiquette MPLS (300016) sont échangés avec des étiquettes 16 et 299840 transférés via leurs interfaces respectives (so-0/0/3.0 et so-0/0/1.0 respectivement vers les routeurs PE2 et PE3).

Tunnels sélectifs : Routes de découverte automatique S-PMSI de type 3 et Routes de découverte automatique Leaf de type 4

Les tunnels de fournisseurs sélectifs sont configurés en incluant l’instruction selective au niveau de la [edit routing-instances routing-instance-name provider-tunnel] hiérarchie. Vous pouvez configurer un seuil pour déclencher la signalisation d’un tunnel de fournisseur sélectif. L’inclusion de l’instruction selective déclenche les événements suivants.

Tout d’abord, le routeur PE entrant est à l’origine d’une route de découverte automatique S-PMSI de type 3. La route de découverte automatique S-PMSI contient le distinguateur de route du VPN où le tunnel est configuré et de la paire (C-S, C-G) qui utilise le tunnel de fournisseur sélectif.

Dans cette section, supposons que le routeur PE1 signale un tunnel sélectif pour (192.168.1.2, 224.1.1.1) et que le routeur PE3 dispose d’un récepteur actif.

Utilisez la show route table vpna.mvpn.0 | find 3: commande pour vérifier que le routeur PE1 a installé la route de type 3 suivante après la configuration du tunnel de fournisseur sélectif :

Deuxièmement, le routeur PE entrant attache un attribut PMSI à une route de type 3. Cet attribut PMSI est similaire à l’attribut PMSI annoncé pour les tunnels de fournisseur inclusifs, à une différence près : le bit de l’attribut PMSI transporté avec les routes de type 3 est Flags défini sur Leaf Information Required. Cela signifie que le routeur PE émetteur demande aux routeurs PE récepteurs d’envoyer une route de type 4 s’ils ont des récepteurs actifs pour le (C-S, C-G) transporté dans la route de type 3. N’oubliez pas non plus que pour chaque tunnel de fournisseur sélectif, un nouveau point à multipoint et les sous-LSP associés sont signalés. L’attribut PMSI d’un itinéraire de type 3 contient des informations sur le nouveau LSP point à multipoint.

Utilisez la show route advertising-protocol bgp 10.1.1.3 detail table vpna.mvpn | find 3: commande pour vérifier que le routeur PE1 annonce la route de type 3 suivante et l’attribut PMSI . L’objet de session point à multipoint inclus dans l’attribut PMSI a un numéro de port () différent de29499 celui utilisé pour le tunnel inclusif (6574), ce qui indique qu’il s’agit d’un nouveau tunnel point à multipoint.

Les routeurs PE de sortie avec des récepteurs actifs doivent répondre à une route de type 3 en initiant une route de découverte automatique de feuilles de type 4. Une route de découverte automatique leaf contient une clé de route et les champs d’adresse IP du routeur d’origine. Le Route Key champ de l’itinéraire d’autodécouverte leaf contient l’itinéraire de type 3 d’origine reçu. Le champ d’adresse IP du routeur d’origine est défini sur l’ID de routeur du routeur PE à l’origine de l’itinéraire de découverte automatique de la branche.

Le routeur PE entrant ajoute chaque routeur PE sortant à l’origine de l’itinéraire d’autodécouverte leaf en tant que leaf (destination du sous-LSP pour le LSP sélectif point à multipoint). De même, le routeur PE de sortie à l’origine de la route de découverte automatique leaf configure l’état de transfert pour commencer à recevoir des données via le tunnel de fournisseur sélectif.

Les routeurs PE de sortie annoncent des routes de type 4 avec une cible de route spécifique au routeur PE signalant le tunnel de fournisseur sélectif. Cette cible de route se présente sous la forme de target :<rid de l’émetteur PE> :0. Le routeur PE émetteur (le routeur PE signalant le tunnel du fournisseur sélectif) applique une stratégie d’importation interne spéciale aux routes de type 4 qui recherche une cible de route avec son propre ID de routeur. Les routeurs référencés dans cette rubrique sont présentés dans Présentation de la topologie du réseau MVPN nouvelle génération.

Utilisez la show route table vpna.mvpn | find 4:3: commande pour vérifier que le routeur PE3 provient de la route de type 4 suivante. La route locale de type 4 est installée par le module MVPN.

Utilisez la show route advertising-protocol bgp 10.1.1.1 table vpna.mvpn detail | find 4:3: commande pour vérifier que le routeur PE3 a annoncé la route de type 4 locale avec la communauté cible de route suivante. Cette cible de route porte l’adresse IP du routeur PE émetteur (10.1.1.1) suivie d’un 0.

Utilisez la show policy __vrf-mvpn-import-cmcast-leafAD-global-internal__ commande pour vérifier que le routeur PE1 (le routeur PE signalant le tunnel du fournisseur sélectif) a appliqué la stratégie d’importation suivante aux routes de type 4. Les routes sont acceptées si leur cible de route correspond à target:10.1.1.1:0.

Pour chaque tunnel de fournisseur sélectif configuré, une route de type 3 est annoncée et un nouveau LSP point à multipoint est signalé. Les LSP point à multipoint créés par Junos OS pour des tunnels de fournisseur sélectifs sont nommés selon les conventions de nommage suivantes :

• Convention de nommage sélectif des LSP point à multipoint :

  <Ingress PE rid> :<a par numéro unique VRF> :mv<un numéro unique> :<nom-instance-de-routage>

• Convention de nommage sélectif des sous-LSP point à multipoint :

  <egress PE rid> :<ingress PE rid> :<a par VRF unique> :mv<a unique number> :<routing-instance-name>

Utilisez la show mpls lsp p2mp commande pour vérifier que le routeur PE1 signale un LSP 10.1.1.1:65535:mv5:vpna point à multipoint avec un sous-LSP 10.1.1.3:10.1.1.1:65535:mv5:vpna. Le premier LSP 10.1.1.1:65535:mvpn:vpna point-à-multipoint est le LSP créé pour le tunnel inclusif.

Les valeurs de cet exemple sont les suivantes.

• Nom LSP I-PMSI P2MP : 10.1.1.1:65535 :mvpn :vpna

• Nom du sous-LSP I-PMSI P2MP (vers PE2) : 10.1.1.2:10.1.1.1:65535 :mvpn :vpna

• Nom du sous-LSP I-PMSI P2MP (vers PE3) : 10.1.1.3:10.1.1.1:65535 :mvpn :vpna

• Nom LSP S-PMSI P2MP : 10.1.1.1:65535 :mv5 :vpna

• Nom du sous-LSP S-PMSI P2MP (vers PE3) : 10.1.1.3:10.1.1.1:65535 :mv5 :vpna