Profil 0
Profil 1
Profil 3
Profil 11
Comme nous l'avons appris des entrées précédentes, dans le backbone lors de l'implémentation de mVPN, il y a toujours une construction MDT par défaut, à laquelle tous les routeurs PE sont connectés. Les messages de service PIM (par exemple, Bootstrap, Auto-RP) ainsi que le trafic multicast personnalisé sont acheminés dans ce MDT. En conséquence, il s'avère que certains appareils PE reçoivent même le trafic auquel ils ne sont pas abonnés.
Si vous voulez savoir comment gérer cela, bienvenue sous le chat!
Afin d'améliorer l'efficacité du transfert de données, une construction supplémentaire est utilisée, appelée "Data MDT". L'idée derrière cela est la suivante:
- Dans l'arborescence, seul le trafic C- (S, G) est distribué
- Seuls les PE de sortie qui ont des destinataires intéressés deviennent membres de l'arborescence
- Le périphérique MDT de données racine est le PE d'entrée (le routeur derrière lequel se trouve la source)
Visuellement, cela ressemble Ă ceci:
Si nous imaginons une situation dans laquelle la source commence à diffuser vers le deuxième groupe de multidiffusion (230.1.1.2), pour lequel les récepteurs sont situés uniquement derrière PE2 et PE3, alors un Data MDT supplémentaire est créé et l'image globale prend la forme (MDT par défaut est omis):
La signalisation pour la commutation du trafic de MDT par défaut vers Data MDT est effectuée exclusivement à la demande lorsqu'un seuil prédéterminé est dépassé par le PE d'entrée soit au moyen de PIM, soit au moyen de BGP.
Données MDT utilisant PIM
Si PIM est utilisé pour la signalisation, le PE d'entrée génère un message spécial PIM Data-MDT TLV et l'envoie dans le cadre du MDT par défaut pour garantir que tous les PE peuvent recevoir le message. Simultanément à l'envoi du Data MDT TLV, Ingress PE démarre un temporisateur égal à trois secondes. Après l'expiration du temporisateur, tous les paquets seront transmis dans Data MDT.
Il convient également de noter que les informations contenues dans le TLV Data-MDT sont mises en cache sur tous les PE. La raison en est assez triviale - même s'il n'y a pas de destinataires de trafic intéressés sur un PE particulier pour le moment, ils peuvent y apparaître après un certain temps. En conséquence, lors de la réception d'une jointure PIM (dans le C-VRF), le PE peut instantanément se connecter au Data MDT déjà existant sur le réseau.
Environ. Les TLV Data-MDT sont transmis une fois par minute.
Chaque MDT de données est défini pour une route distincte (S, G) dans le VPN / VRF. L'administrateur doit spécifier explicitement le nombre maximal de MDT de données pouvant être générés sur l'appareil. Si, à un moment donné, le nombre d'arbres nouvellement installés atteint la limite spécifiée, les arbres suivants réutiliseront ceux déjà installés.
Environ. Au moment d'écrire ces lignes, Cisco IOS ne prend pas en charge la signalisation PIM sur Data MDT. Tous les profils avec cette alarme sont disponibles uniquement sur le système d'exploitation IOS XR.
Data MDT avec BGP
Lors de l'utilisation de BGP dans un réseau de superposition pour la signalisation Data MDT, les principes de base restent les mêmes (par rapport au PIM):
- d'entrée des signaux PE à tous les PE que le trafic pour C- (S, G) sera transmis dans Data MDT
- egress PE, à la réception d'une mise à jour BGP, rejoint l'arbre spécifié
- la famille d'adressage mVPN (sAFI 129) est utilisée pour la signalisation.
Il s'avère que le PE Ingress doit former un message de mise à jour BGP spécial et l'envoyer à tous les PE du mVPN. Pour cela, une route du troisième type est utilisée.
Profil 14
Considérons la transition décrite en utilisant l'exemple de notre laboratoire. En particulier, la configuration dite «Profil 14» est applicable. Ce profil est caractérisé par l'utilisation de BGP mVPN AD pour construire des LSP P2MP MLDP.
Sur PE, nous utiliserons le modèle de configuration suivant:
ip vrf C-ONE mdt auto-discovery mldp mdt partitioned mldp p2mp mdt overlay use-bgp mdt strict-rpf interface ! router bgp 1 address-family ipv4 mvpn neighbor 8.8.8.8 activate neighbor 8.8.8.8 send-community extended exit-address-family
Environ. nous
mdt strict-rpf
parlerons de l 'objectif de la commande interface dans le prochain numéro.
DĂ©couverte automatique
Voyons ce qui se passe sur PE1:
Sur chaque PE, une interface Lspvif0 est créée, sur laquelle C-PIM est activé.
*Dec 3 10:04:54.450: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to up
Il n'y a pas de voisins pour le moment:
PE1#show ip pim vrf C-ONE int Address Interface Ver/ Nbr Query DR DR Mode Count Intvl Prior 172.1.11.1 GigabitEthernet2.111 v2/S 1 30 1 172.1.11.11 172.1.15.1 GigabitEthernet2.115 v2/S 1 30 1 172.1.15.15 1.1.1.1 Lspvif0 v2/S 0 30 1 1.1.1.1
Voyons la table BGP:
PE1#show bgp ipv4 mvpn all BGP table version is 39, local router ID is 1.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, t secondary path, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1.1.1.1:1 (default for vrf C-ONE) *> [1][1.1.1.1:1][1.1.1.1]/12 0.0.0.0 32768 ? *>i [1][1.1.1.1:1][2.2.2.2]/12 2.2.2.2 0 100 0 ? *>i [1][1.1.1.1:1][3.3.3.3]/12 3.3.3.3 0 100 0 ? *>i [1][1.1.1.1:1][4.4.4.4]/12 4.4.4.4 0 100 0 ? Route Distinguisher: 2.2.2.2:1 *>i [1][2.2.2.2:1][2.2.2.2]/12 2.2.2.2 0 100 0 ? Route Distinguisher: 3.3.3.3:1 Network Next Hop Metric LocPrf Weight Path *>i [1][3.3.3.3:1][3.3.3.3]/12 3.3.3.3 0 100 0 ? Route Distinguisher: 4.4.4.4:1 *>i [1][4.4.4.4:1][4.4.4.4]/12 4.4.4.4 0 100 0 ? Route Distinguisher: 1.1.1.1:1 (default for vrf C-ONE) *> [3][1.1.1.1:1][*][*][1.1.1.1]/14 0.0.0.0 32768 ? *>i [3][1.1.1.1:1][*][*][2.2.2.2]/14 2.2.2.2 0 100 0 ? *>i [3][1.1.1.1:1][*][*][3.3.3.3]/14 3.3.3.3 0 100 0 ? *>i [3][1.1.1.1:1][*][*][4.4.4.4]/14 4.4.4.4 0 100 0 ? *> [3][1.1.1.1:1][*][224.0.0.13][1.1.1.1]/18 0.0.0.0 32768 ? Route Distinguisher: 2.2.2.2:1 *>i [3][2.2.2.2:1][*][*][2.2.2.2]/14 2.2.2.2 0 100 0 ? Route Distinguisher: 3.3.3.3:1 *>i [3][3.3.3.3:1][*][*][3.3.3.3]/14 3.3.3.3 0 100 0 ? Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 4.4.4.4:1 *>i [3][4.4.4.4:1][*][*][4.4.4.4]/14 4.4.4.4 0 100 0 ?
Comme vous pouvez le voir, en plus des routes du premier type déjà considérées précédemment, les routes du troisième type S-PMSI AD sont ajoutées, qui sont utilisées pour annoncer PE en tant que routeur d'entrée pour un groupe C- (S, G) spécifique. Pour le moment, le groupe est (*, *). Cela indique la volonté de PE de participer à la construction de MDT partitionné.
Évidemment, pour que le transfert de données fonctionne, les informations de point de rendez-vous doivent être connues dans le VRF. Dans notre cas, CE15 fait office de RP et de BSR.
C-RP#sh run | i pim ip pim bsr-candidate Loopback0 0 ip pim rp-candidate Loopback0
Puisque le C-RP a construit un voisinage PIM avec PE1, les informations sur RP sont Ă©galement connues sur ce PE1:
PE1#show ip pim vrf C-ONE rp mapping Auto-RP is not enabled PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 15.15.15.15 (?), v2 Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150 Uptime: 01:25:50, expires: 00:01:26
Il est nécessaire de fournir ces informations à tous les autres PE / CE. Comment faire? Pour mieux comprendre le principe, je propose d'aller à l'inverse et de commencer à visualiser les informations déjà connues sur CE2:
CE2#show ip pim rp mapping Auto-RP is not enabled PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 15.15.15.15 (?), v2 Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150 Uptime: 01:27:54, expires: 00:02:26
Comme vous pouvez le voir, les messages PIM BSR se sont répandus sur l'infrastructure mVPN. Voyons le vidage du trafic sur PE1:
Comme vous pouvez le voir, PE1 encapsule le message PIM BSR dans MPLS et le marque avec 28. D'oĂą vient-il? On peut supposer que puisque ce paquet a atteint CE2 (et donc PE2), c'est-Ă -dire un LSP avant PE2.
PE2#show 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 : 04:17:40 FEC Root : 2.2.2.2 (we are the root) Opaque decoded : [gid 65536 (0x00010000)] Opaque length : 4 bytes Opaque value : 01 0004 00010000 Upstream client(s) : None Expires : N/A Path Set ID : 1 Replication client(s): > MDT (VRF C-ONE) Uptime : 04:17:40 Path Set ID : None Interface : Lspvif0 RPF-ID : * LSM ID : 3 Type: P2MP Uptime : 01:30:06 FEC Root : 1.1.1.1 Opaque decoded : [gid 131071 (0x0001FFFF)] Opaque length : 4 bytes Opaque value : 01 0004 0001FFFF Upstream client(s) : 6.6.6.6:0 [Active] Expires : Never Path Set ID : 3 Out Label (U) : None Interface : GigabitEthernet2.26* Local Label (D): 34 Next Hop : 10.2.6.6 Replication client(s): MDT (VRF C-ONE) Uptime : 01:30:06 Path Set ID : None Interface : Lspvif0 RPF-ID : *
De l'analyse de la base de données mLDP, on peut voir que sur PE2 il y a un certain arbre (LSM ID: 3), dont la racine est PE1 (IP = 1.1.1.1), Opaque = 01 0004 0001FFFF et pour cet arbre un label local 34 a été généré, qui a été envoyé au voisin R6 ( P2).
Comment PE2 a-t-il connu l'arbre, dont la racine est PE1, et a-t-il même obtenu un opaque? La réponse est simple - en utilisant le type de route BGP 3.
Lorsque PE1 a reçu le PIM BSR, il a généré une route BGP supplémentaire qui décrit le groupe (*, 224.0.0.13) (rappelez-vous qu'il s'agit d'une adresse réservée pour l'envoi de tous les messages de service PIM). Cette route sert à annoncer une nouvelle arborescence de multidiffusion mLDP. À l'intérieur du PTA se trouve la valeur Opaque à utiliser pour la signalisation via mLDP.
PE1#show bgp ipv4 mvpn all route-type 3 * 224.0.0.13 1.1.1.1 BGP routing table entry for [3][1.1.1.1:1][*][224.0.0.13][1.1.1.1]/18, version 116 Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer) Advertised to update-groups: 1 Refresh Epoch 1 Local 0.0.0.0 from 0.0.0.0 (1.1.1.1) Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best Community: no-export Extended Community: RT:65001:1 PMSI Attribute: Flags: 0x0, Tunnel type: 2, length 17, label: exp-null, tunnel parameters: 0600 0104 0101 0101 0007 0100 0400 01FF FF rx pathid: 0, tx pathid: 0x0
Ainsi, en important cette route, PE2 peut initier la signalisation mLDP vers PE1 pour l'arbre (*, 224.0.0.13). Pour l'étiquette reçue de PE2, P2 (R6) génère sa propre étiquette locale (29) et l'envoie vers P1 (R5):
P2#show 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 : 01:40:24 FEC Root : 1.1.1.1 Opaque decoded : [gid 131071 (0x0001FFFF)] Opaque length : 4 bytes Opaque value : 01 0004 0001FFFF Upstream client(s) : 5.5.5.5:0 [Active] Expires : Never Path Set ID : 2 Out Label (U) : None Interface : GigabitEthernet2.56* Local Label (D): 29 Next Hop : 10.5.6.5 Replication client(s): 2.2.2.2:0 Uptime : 01:40:24 Path Set ID : None Out label (D) : 34 Interface : GigabitEthernet2.26* Local label (U): None Next Hop : 10.2.6.2
P1 (R5) fait de même, générant son étiquette locale pour l'arbre et l'envoyant à PE1:
P1#show 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 : 01:41:24 FEC Root : 1.1.1.1 Opaque decoded : [gid 131071 (0x0001FFFF)] Opaque length : 4 bytes Opaque value : 01 0004 0001FFFF Upstream client(s) : 1.1.1.1:0 [Active] Expires : Never Path Set ID : 2 Out Label (U) : None Interface : GigabitEthernet2.15* Local Label (D): 28 Next Hop : 10.1.5.1 Replication client(s): 4.4.4.4:0 Uptime : 01:41:24 Path Set ID : None Out label (D) : 34 Interface : GigabitEthernet2.45* Local label (U): None Next Hop : 10.4.5.4 7.7.7.7:0 Uptime : 01:41:24 Path Set ID : None Out label (D) : 30 Interface : GigabitEthernet2.57* Local label (U): None Next Hop : 10.5.7.7 6.6.6.6:0 Uptime : 01:41:24 Path Set ID : None Out label (D) : 29 Interface : GigabitEthernet2.56* Local label (U): None Next Hop : 10.5.6.6
Visuellement, l'ensemble du processus est illustré dans la figure ci-dessous:
Rejoindre une arborescence partagée et construire une arborescence P2MP racine (ROOT = RP-PE)
Étape 2. Un récepteur d'info-trafic apparaît sur le réseau. Après la sortie PE (PE2) reçoit une jointure PIM de CE pour C - (*, G), PE2 effectue une vérification RPF pour trouver BGP Next-Hop vers C-RP. Found Next-Hop (1.1.1.1) sera utilisé comme partition MDT ROOT pour mLDP.
De plus, PE2 crée une interface Lspvif à l'intérieur du C-VRF:
PE2# *Dec 3 14:46:21.606: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif1, changed state to up PE2# *Dec 3 14:46:22.310: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 2.2.2.2 on interface Lspvif1
Étape 3. Egress PE (PE2) génère un message de mappage mLDP vers RP-PE (ROOT P2MP MDT) en utilisant la valeur Opaque de la mise à jour BGP.
PE2#show mpls mldp database summary LSM ID Type Root Decoded Opaque Value Client Cnt. 4 P2MP 1.1.1.1 [gid 65536 (0x00010000)] 1 1 P2MP 2.2.2.2 [gid 65536 (0x00010000)] 1 3 P2MP 1.1.1.1 [gid 131071 (0x0001FFFF)] 1 PE2# PE2#show mvpn ipv4 vrf C-ONE auto-discovery s-pmsi * * detail I-PMSI - Intra-AS Inclusive-PMSI, S-PMSI - Selective-PMSI * - Indicates Wildcard source or group address [S-PMSI][1.1.1.1:1][*][*][1.1.1.1], Joined Orig: Remote Uptime: 04:44:27 Type: MLDP P2MP Root: 1.1.1.1 Fec-Opq: 1 Global-Id: 65536 (0x10000) [S-PMSI][3.3.3.3:1][*][*][3.3.3.3], Orig: Remote Uptime: 04:44:22 Type: MLDP P2MP Root: 3.3.3.3 Fec-Opq: 1 Global-Id: 65536 (0x10000) [S-PMSI][4.4.4.4:1][*][*][4.4.4.4], Orig: Remote Uptime: 04:44:20 Type: MLDP P2MP Root: 4.4.4.4 Fec-Opq: 1 Global-Id: 65536 (0x10000) [S-PMSI][2.2.2.2:1][*][*][2.2.2.2], Joined Orig: Local Uptime: 04:44:24 Type: MLDP P2MP Root: 2.2.2.2 Fec-Opq: 1 Global-Id: 65536 (0x10000) PE2#show mpls mldp database opaque_type gid 65536 LSM ID : 4 Type: P2MP Uptime : 00:03:43 FEC Root : 1.1.1.1 Opaque decoded : [gid 65536 (0x00010000)] Opaque length : 4 bytes Opaque value : 01 0004 00010000 Upstream client(s) : 6.6.6.6:0 [Active] Expires : Never Path Set ID : 4 Out Label (U) : None Interface : GigabitEthernet2.26* Local Label (D): 35 Next Hop : 10.2.6.6 Replication client(s): MDT (VRF C-ONE) Uptime : 00:03:43 Path Set ID : None Interface : Lspvif1 RPF-ID : 0x1
Étape 4. Egress PE génère une route BGP du sixième type (rejoignant l'arborescence partagée vers RP-PE). Cette route est uniquement importée vers RP-PE.
PE2#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 230.1.1.1 BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][230.1.1.1/32]/22, version 130 Paths: (1 available, best #1, table MVPNv4-BGP-Table) Advertised to update-groups: 1 Refresh Epoch 1 Local 0.0.0.0 from 0.0.0.0 (2.2.2.2) Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best Extended Community: RT:1.1.1.1:1 rx pathid: 1, tx pathid: 0x0
Étape 5. RP-PE traduit la route BGP reçue du sixième type dans la jointure PIM vers RP. À ce stade, le RP est prêt à envoyer du trafic de multidiffusion vers le PE de sortie. Vous devez fournir le trafic de la source au RP.
PE1#show ip mroute vrf C-ONE | b \( (*, 230.1.1.1), 00:07:08/stopped, RP 15.15.15.15, flags: SG Incoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.15 Outgoing interface list: Lspvif0, Forward/Sparse, 00:07:08/stopped
Étape 6. Lorsque S-PE (PE4) reçoit le premier paquet de multidiffusion de la source (CE4), le trafic est encapsulé dans le message de registre PIM et envoyé sous forme de paquet de monodiffusion vers le C-RP (en utilisant les règles normales MPLS L3 VPN).
Étape 7. Après avoir reçu le registre PIM, le C-RP commence le processus de construction de l'arbre en C (14.14.14.14, 230.1.1.1). RP-PE reçoit la jointure PIM pour C- (14.14.14.14, 230.1.1.1) de C-RP. Ce message est traduit en route de type BGP 7. Cependant, avant d'envoyer au côté source, vous devez créer une nouvelle arborescence MDT partitionnée avec PE comme ROOT.
Étape 8. RP-PE effectue des vérifications RPF pour trouver BGP Next-Hop vers la source. Cette adresse sera utilisée comme racine MDT partitionnée pour mLDP.
Étape 9. En utilisant la route BGP Next-Hop et BGP reçus du troisième type d'Ingress PE, RP-PR génère un message de mappage mLDP vers l'adresse IP Ingress PE, créant ainsi l'arborescence P2MP racine vers Ingress PE.
Étape 10. RP-PE envoie le type de route BGP 7 (Join from RP) vers Ingress PE.
Étape 11. Ingress PE convertit la route BGP reçue du septième type en PIM Join et l'envoie vers la source de trafic.
Attachez-vous Ă l'arborescence source et construisez P2MP (ROOT = S-PE)
Étape 12. Le PE Ingress envoie également une route BGP de type 5 à tous les PE mVPN, les informant ainsi qu'il existe une source active dans le réseau. Cette route est un déclencheur pour basculer vers l'arborescence SPT.
Étape 13. Egress PE utilise le type de route BGP reçu 5 pour générer un message de mappage mLDP vers Ingress PE (les informations MDT sont tirées du type de route BGP 3).
Ainsi, le trafic peut désormais être redirigé de manière optimale de la source vers la destination à l'aide des balises mpls (mLDP).
