الملف الشخصي 0
الملف الشخصي 1
الملف الشخصي 3
في هذا الجزء من المقالة ، سننظر في خيار استبدال الإشارات داخل شبكة التراكب من PIM إلى BGP.
كما تمت مناقشته سابقًا (راجع مقالة BGP Auto-Discovery) ، من أجل إرسال نظائر لرسائل PIM ، تم اختراع عدة أنواع من المسارات في BGP ، كل منها يحمل وظائف معينة. علاوة على ذلك ، هناك أنواع مسارات أكثر من أنواع الرسائل الموجودة في PIM.
"لماذا نضع بومة على الكرة الأرضية؟" - قد تسأل ، لأن كل شيء يعمل بشكل رائع مع PIM أيضًا. وبشكل عام ، سوف تكون على حق. السبب الرئيسي لحركة مثل هذا الفارس هو قابلية التوسع. يتطلب PIM ، كونه في جوهره بروتوكولًا مرنًا ، إرسال رسائل خدمة بريدية ثابتة لتشغيله ، والتي ، عند حجم معين للتنفيذ (إذا بدأ عدد العقد في تجاوز بضع مئات أو آلاف) ، تفرض قيودًا بسبب حمل وحدة المعالجة المركزية الذي لا مفر منه. BGP هو بروتوكول موجه بقوة - أي إذا قيل شيء مرة واحدة ، فلا يتكرر ؛ أي تحديثات BGP هي فقط بسبب تغييرات الشبكة.
سننظر اليوم في سيناريوهين: استخدام PIM SSM و PIM ASM ضمن C-VRF.
C-PIM SSM
لفهم أبسط لإشارات BGP لبناء أشجار متعددة البث ، دعنا نبدأ محادثتنا مع PIM SSM أبسط.
بادئ ذي بدء ، لنقم بإزالة الإعدادات الحالية لنقطة الالتقاء وتعطيل مستلمي حركة المرور:
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
في جميع PEs ، سنشير إلى أن BGP ستعمل للإشارة بدلاً من PIM. يتم ذلك باستخدام الأمر التالي:
ip vrf C-ONE
mdt overlay use-bgp
ستكون نقطة البداية للمراقبة هي الموقف بدون وجود مصادر ومتلقي حركة مرور البث المتعدد. يجب أن تكون المسارات من النوع 1 فقط موجودة في جدول 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 ?
لنقم بتوصيل المستلم:
CE4(config-if)#ip igmp join 230.1.1.1 source 11.11.11.11
في أقرب PE ، يتم إنشاء مسار BGP من النوع السابع - وهذا يعادل رسالة الانضمام 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 ?
منطقياً ، يجب أن يكون هذا المسار موجودًا فقط على PE4 و PE1 (لأنه من خلالهما يجب أن تمر حركة المرور) وغائبًا في PE2 و PE3. دعونا تحقق:
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#
كيف يتم استيراد المسار الذي تم إنتاجه في الأصل على PE4 فقط على PE1؟
لنلقِ نظرة على الإدخال في جدول BGP بمزيد من التفصيل:
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
يحتوي إدخال البادئة على مسار المجتمع الممتد Route-target = 1.1.1.1:1 ، والذي تمت إضافته إلى بادئة vpnv4 بواسطة جهاز التوجيه ، وهو جار RPF من نقطة 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
دعنا نتحقق من الاتصال:
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
في حالة C-PIM في وضع SSM ، كل شيء بسيط للغاية. لكي يعمل mVPN بشكل صحيح ، يكفي إنشاء مسارين (نوعين) إضافيين BGP.
ولكن ماذا لو تم استخدام ASM PIM أكثر تعقيدًا داخل C-VRF؟
بادئ ذي بدء ، نرى أن جميع المديرين التنفيذيين يعرفون معلومات حول نقطة الالتقاء:
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#
كيف؟ إذا نظرنا إلى جدول BGP ، فلن نجد أي تلميح لهذه النقطة هناك:
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 ?
لا تنس أن لدينا PMSTI مع تنشيط PIM:
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
من هذا ، يمكن استخلاص نتيجة مهمة - يتم إرسال بعض رسائل PIM (حتى مع إشارات BGP) عبر العمود الفقري في إطار عمل MDT الافتراضي .
دعنا نتخيل ظهور مصدر على الشبكة (خلف جهاز التوجيه CE2). نظرًا لعدم وجود مدخلات mRIB حاليًا على CE2 ، فإن جهاز التوجيه المعين PIM (في حالتنا ، هو CE2 نفسه) يرسل رسالة تسجيل إلى نقطة الالتقاء ، مما يشير إلى وجود مصدر نشط في الشبكة.
يتم إنشاء شجرة عند نقطة الالتقاء (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
ونظرًا لعدم وجود مستلمين نشطين لحركة المرور في الشبكة (لا توجد شجرة (* ، 231.1.1.1)) ، يتم إنشاء رسالة إيقاف التسجيل من جانب CE5
استجابةً لتلقي Register-Stop ، يعلق CE2 نقل البيانات (لا توجد واجهات في 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
الآن ، تخيل أن هناك مستلمًا على الشبكة مهتمًا بحركة المرور للمجموعة 231.1.1.1. في PE4 ، يظهر طريق داخل 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
ويتم إنشاء مسار BGP من النوع السادس ، وهو ما يعادل 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
في الناتج أعلاه ، تحتاج إلى ملاحظة مسار المجتمع الممتد المستهدف = 1.1.1.1:1. ما هو ومن أين أتت؟
دعنا نتحقق من وجود هذه البادئة على PEs الأخرى:
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
أولئك. البادئة موجودة فقط في PE1. الأمر المثير للاهتمام هو حقيقة أن نقطة الالتقاء (15.15.15.15) تقع في الموقع خلف PE1.
مع معرفة الغرض من هدف المسار (استيراد المسارات إلى VRF محدد) ، فإن الاستنتاج يقترح نفسه - RT = 1.1.1.1:1 معروف لـ PE1 وغير معروف لـ PE2 / PE3. أي أنه من الواضح أن PE4 قد أنشأت مسار BGP يصف PIM Shared Tree Join بطريقة تم معالجتها فقط على PE التي تقع خلفها نقطة الالتقاء (في الواقع ، هذا تناظري لنقل PIM Join من خلال واجهة RPF). ولكن كيف يوفق PE1 و PE4 بين قيم Route-target؟
يقوم PE4 بإجراء RPF لعنوان نقطة الالتقاء:
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 على أنها جارة RPF. هذا يعني أنه يجب على PE4 وضع هدف مسار داخل مسار من النوع 6 لن يستورده سوى PE1. للإجابة على السؤال "كيف تعرف PE4 ذلك؟" - دعنا نرى ، بالنسبة للمبتدئين ، مسار 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
لاحظ مجتمع MVPN VRF الإضافي: 1.1.1.1: 1. هذا ليس أكثر من مجتمع استيراد المسار الذي تم إنشاؤه بواسطة PE1. يتم نسخ هذه القيمة كهدف مسار داخل مسار الإرسال المتعدد ، مما يسمح لـ PE1 باستيراد التحديث المستلم من PE4.
نتيجة معالجة نوع مسار BGP 6 على PE4 هو إنشاء إدخال في جدول توجيه البث المتعدد:
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
ملاحظة - لاحظ أن Tunnel0 (PMSTI) محدد كواجهة إدخال.
عند نقطة الالتقاء ، يتم الانتهاء من إنشاء شجرة مشتركة:
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
الآن ، إذا ظهر مصدر حركة مرور نشط على الشبكة مرة أخرى ، فستعرف نقطة الالتقاء كيفية "الجمع" (* ، 231.1.1.1) و (12.12.12.12 ، 231.1.1.1) الأشجار.
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
تقوم نقطة الالتقاء بإنشاء رابط PIM (12.12.12.12 ، 231.1.1.1) ، وإرساله نحو CE2. يتلقى PE1 انضمام PIM المحدد ويقوم بإنشاء مسار BGP من النوع السابع:
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
يرجى ملاحظة أنه تم تعيين قيمة Remote VPN RD على 2.2.2.2:1 ، منذ ذلك الحين من خلال PE2 يتم الانتهاء من فحص RPF للمسار:
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
تمت إضافة RT 2.2.2.2:1 إلى VPNv4 بادئة من جانب 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
هذه الخطوة ، في الواقع ، تكمل بناء الشجرة (12.12.12.12 ، 231.1.1.1) في القسم بين المصدر ونقطة الالتقاء:
بعد تلقي مسار من النوع السابع ، ينشئ PE2 مسارًا من النوع الخامس ، مما يشير إلى وجود مصدر حركة مرور نشط في الشبكة. يتم استيراد المسار بواسطة جميع أجهزة 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
عند استلام مسار من النوع 5 ، في PE4 (حيث يوجد جهاز الاستقبال) ، يتم الانتهاء من إنشاء شجرة متعددة البث:
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
ملاحظة - انتبه إلى علامة Q ، والتي تشير إلى أن الإدخال تم إنشاؤه بفضل رسالة BGP Source-Active
المتغير المدروس لمنظمة mVPN هو الاسم الرمزي "الملف الشخصي 11". خصائصه الرئيسية:
- لنقل حركة المرور المتعدد إلى الشبكة المتراكبة ، يتم استخدام Default MDT
- يتم استخدام بروتوكول mGRE كطريقة لتنظيم النقل
- يستخدم بروتوكول BGP للإشارة إلى شجرة الإرسال المتعدد داخل الشبكة المفروضة