Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit le protocole GRE (MDT) GRE (BGP AD - PIM C) pour Multicast over VPN (mVPN). Il utilise un exemple et la mise en oeuvre dans Cisco IOS afin d'illustrer le comportement.
Il est utilisé pour connecter la multidiffusion à tous les PE dans un VRF. Par défaut, il connecte tous les routeurs PE. Par défaut, il transporte tout le trafic. Tout le trafic de contrôle PIM et le trafic du plan de données. Exemple : (*, G) Trafic et (S, G) Trafic. La valeur par défaut est le must. Ce MDT par défaut connecte tous les routeurs PE à connecter. Cela représente multipoint à multipoint. N'importe qui peut envoyer et tout le monde peut recevoir de l'arbre.
Elle est facultative et est créée à la demande. Il transporte un trafic spécifique (S, G). Dans la dernière version d'IOS, le seuil est configuré comme 0 et infini. À chaque fois qu'un premier paquet atteint le VRF, le MDT de données est initialisé et, si infini, le MDT de données n'est jamais créé, et le trafic se déplace vers l'avant dans le MDT par défaut. Le MDT de données est toujours l'arbre de réception, il n'envoie jamais de trafic. Le MDT de données est uniquement destiné au trafic (S, G).
Le seuil auquel le MDT de données est créé peut être configuré par routeur ou par VRF. Lorsque la transmission multidiffusion dépasse le seuil défini, le routeur PE émetteur crée le MDT de données et envoie un message UDP (User Datagram Protocol), qui contient des informations sur le MDT de données à tous les routeurs du MDT par défaut. Les statistiques permettant de déterminer si un flux de multidiffusion a dépassé le seuil MDT de données sont examinées une fois par seconde.
Note: Après qu’un routeur PE envoie le message UDP, il attend 3 secondes de plus avant de basculer ; 13 secondes est le délai de basculement le plus défavorable et 3 secondes le meilleur.
Les MDT de données sont créés uniquement pour les entrées de route de multidiffusion (S, G) dans la table de routage de multidiffusion VRF. Ils ne sont pas créés pour les entrées (*, G) quelle que soit la valeur du débit de données source individuel
S'il y a 5 PE chacun tenant mVRF RED, il y a 5 entrées x (S, G).
Si SSM n'est pas utilisé pour configurer des MDT de données :
G est connu comme étant configuré, mais PE ne connaît pas directement la valeur de S (S, G) du MDT par défaut propagé par MP-BGP.
L'avantage de SSM est qu'il ne dépend pas de l'utilisation d'un RP pour dériver le routeur PE source pour un groupe MDT particulier.
L'adresse IP du PE source et du groupe MDT par défaut est envoyée via le protocole BGP (Border Gateway Protocol)
BGP peut envoyer ces informations de deux manières :
Note: Les MVPN GRE ont été pris en charge avant d'utiliser MDT SAFI ; en fait, même avant le SAFI MDT en utilisant RD type 2. Techniquement, pour Profile 3, MDT SAFI ne doit pas être configuré, mais les deux SAFI sont simultanément pris en charge pour la migration.
L'attribut PMSI porte l'adresse source et l'adresse de groupe. Pour former le tunnel MT.
232.0.0.0 - 232.255.255.255 a été réservé aux applications multidiffusion spécifiques à la source globales.
239.0.0.0 - 239.255.255.255 est la plage d'espace d'adressage de multidiffusion IPv4 étendue administrativement
Portée locale de l'organisation IPv4 - 239.192.0.0/14
L'étendue locale est l'étendue d'enceinte minimale et n'est donc pas plus divisible.
Les plages 239.0.0.0/10, 239.64.0.0/10 et 239.128.0.0/10 ne sont pas affectées et peuvent être étendues à cet espace.
Ces plages doivent rester non attribuées jusqu'à ce que l'espace 239.192.0.0/14 ne soit plus suffisant.
Par exemple, tous les VRF utilisant Default-MDT 239.192.10.1 doivent utiliser la même plage de données MDT 239.232.1.0/24
La signalisation de superposition de Rosen GRE est affichée dans l'image.
La topologie de Rosen GRE est affichée dans l'image.
MVPN introduit les informations de routage multidiffusion dans la table de routage et de transfert VPN. Lorsqu'un routeur de périphérie du fournisseur reçoit des données de multidiffusion ou des paquets de contrôle d'un routeur de périphérie du client (CE), le transfert est effectué conformément aux informations de l'instance MVRF (Multicast VPN Routing and Forwarding instance). MVPN n'utilise pas la commutation d'étiquette.
Un ensemble de MVRF pouvant envoyer du trafic de multidiffusion entre eux constitue un domaine de multidiffusion. Par exemple, le domaine de multidiffusion d'un client qui souhaite envoyer certains types de trafic de multidiffusion à tous les employés du monde entier se composerait de tous les routeurs CE associés à cette entreprise.
VRF SSM-BGP mBGP: Address family VPNv4 VRF Routing Protocol
Vérifiez que toutes les interfaces connectées sont ACTIVÉES.
Une fois que nous avons configuré mdt default 239.232.0.0
Le tunnel 0 est apparu et a attribué son adresse de bouclage 0 comme source.
%LINEPROTO-5-UPDOWN : Protocole de ligne sur l’interface Tunnel0, état modifié en up
PIM(1): Check DR after interface: Tunnel0 came up! PIM(1): Changing DR for Tunnel0, from 0.0.0.0 to 1.1.1.1 (this system) %PIM-5-DRCHG: VRF SSM-BGP: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Tunnel0
Cette image montre la création de tunnel MDT.
PE1#sh int tunnel 0 Tunnel0 is up, line protocol is up Hardware is Tunnel Interface is unnumbered. Using address of Loopback0 (1.1.1.1) MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 1.1.1.1 (Loopback0) Tunnel Subblocks: src-track: Tunnel0 source tracking subblock associated with Loopback0 Set of tunnels with source Loopback0, 1 member (includes iterators), on interface <OK> Tunnel protocol/transport multi-GRE/IP Key disabled, sequencing disabled Checksumming of packets disabled
Dès que BGP MVPN est activé, tous les PE se découvrent via la route de type 1. Tunnel de multidiffusion formé. BGP transporte toutes les adresses PE de groupe et source dans l'attribut PMSI.
Cette image montre l'échange d'une route de type 1.
Cette image montre PCAP-1.
PE1#sh ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, (3.3.3.3, 239.232.0.0), 00:01:41/00:01:18, flags: sTIZ Incoming interface: Ethernet0/1, RPF nbr 10.0.1.2 Outgoing interface list: MVRF SSM-BGP, Forward/Sparse, 00:01:41/00:01:18 (2.2.2.2, 239.232.0.0), 00:01:41/00:01:18, flags: sTIZ Incoming interface: Ethernet0/1, RPF nbr 10.0.1.2 Outgoing interface list: MVRF SSM-BGP, Forward/Sparse, 00:01:41/00:01:18 “Z” Multicast Tunnel formed after BGP mVPN comes up, as it advertises the Source PE and Group Address in PMSI attribute.
PE1#sh ip pim vrf SSM-BGP neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, P - Proxy Capable, S - State Refresh Capable, G - GenID Capable Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 10.1.0.2 Ethernet0/2 00:58:18/00:01:31 v2 1 / DR S P G 3.3.3.3 Tunnel0 00:27:44/00:01:32 v2 1 / S P G 2.2.2.2 Tunnel0 00:27:44/00:01:34 v2 1 / S P G
Dès que vous configurez les informations RP :
%LINEPROTO-5-UPDOWN : Protocole de ligne sur l’interface Tunnel1, état modifié en up
L'échange de messages d'amorçage via le tunnel MDT
PIM(1): Received v2 Bootstrap on Tunnel0 from 2.2.2.2 PIM(1): pim_add_prm:: 224.0.0.0/240.0.0.0, rp=22.22.22.22, repl = 0, ver =2, is_neg =0, bidir = 0, crp = 0 PIM(1): Update prm_rp->bidir_mode = 0 vs bidir = 0 (224.0.0.0/4, RP:22.22.22.22), PIMv2 *May 18 10:28:42.764: PIM(1): Received RP-Reachable on Tunnel0 from 22.22.22.22
Cette image montre l'échange de messages bootstrap via le tunnel MDT.
PE2#sh int tunnel 1 Tunnel1 is up, line protocol is up Hardware is Tunnel Description: Pim Register Tunnel (Encap) for RP 22.22.22.22 on VRF SSM-BGP Interface is unnumbered. Using address of Ethernet0/2 (10.2.0.1) MTU 17912 bytes, BW 100 Kbit/sec, DLY 50000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 10.2.0.1 (Ethernet0/2), destination 22.22.22.22 Tunnel Subblocks: src-track: Tunnel1 source tracking subblock associated with Ethernet0/2 Set of tunnels with source Ethernet0/2, 1 member (includes iterators), on interface <OK> Tunnel protocol/transport PIM/IPv4 Tunnel TOS/Traffic Class 0xC0, Tunnel TTL 255 Tunnel transport MTU 1472 bytes Tunnel is transmit only
Deux tunnels ont formé le tunnel PIM register et le tunnel MDT.
Commande à vérifier :
**MDT BGP :
PE1#sh ip pim vrf m-SSM mdt bgp
** envoyer des données FHR :
PE1#sh ip pim vrf m-SSM mdt