Signalisation intrabande MULTICAST de nouvelle génération (VRF MLDP : Profil 6)
Contenu
Introduction
Ce document décrit le protocole MLDP VRF de signalisation intrabande qui est le profil 6 pour la multidiffusion de nouvelle génération sur VPN (mVPN). Il utilise un exemple et la mise en oeuvre dans Cisco IOS afin d'illustrer le comportement.
Informations générales
Signalisation MLDP (Multicast Label Distribution Protocol) en bande pour permettre au coeur MLDP de créer un état (S, G) ou (*, G) sans utiliser de signalisation hors bande, comme le protocole BGP (Border Gateway Protocol) ou le protocole PIM (Protocol Independent Multicast).
Le VPN de multidiffusion (MVPN) pris en charge par MLDP permet d'agréger les flux de multidiffusion VPN sur une arborescence spécifique au VPN.
Aucun état client n'est créé dans le coeur du protocole MLDP. Il existe le seul état pour les arborescences de distribution de multidiffusion de données (MDT) et par défaut.
Dans certains scénarios, l'état créé pour les flux VPN est limité et ne semble pas être un facteur de risque ou de limitation. Dans ces scénarios, le protocole MLDP peut créer des MDT intrabande qui sont des LSP de transit.
Les arbres utilisés dans un espace VPN sont des MDT. Les arbres utilisés dans la table globale sont des LSP point à multipoint de transit (P2MP) ou multipoint (MP2MP).
Dans les deux cas, un seul flux de multidiffusion (VPN ou non) est associé à un seul LSP dans le coeur MPLS. Les informations de flux sont codées dans la classe d'équivalence de transfert (FEC) du LSP. Il s'agit d'une signalisation intrabande.
LSM offre des avantages par rapport aux tunnels principaux GRE actuellement utilisés pour le transport du trafic client dans le coeur et il exploite l'infrastructure MPLS pour le transport des paquets de multidiffusion IP, fournissant un plan de données commun pour la monodiffusion et la multidiffusion.
Signalisation MLDP
La signalisation MLDP offre deux fonctions :
- Pour découvrir la FEC (et sa valeur opaque associée) pour un LSP MP
- Pour affecter un flux de multidiffusion à un LSP MP
Signalisation intrabande
- La valeur opaque est utilisée pour mapper un LSP MP à un flux de multidiffusion IP.
- Le contenu de la valeur opaque provient du flux de multidiffusion.
Signalisation superposée ou hors bande
- Utilise un protocole de superposition pour mapper un LSP MP à un flux de multidiffusion IP.
- Une valeur opaque peut être attribuée par le PE racine d'entrée ou configurée de manière statique.
- MP LSP est créé à la demande ou peut être préconfiguré.
- Permet d'agréger des flux de multidiffusion sur un seul LSP MP.
Protocole LDP (Label Distribution Protocol) FEC (Label Distribution Protocol) # RFC5918
L'élément FEC générique typé fait référence à tous les FEC du type spécifié qui répondent à la contrainte. Il spécifie un 'type d'élément FEC' et une contrainte facultative, qui est destinée à fournir des informations supplémentaires.
Le format de l'élément FEC générique typé est le suivant :
Caractère générique saisi : Type d'élément FEC d'un octet (0x05).
LDP [RFC5036] distribue des étiquettes pour les classes d'équivalence de transfert (FEC). Le protocole LDP utilise des TLV FEC dans les messages LDP pour spécifier des FEC.
Un TLV FEC LDP inclut un ou plusieurs éléments FEC. Un élément FEC inclut un type FEC et une valeur facultative dépendante du type.
La RFC 5036 spécifie deux types FEC (préfixe et caractères génériques) et d'autres documents spécifient des types FEC supplémentaires ; par exemple, voir [RFC4447] et [MLDP].
Comme spécifié par RFC 5036, l'élément FEC générique fait référence à tous les FEC par rapport à une contrainte facultative.
La seule contrainte RFC 5036 spécifie celle qui limite la portée de l'élément FEC générique à « tous les FEC liés à une étiquette donnée ».
La spécification RFC 5036 de l'élément FEC générique présente les lacunes suivantes qui limitent son utilité :
- L'élément FEC générique n'est pas tapé. Dans certaines situations, il serait utile de pouvoir faire référence à tous les FEC d'un type donné (comme autre contrainte).
- L'utilisation de l'élément FEC générique est limitée aux messages de retrait d'étiquette et de libération d'étiquette. Dans certains cas, il serait utile d'avoir un élément FEC générique, avec contrainte de type, dans les messages de demande d'étiquette.
Topologie
Signalisation de superposition
Configuration
Étape 1. Activez MPLS MLDP dans les noeuds principaux.
# mpls mldp logging
Étape 2. Activez la SIGNALISATION INBANDE MLDP dans CORE.
Sur PE1, PE2 et PE3
# ip multicast vrf INBAND-MLDP mpls mldp
# ip pim vrf INBAND-MLDP mpls source loopback 0
Étape 3. Activez PIM SM dans toutes les interfaces CE et l'interface PE VRF.
Sur CE1, CE2, CE3 et toutes les interfaces VRF PE1, PE2 et PE3
# interface x/x
# ip pim sparse-mode
# interface loopback x/x
# ip pim sparse-mode
Étape 4. Activez la multidiffusion dans le VRF.
Sur PE1, PE2 et PE3
# ip multicast-routing vrf INBAND-MLDP
Étape 5. Activez VRF sur l'interface PE-CE x/x du routeur PE.
# interface x/x
# ip vrf forwarding INBAND-MLDP
Étape 6. Configurer le mode SSM dans les noeuds CE et PE (VRF uniquement).
Sur les noeuds CE
# ip pim ssm default
Sur PE1, PE2, PE3 sous VRF
# ip pim vrf INBAND-MLDP ssm default
Étape 7. Configurez le groupe IGMP SSM 232.1.1.1 (récepteur).
Sur les récepteurs 2 et 3
CE #interface x/x
# ip pim join-group 232.1.1.1 source 10.1.0.2
Vérification
IGP, MPLS LDP, BGP s'exécute parfaitement sur notre réseau de bout en bout.
Dans cette section, la vérification est effectuée pour vérifier la contiguïté AF VPN dans le réseau principal/d'agrégation. La contiguïté est vérifiée entre CE-PE et le plan de contrôle est également vérifié avec le plan de données pour le trafic VPN sur le réseau MPLS.
Pour vérifier que les périphériques de périphérie client (CE) locaux et distants peuvent communiquer sur le coeur de réseau MPLS (Multiprotocol Label Switching), procédez comme suit :
Tâche 1 : vérification de la connectivité physique
- Vérifiez que toutes les interfaces connectées sont ACTIVÉES.
Tâche 2 : Vérifiez la monodiffusion VPNv4 de la famille d'adresses BGP.
- Vérifiez que BGP est activé sur tous les routeurs pour la monodiffusion AF VPNv4 et que les voisins BGP sont UP.
- Vérifiez que la table de monodiffusion VPNv4 BGP contient tous les préfixes du client.
Tâche 3 : Vérifier le trafic multidiffusion de bout en bout
- Vérifiez le voisinage PIM avec le voisin PIM connecté.
- Vérifiez que l'état de multidiffusion est créé dans le VRF.
Sur l'entrée mRIB PE VRF sur PE1, PE2 et PE3
- Vérifiez que l'entrée VRF (S, G) mFIB est activée, et que le paquet est incrémenté dans le transfert logiciel.
- Vérifier que les paquets ICMP atteignent l'interface CE à CE.
Tâche 4 : Vérifiez le COEUR MPLS.
- Vérifiez le coeur LSP MPLS.
- Vérifiez le transfert MPLS à l'intérieur du coeur de réseau, conformément à la conception.
- Vérifiez que la requête ping MPLS P2MP LSP fonctionne.
Comment créer un plan de contrôle ?
Vérifiez le plan de contrôle que l'imposition d'étiquette se produit lorsque le routeur PE transfère en fonction de l'en-tête IP et ajoute une étiquette MPLS au paquet lors de l'entrée dans un réseau MPLS.
Dans la direction de l'imposition de l'étiquette, le routeur commute les paquets en fonction d'une recherche dans une table CEF pour trouver le saut suivant et ajoute les informations d'étiquette appropriées stockées dans la FIB pour la destination. Lorsqu’un routeur effectue un échange d’étiquettes dans le coeur d’un paquet MPLS, il effectue une recherche dans la table MPLS. Le routeur déduit cette table MPLS (LFIB) à partir des informations de la table CEF et de la base d'informations d'étiquette (LIB).
La disposition d'étiquette se produit lorsque le routeur PE reçoit un paquet MPLS, prend une décision de transfert basée sur l'étiquette MPLS, supprime l'étiquette et envoie un paquet IP. Le routeur PE utilise la LFIB pour déterminer le chemin d’un paquet dans cette direction.Comme indiqué précédemment, une session iBGP spéciale facilite l’annonce des préfixes VPNv4 et de leurs étiquettes entre les routeurs PE. Au niveau du PE publicitaire, BGP alloue des étiquettes pour les préfixes VPN appris localement et les installe dans la LFIB, qui est la table de transfert MPLS.
Étape 1. Une fois que vous avez configuré le protocole MLDP dans le coeur de réseau. Ces messages échangent.
MLDP: P2MP Wildcard label request sent to 11.11.11.11:0 success MLDP: MP2MP Wildcard label request sent to 11.11.11.11:0 success MLDP-MFI: Enabled MLDP MFI client on Lspvif0; status = ok LDP Peer 11.11.11.11:0 re-announced MLDP-NBR: 11.11.11.11:0 UP sess_hndl: 1, (old ID: 0.0.0.0:0) mLDP-RW: Sending RW notification message to process: mLDP Process mLDP-RW: RW Tracking started for: 11.11.11.11 MLDP-LDP: [id 0] Wildcard label request from: 11.11.11.11:0 label: 0 root: 6.2.0.0 Opaque_len: 0 sess_hndl: 0x1 MLDP-LDP: [id 0] Wildcard label request from: 11.11.11.11:0 label: 0 root: 8.2.0.0 Opaque_len: 0 sess_hndl: 0x1 Neighbor 11.11.11.11 request for the label request to PE1.
Utilisez ce débogage pour vérifier l'établissement précédent :
# debug mpls mldp all
Étape 2. Activez la SIGNALISATION INBANDE dans VRF.
PE1 # Config t # ip pim vrf MLDP-INBAND mpls source loopback 0 # ip multicast vrf MLDP-INBAND mpls mldp MLDP: Enabled IPv4 on Lspvif0 unnumbered with Loopback0 MLDP-MFI: Enable lsd on int failed; not registered; MLDP: Enable pim on lsp vif: Lspvif0 MLDP: Add success lsp vif: Lspvif0 address: 0.0.0.0 application: MLDP vrf_id: 1 MLDP-DB: Replaying database events for opaque type value: 250 %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to up PIM(1): Check DR after interface: Lspvif0 came up! PIM(1): Changing DR for Lspvif0, from 0.0.0.0 to 1.1.1.1 (this system) %PIM-5-DRCHG: VRF MLDP-INBAND: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Lspvif0 Use this Debug to check the preceding establishment # debug ip pim vrf LDP-INBAND6 PE1#sh interfaces lspvif 0 Lspvif0 is up, line protocol is up Hardware is Interface is unnumbered. Using address of Loopback0 (1.1.1.1) MTU 17940 bytes, BW 8000000 Kbit/sec, DLY 5000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation LOOPBACK, loopback not set
Lorsque le récepteur est mis en ligne :
Le récepteur 3 est en ligne et envoie les messages PIM JOIN (S, G) à PE3.
PIM(1): Received v2 Join/Prune on Ethernet0/2 from 10.2.0.2, to us PIM(1): Join-list: (10.1.0.2/32, 232.1.1.1), S-bit set MRT(1): Create (*,232.1.1.1), RPF (unknown, 0.0.0.0, 2147483647/0) MLDP: Interface Lspvif1 moved from VRF (default) to VRF MLDP-INBAND MLDP: Enabled IPv4 on Lspvif1 unnumbered with Loopback0 MLDP-MFI: Enabled MLDP MFI client on Lspvif1; status = ok MRT(1): Add interface Lspvif1 MLDP: Enable pim on lsp vif: Lspvif1 MLDP: Add success lsp vif: Lspvif1 address: 1.1.1.1 application: MLDP vrf_id: 1 MLDP: LDP root 1.1.1.1 added mLDP-RW: Sending RW notification message to process: mLDP Process mLDP-RW: RW Tracking started for: 1.1.1.1 MLDP: Route watch started for 1.1.1.1 topology: base ipv4 MLDP-DB: Added [vpnv4 10.1.0.2 232.1.1.1 1:1] DB Entry MLDP-DB: [vpnv4 10.1.0.2 232.1.1.1 1:1] Added P2MP branch for MRIBv4(1) label %MLDP-5-ADD_BRANCH: [vpnv4 10.1.0.2 232.1.1.1 1:1] Root: 1.1.1.1, Add P2MP branch MRIBv4(1) remote label MLDP: nhop 10.0.2.2 added MLDP-NBR: 11.11.11.11:0 mapped to next_hop: 10.0.2.2 MLDP: Root 1.1.1.1 old paths: 0 new paths: 1 MLDP-DB: [vpnv4 10.1.0.2 232.1.1.1 1:1] Changing peer from none to 11.11.11.11:0 MLDP-DB: [vpnv4 10.1.0.2 232.1.1.1 1:1] Add accepting element nbr: 11.11.11.11:0 MLDP: [vpnv4 10.1.0.2 232.1.1.1 1:1] label mappping msg sent to 11.11.11.11:0 success MLDP-DB: [vpnv4 10.1.0.2 232.1.1.1 1:1] path to peer: 11.11.11.11:0 changed None:0.0.0.0 to Ethernet0/3:10.0.2.2
Toute communication de Receiver (S, G) Join sera convertie en MLDP et tous les messages seront acheminés vers Lspvif 1
Avec PIM JOIN (S, G) comme MLDP est un protocole piloté par le récepteur, il commence à créer la base de données MLDP du récepteur à la source. Il s'agit de l'allocation d'étiquette en aval pour le protocole MLDP P2MP.
MLDP P2MP
Le transport de paquets P2MP est mis en oeuvre à l'aide du protocole RSVP (Resource Reservation Protocol) P2MP - Traffic Engineering (P2MP-TE) et le transport de paquets M2M sont mis en oeuvre via le VPN multidiffusion IPv4 (MVPN) à l'aide du protocole MLDP (Multicast Label Distribution Protocol).
Le paquet est transporté sur trois types de routeurs :
· routeur de tête de réseau : Encapsule le paquet IP avec une ou plusieurs étiquettes.
· routeur de point médian : Remplace l'étiquette interne par une étiquette externe.
· routeur de destination : Supprime l'étiquette du paquet.
Flux de paquets dans un réseau MVPN basé sur MLDP Pour chaque paquet entrant, MPLS crée plusieurs étiquettes sortantes. Les paquets du réseau source sont répliqués le long du chemin vers le réseau récepteur. Le routeur CE1 envoie le trafic de multidiffusion IP natif. Le routeur PE1 impose une étiquette sur le paquet de multidiffusion entrant et réplique le paquet étiqueté vers le réseau principal MPLS. Lorsque le paquet atteint le routeur principal (P), il est répliqué avec les étiquettes appropriées pour le MDT par défaut MP2MP ou le MDT de données P2MP et transporté vers tous les PE de sortie. Une fois que le paquet atteint le PE de sortie, l'étiquette est supprimée et le paquet de multidiffusion IP est répliqué sur l'interface VRF
PE1#sh mpls mldp database * For interface indicates MLDP recursive forwarding is enabled * For RPF-ID indicates wildcard value > Indicates it is a Primary MLDP MDT Branch LSM ID : 1 Type: P2MP Uptime : 00:23:11 FEC Root : 1.1.1.1 (we are the root) Opaque decoded : [vpnv4 10.1.0.2 232.1.1.1 1:1] Opaque length : 16 bytes Opaque value : FA 0010 0A010002E80101010000000100000001 Upstream client(s) : None Expires : N/A Path Set ID : 1 Replication client(s): 11.11.11.11:0 Uptime : 00:23:11 Path Set ID : None Out label (D) : 21 Interface : Ethernet0/1* Local label (U): None Next Hop : 10.0.1.2 RR-P#sh mpls mldp database * For interface indicates MLDP recursive forwarding is enabled * For RPF-ID indicates wildcard value > Indicates it is a Primary MLDP MDT Branch LSM ID : 2 Type: P2MP Uptime : 00:28:12 FEC Root : 1.1.1.1 Opaque decoded : [vpnv4 10.1.0.2 232.1.1.1 1:1] Opaque length : 16 bytes Opaque value : FA 0010 0A010002E80101010000000100000001 Upstream client(s) : 1.1.1.1:0 [Active] Expires : Never Path Set ID : 2 Out Label (U) : None Interface : Ethernet0/1* Local Label (D): 21 Next Hop : 10.0.1.1 Replication client(s): 3.3.3.3:0 Uptime : 00:28:12 Path Set ID : None Out label (D) : 26 Interface : Ethernet0/2* Local label (U): None Next Hop : 10.0.3.1 2.2.2.2:0 Uptime : 00:24:41 Path Set ID : None Out label (D) : 25 Interface : Ethernet0/3* Local label (U): None Next Hop : 10.0.2.1 RR-P#sh mpls forwarding-table labels 21 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 21 26 [vpnv4 10.1.0.2 232.1.1.1 1:1] \ 0 Et0/2 10.0.3.1 25 [vpnv4 10.1.0.2 232.1.1.1 1:1] \ 0 Et0/3 10.0.2.1
MRIB créé sur les périphériques PE :
PE1#sh ip mroute vrf MLDP-INBAND 232.1.1.1 verbose IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet, U - URD, I - Received Source Specific Host Report, (10.1.0.2, 232.1.1.1), 00:00:17/00:02:42, flags: sTI Incoming interface: Ethernet0/2, RPF nbr 10.1.0.2 Outgoing interface list: Lspvif0, LSM ID: 1, Forward/Sparse, 00:00:17/00:02:42
Lorsque Source commence la diffusion en continu :
Lorsque la source de multidiffusion commence à envoyer du trafic, [10.1.0.2, 232.1.1.1] se produit comme indiqué dans cette image.
Trafic provenant de la source 10.1.0.2 en continu à partir de 232.1.1.1. Passe par Ethernet0/2.
Le paquet a été transféré via Lspvif 0.
PIM(0): Insert (10.1.0.2,232.1.1.1) join in nbr 10.1.0.2's queue PIM(0): Building Join/Prune packet for nbr 10.1.0.2 PIM(0): Adding v2 (10.1.0.2/32, 232.1.1.1), S-bit Join PIM(0): Send v2 join/prune to 10.1.0.2 (Ethernet0/2) MFIBv4(0x0): Pkt (10.1.0.2,232.1.1.1) from Ethernet0/2 (FS) accepted for forwarding MFIBv4(0x0): Pkt (10.1.0.2,232.1.1.1) from Ethernet0/2 (FS) sent on Lspvif0, LSM NBMA/4
Ce paquet est tunnelisé dans le Lspvif 0.
Côté récepteur :
Du côté du récepteur, le paquet atteint au niveau de Lspvif 1.
MFIBv4(0x0): Pkt (10.1.0.2,232.1.1.1) from Lspvif1 (FS) accepted for forwarding MFIBv4(0x0): Pkt (10.1.0.2,232.1.1.1) from Lspvif1 (FS) sent on Ethernet0/0 PIM(0): Received v2 Join/Prune on Ethernet0/0 from 10.3.0.2, to us PIM(0): Join-list: (10.1.0.2/32, 232.1.1.1), S-bit set PIM(0): Update Ethernet0/0/10.3.0.2 to (10.1.0.2, 232.1.1.1), Forward state, by PIM SG Join
Lorsque le paquet atteint le PE1, il vérifie l'ID LSM pour transférer le trafic, qui est étiqueté à imposer dans le paquet multidiffusion.
Cette image montre la vérification de l'interface LSPVIF.
Pour chaque paquet entrant, MPLS crée plusieurs étiquettes sortantes. Les paquets du réseau source sont répliqués le long du chemin vers le réseau récepteur. Le routeur CE1 envoie le trafic de multidiffusion IP natif. Le routeur PE1 impose une étiquette sur le paquet de multidiffusion entrant et réplique le paquet étiqueté vers le réseau principal MPLS.
Lorsque le paquet atteint le routeur principal (P), il est répliqué avec les étiquettes appropriées pour le MDT par défaut MP2MP ou le MDT de données P2MP et transporté vers tous les PE de sortie. Une fois que le paquet atteint le PE de sortie, l'étiquette est supprimée et le paquet de multidiffusion IP est répliqué sur l'interface VRF.
Conclusion
La configuration MLDP MVPN active la distribution de paquets de multidiffusion IPv4 à l'aide de MPLS. Cette configuration utilise des étiquettes MPLS pour construire les arbres de distribution multidiffusion (MDT) par défaut et de données.
La réplication MPLS est utilisée comme mécanisme de transfert dans le réseau principal. Pour que la configuration MLDP MVPN fonctionne, assurez-vous que la configuration MLDP MPLS globale est activée.
Commentaires