Profil 0
Profil 1
Profil 3
Dans cette partie de l'article, nous examinerons la possibilité de remplacer la signalisation dans le réseau de superposition de PIM à BGP.
Comme indiqué précédemment (voir l'article sur la détection automatique BGP), afin de transmettre des analogues de messages PIM, plusieurs types de routes ont été inventés dans BGP, chacun d'entre eux portant certaines fonctionnalités. De plus, il existe plus de types de routes que de types de messages dans PIM.
"Pourquoi mettre un hibou sur un globe?" - vous pouvez demander, car tout fonctionne très bien avec PIM aussi. Et, en général, vous aurez raison. La principale raison d'un tel mouvement de chevalier est l'évolutivité. PIM, étant essentiellement un protocole Soft Driven, nécessite l'envoi constant de messages de service pour son fonctionnement, ce qui, à une certaine taille d'implémentation (si le nombre de nœuds commence à dépasser quelques centaines ou milliers), introduit des limitations en raison de la charge inévitable du processeur. BGP est un protocole Hard Driven - c.-à-d. si quelque chose a été dit une fois, il ne se répète pas; toutes les mises à jour BGP sont uniquement dues à des changements de réseau.
Aujourd'hui, nous allons considérer deux scénarios: utiliser PIM SSM et PIM ASM dans C-VRF.
C-PIM SSM
Pour une compréhension plus simple de la signalisation BGP pour la création d'arbres de multidiffusion, commençons notre conversation avec un SSM PIM plus simple.
Tout d'abord, supprimons les paramètres actuels du point de rendez-vous et désactivons les destinataires du trafic:
CE4(config)#interface Loopback0
CE4(config-if)#no ip igmp join-group 231.1.1.2
CE4(config-if)#
CE15(config)#no ip pim bsr-candidate Loopback0 0
CE15(config)#no ip pim rp-candidate Loopback0 group-list 1
Sur tous les PE, nous indiquerons que BGP fonctionnera pour la signalisation au lieu de PIM. Cela se fait avec la commande suivante:
ip vrf C-ONE
mdt overlay use-bgp
Le point de départ de l'observation sera la situation sans la présence de sources et de destinataires du trafic multicast. Seules les routes de type 1 doivent être présentes dans la table BGP:
PE1#show bgp ipv4 mvpn all
BGP table version is 406, 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 ?
Connectons le destinataire:
CE4(config-if)#ip igmp join 230.1.1.1 source 11.11.11.11
Sur le PE le plus proche, une route BGP du 7ème type est créée - c'est l'équivalent du message de jointure PIM (S, G):
PE4#show bgp ipv4 mvpn all
Route Distinguisher: 1.1.1.1:1
*> [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/22
0.0.0.0 32768 ?
Logiquement, cette route ne doit être présente que sur PE4 et PE1 (car c'est par eux que le trafic doit passer) et absente sur PE2 et PE3. Allons vérifier:
PE1#show bgp ipv4 mvpn all | b \[7\]
*>i [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/22
4.4.4.4 0 100 0 ?
PE2#show bgp ipv4 mvpn all | b \[7\]
PE2#
PE3#show bgp ipv4 mvpn all | b \[7\]
PE3#
Comment se fait-il que la route créée à l'origine sur PE4 ne soit importée que sur PE1?
Regardons l'entrée dans la table BGP plus en détail:
PE4#show bgp ipv4 mvpn all route-type 7 1.1.1.1:1 65001 11.11.11.11 230.1.1.1
BGP routing table entry for [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/22, version 533
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
Advertised to update-groups:
7
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (4.4.4.4)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
Extended Community: RT:1.1.1.1:1
rx pathid: 1, tx pathid: 0x0
L'entrée de préfixe contient la communauté étendue Route-target = 1.1.1.1:1, qui a été ajoutée au préfixe vpnv4 par le routeur, qui est un voisin RPF du point de PE4:
PE1#show bgp vpnv4 unicast rd 1.1.1.1:1 11.11.11.11/32
BGP routing table entry for 1.1.1.1:1:11.11.11.11/32, version 670
Paths: (1 available, best #1, table C-ONE)
Advertised to update-groups:
1 17
Refresh Epoch 4
65011
172.1.11.11 (via vrf C-ONE) from 172.1.11.11 (11.11.11.11)
Origin IGP, metric 0, localpref 100, valid, external, best
Extended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1
mpls labels in/out 10018/nolabel
rx pathid: 0, tx pathid: 0x0
PE1#
PE2#show bgp vpnv4 unicast rd 2.2.2.2:1 11.11.11.11/32
BGP routing table entry for 2.2.2.2:1:11.11.11.11/32, version 762
Paths: (1 available, best #1, table C-ONE)
Advertised to update-groups:
1
Refresh Epoch 152
65011, imported path from 1.1.1.1:1:11.11.11.11/32 (global)
1.1.1.1 (metric 4) (via default) from 8.8.8.8 (8.8.8.8)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1
Originator: 1.1.1.1, Cluster list: 8.8.8.8
Connector Attribute: count=1
type 1 len 12 value 1.1.1.1:1:1.1.1.1
mpls labels in/out nolabel/10018
rx pathid: 0, tx pathid: 0x0
Vérifions la connectivité:
CE1#ping 230.1.1.1 so 11.11.11.11 rep 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 230.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11
Reply to request 0 from 14.14.14.14, 7 ms
Reply to request 0 from 14.14.14.14, 8 ms
Reply to request 1 from 14.14.14.14, 7 ms
Reply to request 1 from 14.14.14.14, 9 ms
Reply to request 2 from 14.14.14.14, 7 ms
Reply to request 2 from 14.14.14.14, 7 ms
ASM C-PIM
Dans le cas du C-PIM en mode SSM, tout est assez simple. Pour que mVPN fonctionne correctement, il suffit de créer deux routes BGP (types) supplémentaires.
Mais que se passe-t-il si le PIM ASM plus complexe est utilisé à l'intérieur du C-VRF?
Tout d'abord, nous voyons que tous les CE connaissent des informations sur le point de rendez-vous:
CE2#show ip pim rp mapp
CE2#show ip pim rp mapping
Auto-RP is not enabled
PIM Group-to-RP Mappings
Group(s) 231.1.1.0/24
RP 15.15.15.15 (?), v2
Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150
Uptime: 1d04h, expires: 00:02:09
CE2#
Comment? Si nous regardons la table BGP, nous n'y trouverons aucun indice sur ce point:
PE1#show bgp ipv4 mvpn all
BGP table version is 682, 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 ?
N'oubliez pas que nous avons un PMSTI avec PIM activé:
PE1#show ip pim vrf C-ONE interface
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 Tunnel2 v2/S 0 30 1 1.1.1.1
De cela, une conclusion importante peut être tirée - certains messages PIM (même avec la signalisation BGP) sont transmis sur le réseau central dans le MDT par défaut .
Imaginons qu'une source apparaisse sur le réseau (derrière le routeur CE2). Puisqu'il n'y a actuellement aucune entrée mRIB sur CE2, le routeur désigné PIM (dans notre cas, c'est CE2 lui-même) envoie un message Register au point de rendez-vous, signalant ainsi la présence d'une source active dans le réseau.
Un arbre est créé au point de rendez-vous (12.12.12.12, 231.1.1.1):
CE5#show ip mroute | b \(
(*, 231.1.1.1), 00:00:19/stopped, RP 15.15.15.15, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(12.12.12.12, 231.1.1.1), 00:00:19/00:02:40, flags: P
Incoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.1
Outgoing interface list: Null
Et, comme il n'y a pas de destinataires de trafic actifs sur le réseau (il n'y a pas d'arborescence (*, 231.1.1.1)), alors un message Register-Stop est généré du côté CE5
En réponse à la réception de Register-Stop, CE2 suspend la transmission de données (pas d'interfaces dans OIL):
CE2#show ip mroute 231.1.1.1
(12.12.12.12, 231.1.1.1), 00:00:07/00:02:54, flags: PFT
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list: Null
Maintenant, imaginez qu'il y a un destinataire sur le réseau intéressé par le trafic pour le groupe 231.1.1.1. Sur PE4, une route apparaît à l'intérieur du C-VRF:
PE4#show ip mroute vrf C-ONE 231.1.1.1 | b \(
(*, 231.1.1.1), 00:00:44/00:02:45, RP 15.15.15.15, flags: Sg
Incoming interface: Tunnel0, RPF nbr 1.1.1.1
Outgoing interface list:
GigabitEthernet2.414, Forward/Sparse, 00:00:44/00:02:45
Et une route BGP du 6ème type est créée, ce qui est l'équivalent de PIM Join (*, 231.1.1.1):
PE4#show bgp ipv4 mvpn all
Route Distinguisher: 1.1.1.1:1
*> [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22
0.0.0.0 32768 ?
PE4#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1
BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22, version 808
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
Advertised to update-groups:
8
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (4.4.4.4)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
Extended Community: RT:1.1.1.1:1
rx pathid: 1, tx pathid: 0x0
Dans la sortie ci-dessus, vous devez noter la communauté étendue Route-target = 1.1.1.1:1. De quoi s'agit-il et d'où vient-il?
Vérifions la présence de ce préfixe sur d'autres PE:
PE2#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1
% Network not in table
PE3#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1
% Network not in table
PE1#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1
BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22, version 698
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
Not advertised to any peer
Refresh Epoch 2
Local
4.4.4.4 (metric 3) from 8.8.8.8 (8.8.8.8)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:1.1.1.1:1
Originator: 4.4.4.4, Cluster list: 8.8.8.8
rx pathid: 0, tx pathid: 0x0
Ceux. le préfixe n'existe que sur PE1. Ce qui est intéressant, c'est que le point de rendez-vous (15.15.15.15) est situé sur le site derrière PE1.
Connaissant le but de la Route-target (importation de routes dans un certain VRF), la conclusion se suggère - RT = 1.1.1.1:1 est connu de PE1 et inconnu de PE2 / PE3. Autrement dit, il est évident que PE4 a généré une route BGP décrivant la jointure d'arbre partagée PIM de telle manière qu'elle n'a été traitée que sur le PE derrière lequel le point de rendez-vous est réellement situé (en fait, il s'agit d'un analogue de la transmission de jointure PIM via l'interface RPF). Mais comment PE1 et PE4 réconcilient les valeurs Route-cible?
PE4 conduit RPF pour l'adresse du point de rendez-vous:
PE4#show ip rpf vrf C-ONE 15.15.15.15
RPF information for ? (15.15.15.15)
RPF interface: Tunnel0
RPF neighbor: ? (1.1.1.1)
RPF route/mask: 15.15.15.15/32
RPF type: unicast (bgp 65001)
Doing distance-preferred lookups across tables
BGP originator: 1.1.1.1
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
PE1 est considéré comme un voisin RPF. Cela signifie que PE4 doit placer une Route-target à l'intérieur d'une route de type 6 que seul PE1 importera. Pour répondre à la question "comment PE4 le sait-il?" - voyons, pour commencer, la route vpn:
PE4#show bgp vpnv4 unicast vrf C-ONE 15.15.15.15/32
BGP routing table entry for 4.4.4.4:1:15.15.15.15/32, version 859
Paths: (1 available, best #1, table C-ONE)
Advertised to update-groups:
1
Refresh Epoch 1
65015, imported path from 1.1.1.1:1:15.15.15.15/32 (global)
1.1.1.1 (metric 3) (via default) from 8.8.8.8 (8.8.8.8)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1
Originator: 1.1.1.1, Cluster list: 8.8.8.8
Connector Attribute: count=1
type 1 len 12 value 1.1.1.1:1:1.1.1.1
mpls labels in/out nolabel/10013
rx pathid: 0, tx pathid: 0x0
Notez la communauté MVPN VRF supplémentaire: 1.1.1.1: 1. Ce n'est rien de plus que la communauté Route Import générée par PE1. C'est cette valeur qui est copiée en tant que cible de route à l'intérieur de la route de multidiffusion, ce qui permet à PE1 d'importer la mise à jour reçue de PE4.
Le résultat du traitement du type de route BGP 6 sur PE4 est la création d'une entrée dans la table de routage multicast:
PE4#show ip mroute vrf C-ONE
(*, 231.1.1.1), 00:23:31/00:02:33, RP 15.15.15.15, flags: Sg
Incoming interface: Tunnel0, RPF nbr 1.1.1.1
Outgoing interface list:
GigabitEthernet2.414, Forward/Sparse, 00:23:31/00:02:33
Remarque - Notez que Tunnel0 (PMSTI) est spécifié comme interface d'entrée.
Au point de rendez-vous, la création d'un arbre commun est terminée:
CE5#show ip mroute | b \(
(*, 231.1.1.1), 00:25:42/00:03:22, RP 15.15.15.15, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet2.115, Forward/Sparse, 00:25:42/00:03:22
Désormais, si une source de trafic active réapparaît sur le réseau, le point de rendez-vous saura "combiner" (*, 231.1.1.1) et (12.12.12.12, 231.1.1.1) les arbres.
CE5#show ip mroute | b \(
(*, 231.1.1.1), 00:47:12/stopped, RP 15.15.15.15, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet2.115, Forward/Sparse, 00:47:12/00:02:31
(12.12.12.12, 231.1.1.1), 00:00:23/00:02:43, flags: PT
Incoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.1
Outgoing interface list: Null
Le point de rendez-vous crée une jointure PIM (12.12.12.12, 231.1.1.1), l'envoyant vers CE2. PE1 reçoit la jointure PIM spécifiée et crée une route BGP du 7ème type:
PE1#show bgp ipv4 mvpn all
Route Distinguisher: 2.2.2.2:1
*> [7][2.2.2.2:1][65001][12.12.12.12/32][231.1.1.1/32]/22
0.0.0.0 32768 ?
PE1#show bgp ipv4 mvpn all route-type 7 2.2.2.2:1 65001 12.12.12.12 231.1.1.1
BGP routing table entry for [7][2.2.2.2:1][65001][12.12.12.12/32][231.1.1.1/32]/22, version 726
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
Advertised to update-groups:
8
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
Extended Community: RT:2.2.2.2:1
rx pathid: 1, tx pathid: 0x0
Veuillez noter que la valeur Remote VPN RD est définie sur 2.2.2.2:1, car c'est par PE2 que le contrôle RPF de l'itinéraire est effectué:
PE1#show ip rpf vrf C-ONE 12.12.12.12
RPF information for ? (12.12.12.12)
RPF interface: Tunnel2
RPF neighbor: ? (2.2.2.2)
RPF route/mask: 12.12.12.12/32
RPF type: unicast (bgp 65001)
Doing distance-preferred lookups across tables
BGP originator: 2.2.2.2
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
Et RT 2.2.2.2:1 a été ajouté à VPNv4 un préfixe du côté PE2:
PE1#show bgp vpnv4 unicast vrf C-ONE 12.12.12.12
BGP routing table entry for 1.1.1.1:1:12.12.12.12/32, version 706
Paths: (1 available, best #1, table C-ONE)
Advertised to update-groups:
1
Refresh Epoch 2
65012, imported path from 2.2.2.2:1:12.12.12.12/32 (global)
2.2.2.2 (metric 4) (via default) from 8.8.8.8 (8.8.8.8)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:2.2.2.2:1
Originator: 2.2.2.2, Cluster list: 8.8.8.8
Connector Attribute: count=1
type 1 len 12 value 2.2.2.2:1:2.2.2.2
mpls labels in/out nolabel/31
rx pathid: 0, tx pathid: 0x0
A cette étape, en effet, la construction de l'arbre (12.12.12.12, 231.1.1.1) est terminée dans la section entre la source et le point de rendez-vous:
Après avoir reçu une route de type 7, PE2 génère une route de type 5, signalant la présence d'une source de trafic active sur le réseau. La route est importée par tous les appareils PE.
PE2#show bgp ipv4 mvpn all
Route Distinguisher: 2.2.2.2:1 (default for vrf C-ONE)
*> [5][2.2.2.2:1][12.12.12.12][231.1.1.1]/18
0.0.0.0 32768 ?
PE2#show bgp ipv4 mvpn all route-type 5 12.12.12.12 231.1.1.1
BGP routing table entry for [5][2.2.2.2:1][12.12.12.12][231.1.1.1]/18, version 838
Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)
Advertised to update-groups:
8
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
Community: no-export
Extended Community: RT:65001:1
rx pathid: 0, tx pathid: 0x0
Lors de la réception d'une route de type 5, la création d'une arborescence multicast est terminée sur PE4 (où se trouve le récepteur):
PE4#show ip mroute vrf C-ONE
(12.12.12.12, 231.1.1.1), 00:22:24/00:02:51, flags: TnQ
Incoming interface: Tunnel0, RPF nbr 2.2.2.2
Outgoing interface list:
GigabitEthernet2.414, Forward/Sparse, 00:22:24/00:03:19
Remarque - faites attention à l'indicateur Q, qui indique que l'entrée a été créée grâce au message BGP Source-Active
La variante considérée de l'organisation mVPN porte le nom de code "Profile 11". Ses principales caractéristiques:
- pour transmettre le trafic multicast vers le réseau superposé, MDT par défaut est utilisé
- le protocole mGRE est utilisé comme méthode d'organisation du transport
- Le protocole BGP est utilisé pour signaler l'arbre de multidiffusion au sein du réseau imposé