Profil 0
Profil 1
Profil 3
In diesem Teil des Artikels wird die Option zum Ersetzen der Signalisierung innerhalb des Overlay-Netzwerks von PIM zu BGP untersucht.
Wie bereits erwähnt (siehe Artikel über die automatische Erkennung von BGP), wurden in BGP verschiedene Arten von Routen erfunden, um Analoge von PIM-Nachrichten zu übertragen, von denen jede bestimmte Funktionen enthält. Darüber hinaus gibt es in PIM mehr Routentypen als Nachrichtentypen.
"Warum eine Eule auf einen Globus setzen?" - Sie können fragen, weil alles mit PIM auch gut funktioniert. Und im Allgemeinen werden Sie Recht haben. Der Hauptgrund für die Bewegung eines solchen Ritters ist die Skalierbarkeit. PIM, das im Wesentlichen ein Soft Driven-Protokoll ist, erfordert für seinen Betrieb das ständige Versenden von Dienstnachrichten, was bei einer bestimmten Implementierungsgröße (wenn die Anzahl der Knoten einige hundert oder tausend überschreitet) aufgrund der unvermeidlichen Belastung der CPU zu Einschränkungen führt. BGP ist ein festgesteuertes Protokoll - d.h. Wenn etwas einmal gesagt wurde, wird es nicht wiederholt. Alle BGP-Updates sind ausschließlich auf Netzwerkänderungen zurückzuführen.
Heute werden zwei Szenarien betrachtet: Verwendung von PIM SSM und PIM ASM in C-VRF.
C-PIM SSM
Um die BGP-Signalisierung zum Erstellen von Multicast-Bäumen einfacher zu verstehen, beginnen wir unser Gespräch mit einem einfacheren PIM-SSM.
Entfernen Sie zunächst die aktuellen Einstellungen für den Rendezvous-Punkt und deaktivieren Sie die Verkehrsempfänger:
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
Auf allen PEs geben wir an, dass BGP anstelle von PIM für die Signalisierung funktioniert. Dies erfolgt mit folgendem Befehl:
ip vrf C-ONE
mdt overlay use-bgp
Ausgangspunkt für die Beobachtung ist die Situation ohne die Anwesenheit von Quellen und Empfängern von Multicast-Verkehr. In der BGP-Tabelle sollten nur Typ-1-Routen vorhanden sein:
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 ?
Verbinden wir den Empfänger:
CE4(config-if)#ip igmp join 230.1.1.1 source 11.11.11.11
Auf dem nächsten PE wird eine BGP-Route des 7. Typs erstellt - dies entspricht der PIM (S, G) Join-Nachricht:
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 ?
Logischerweise sollte diese Route nur auf PE4 und PE1 vorhanden sein (da durch sie der Verkehr passieren sollte) und auf PE2 und PE3 fehlen. Lass uns nachsehen:
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#
Wie kommt es, dass die ursprünglich auf PE4 erzeugte Route nur auf PE1 importiert wird?
Schauen wir uns den Eintrag in der BGP-Tabelle genauer an:
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
Der Präfixeintrag enthält das erweiterte Community-Routenziel = 1.1.1.1:1, das vom Router, der ein RPF-Nachbar aus Sicht von PE4 ist , zum vpnv4- Präfix hinzugefügt wurde:
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
Lassen Sie uns die Konnektivität überprüfen:
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
C-PIM ASM
Bei C-PIM im SSM-Modus ist alles ganz einfach. Damit mVPN ordnungsgemäß funktioniert, müssen zwei zusätzliche (Typ-) BGP-Routen erstellt werden.
Was aber, wenn das komplexere ASM-PIM im C-VRF verwendet wird?
Zunächst sehen wir, dass alle CEs Informationen über den Treffpunkt kennen:
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#
Wie? Wenn wir uns die BGP-Tabelle ansehen, werden wir dort keinen Hinweis auf diesen Punkt finden:
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 ?
Vergessen Sie nicht, dass wir eine PMSTI haben, auf der PIM aktiviert ist:
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
Daraus kann eine wichtige Schlussfolgerung gezogen werden: Einige PIM-Nachrichten (auch mit BGP-Signalisierung) werden über das Kernnetzwerk innerhalb des Standard-MDT übertragen .
Stellen wir uns vor, eine Quelle erscheint im Netzwerk (hinter dem CE2-Router). Da derzeit keine mRIB-Einträge auf CE2 vorhanden sind, sendet der PIM Designated Router (in unserem Fall CE2 selbst) eine Registernachricht an den Rendezvous-Punkt und signalisiert so das Vorhandensein einer aktiven Quelle im Netzwerk.
Am Treffpunkt wird ein Baum erstellt (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
Und da im Netzwerk keine aktiven Verkehrsempfänger vorhanden sind (es gibt keinen Baum (*, 231.1.1.1)), wird von der CE5-Seite eine Register-Stop-Nachricht generiert
In Reaktion auf den Empfang von Register-Stop unterbricht CE2 die Datenübertragung (keine Schnittstellen in 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
Stellen Sie sich nun vor, es gibt einen Empfänger im Netzwerk, der an Datenverkehr für Gruppe 231.1.1.1 interessiert ist. Auf PE4 wird im C-VRF eine Route angezeigt:
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
Und es wird eine BGP-Route des 6. Typs erstellt, die PIM Join (*, 231.1.1.1) entspricht:
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
In der obigen Ausgabe müssen Sie das erweiterte Community-Routenziel = 1.1.1.1:1 beachten. Was ist das und woher kommt es?
Lassen Sie uns das Vorhandensein dieses Präfixes auf anderen PEs überprüfen:
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
Jene. Das Präfix existiert nur auf PE1. Interessant ist die Tatsache, dass sich der Treffpunkt (15.15.15.15) genau an der Stelle hinter PE1 befindet.
In Kenntnis des Zwecks des Routenziels (Import von Routen in eine bestimmte VRF) bietet sich die Schlussfolgerung an - RT = 1.1.1.1:1 ist PE1 bekannt und PE2 / PE3 unbekannt. Das heißt, es ist offensichtlich, dass PE4 eine BGP-Route generiert hat, die den PIM Shared Tree Join so beschreibt, dass sie nur auf dem PE verarbeitet wurde, hinter dem sich der Rendezvous-Punkt tatsächlich befindet (tatsächlich ist dies ein Analogon der PIM Join-Übertragung über die RPF-Schnittstelle). Aber wie bringen PE1 und PE4 die Route-Zielwerte in Einklang?
PE4 führt RPF für Rendezvous-Punktadresse durch:
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 wird als RPF-Nachbar angesehen. Dies bedeutet, dass PE4 ein Routenziel innerhalb einer Route vom Typ 6 platzieren muss, die nur von PE1 importiert wird. Um die Frage zu beantworten "Woher weiß PE4 das?" - Lassen Sie uns zunächst die VPN-Route sehen:
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
Beachten Sie die zusätzliche MVPN VRF-Community: 1.1.1.1: 1. Dies ist nichts weiter als die von PE1 generierte Route Import-Community. Dieser Wert wird als Routenziel innerhalb der Multicast-Route kopiert, sodass PE1 das empfangene Update von PE4 importieren kann.
Das Ergebnis der Verarbeitung von BGP-Routentyp 6 auf PE4 ist die Erstellung eines Eintrags in der Multicast-Routing-Tabelle:
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
Hinweis - Beachten Sie, dass Tunnel0 (PMSTI) als Eingabeschnittstelle angegeben ist.
Am Treffpunkt ist die Erstellung eines gemeinsamen Baums abgeschlossen:
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
Wenn nun wieder eine aktive Verkehrsquelle im Netzwerk angezeigt wird, kann der Rendezvous-Punkt die Bäume (*, 231.1.1.1) und (12.12.12.12, 231.1.1.1) "kombinieren".
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
Der Rendezvous-Punkt erstellt einen PIM-Join (12.12.12.12, 231.1.1.1) und sendet ihn an CE2. PE1 empfängt den angegebenen PIM-Join und erstellt eine BGP-Route vom 7. Typ:
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
Bitte beachten Sie, dass der Remote VPN RD-Wert seitdem auf 2.2.2.2:1 eingestellt ist Über PE2 wird die RPF-Prüfung der Route abgeschlossen:
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
Und RT 2.2.2.2:1 wurde VPNv4 ein Präfix von der PE2-Seite hinzugefügt:
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
In diesem Schritt wird die Konstruktion des Baums (12.12.12.12, 231.1.1.1) im Abschnitt zwischen der Quelle und dem Treffpunkt abgeschlossen:
Nach dem Empfang einer Route vom Typ 7 generiert PE2 eine Route vom Typ 5, die das Vorhandensein einer aktiven Verkehrsquelle im Netzwerk signalisiert. Die Route wird von allen PE-Geräten importiert.
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
Wenn ein Routentyp 5 empfangen wird, ist die Erstellung eines Multicast-Baums auf PE4 (wo sich der Empfänger befindet) abgeschlossen:
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
Hinweis - Achten Sie auf das Q-Flag, das angibt, dass der Eintrag dank der Nachricht BGP Source-Active erstellt wurde
Die betrachtete Variante der mVPN-Organisation trägt den Codenamen "Profil 11". Seine Hauptmerkmale:
- Standard-MDT wird verwendet, um Multicast-Verkehr an das überlagerte Netzwerk zu übertragen
- Das mGRE-Protokoll wird als Transportorganisationsmethode verwendet
- Das BGP-Protokoll wird verwendet, um den Multicast-Baum innerhalb des auferlegten Netzwerks zu signalisieren