الملف الشخصي 0
الملف الشخصي 1
الملف الشخصي 3
الملف الشخصي 11
كما تعلمنا من الإدخالات السابقة ، في العمود الفقري عند تنفيذ mVPN ، هناك دائمًا بنية MDT افتراضية ، والتي تتصل بها جميع أجهزة توجيه PE. يحمل هذا MDT رسائل PIM العلوية (مثل Bootstrap و Auto-RP) بالإضافة إلى حركة مرور الإرسال المتعدد المخصصة. نتيجة لذلك ، اتضح أن بعض أجهزة PE تتلقى حتى حركة المرور التي لم تشترك فيها.
إذا كنت تريد معرفة كيفية التعامل معها - مرحبًا بك تحت الخفض!
من أجل تحسين كفاءة نقل البيانات ، يتم استخدام بنية إضافية ، والتي يشار إليها باسم "البيانات MDT". الفكرة من وراءها هي كما يلي:
- داخل الشجرة ، يتم توزيع حركة مرور C- (S ، G) فقط
- فقط هؤلاء الأشخاص الذين لديهم متلقون مهتمون يصبحون أعضاءً في الشجرة
- جهاز root Data MDT هو Ingress PE (جهاز التوجيه الذي يوجد خلفه المصدر)
بصريا ، يبدو كالتالي:
إذا تخيلنا موقفًا يبدأ فيه المصدر بالبث إلى المجموعة الثانية للبث المتعدد (230.1.1.2) ، حيث يوجد المستلمون خلف PE2 و PE3 فقط ، فسيتم إنشاء بيانات MDT إضافية وتتخذ الصورة العامة الشكل (تم حذف الافتراضي MDT):
يتم تنفيذ إشارات تحويل حركة المرور من MDT الافتراضي إلى بيانات MDT حصريًا عند الطلب عندما يتم تجاوز عتبة محددة مسبقًا بواسطة PE الدخول إما عن طريق PIM أو عن طريق BGP.
بيانات MDT باستخدام PIM
إذا تم استخدام PIM للإشارة ، فإن دخول PE ينشئ رسالة PIM Data-MDT TLV خاصة ويرسلها كجزء من MDT الافتراضي للتأكد من أن جميع خبراء المنتجات يمكنهم تلقي الرسالة. بالتزامن مع إرسال Data MDT TLV ، يبدأ Ingress PE مؤقتًا يساوي ثلاث ثوانٍ. بعد انتهاء صلاحية المؤقت ، سيتم إرسال جميع الحزم ضمن Data MDT.
وتجدر الإشارة أيضًا إلى أن المعلومات الواردة في Data-MDT TLV مخزنة مؤقتًا على جميع PEs. والسبب في ذلك تافه تمامًا - حتى إذا لم يكن هناك متلقون مهتمون لحركة المرور على PE معين في الوقت الحالي ، فقد يظهرون هناك بعد فترة. وفقًا لذلك ، عند تلقي انضمام PIM (داخل C-VRF) ، يمكن لـ PE الاتصال على الفور بـ Data MDT الموجود بالفعل على الشبكة.
تقريبا. يتم إرسال Data-MDT TLVs مرة واحدة في الدقيقة.
يتم تعيين كل Data MDT لمسار منفصل (S ، G) داخل VPN / VRF. يجب أن يحدد المسؤول بشكل صريح الحد الأقصى لعدد البيانات MDTs التي يمكن إنشاؤها على الجهاز. إذا وصل عدد الأشجار المثبتة حديثًا في وقت ما إلى الحد المحدد ، فستعيد الأشجار التالية استخدام الأشجار المثبتة بالفعل.
تقريبا. حتى كتابة هذه السطور ، لا يدعم Cisco IOS إشارات PIM عبر Data MDT. جميع ملفات التعريف مع هذا التنبيه متاحة فقط على نظام التشغيل IOS XR.
MDT البيانات مع BGP
عند استخدام BGP في شبكة تراكب لإشارات البيانات MDT ، تظل المبادئ الأساسية كما هي (مقارنة بـ PIM):
- دخول إشارات PE إلى جميع PEs أن حركة المرور لـ C- (S ، G) سيتم إرسالها داخل Data MDT
- خروج PE ، عند استلام تحديث BGP ، ينضم إلى الشجرة المحددة
- تُستخدم عائلة عناوين mVPN (sAFI 129) للإشارة.
اتضح أن Ingress PE يجب أن يشكل رسالة خاصة بتحديث BGP وإرسالها إلى جميع خبراء المنتجات داخل mVPN. لهذا ، يتم استخدام طريق من النوع الثالث.
الملف الشخصي 14
دعنا نفكر في الانتقال الموصوف باستخدام مثال مختبرنا. على وجه الخصوص ، التكوين المعروف باسم "ملف التعريف 14" قابل للتطبيق. يتميز هذا الملف الشخصي باستخدام BGP mVPN AD لبناء P2MP MLDP LSPs.
في PE ، سوف نستخدم نموذج التكوين التالي:
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
تقريبا.
mdt strict-rpf
سنتحدث عن الغرض من أمر الواجهة في العدد التالي.
الاكتشاف التلقائي
دعونا نرى ما يحدث على PE1:
في كل PE ، يتم إنشاء واجهة Lspvif0 ، والتي يتم تنشيط C-PIM عليها.
*Dec 3 10:04:54.450: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to up
لا يوجد جيران في الوقت الحالي:
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
دعنا نرى جدول 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 ?
كما ترى ، بالإضافة إلى المسارات من النوع الأول التي تم النظر فيها مسبقًا ، تمت إضافة مسارات النوع الثالث S-PMSI AD ، والتي تُستخدم للإعلان عن PE كموجه دخول لمجموعة C- (S ، G) محددة. المجموعة حاليا (* ، *). يشير هذا إلى رغبة PE في المشاركة في بناء MDT المقسم.
من الواضح ، لكي يعمل نقل البيانات ، يجب معرفة معلومات نقطة الالتقاء داخل VRF. في حالتنا ، يعمل CE15 كـ RP و BSR.
C-RP#sh run | i pim ip pim bsr-candidate Loopback0 0 ip pim rp-candidate Loopback0
نظرًا لأن C-RP قام ببناء حي PIM مع PE1 ، فإن المعلومات حول RP معروفة أيضًا في 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
من الضروري تسليم هذه المعلومات إلى جميع PE / CEs الآخرين. كيف افعلها؟ لفهم المبدأ بشكل أفضل ، أقترح الانتقال من العكس والبدء في عرض المعلومات المعروفة بالفعل عن 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
كما ترى ، انتشرت رسائل PIM BSR عبر البنية التحتية لـ mVPN. دعونا نرى تفريغ حركة المرور على PE1:
كما ترى ، تقوم PE1 بتغليف رسالة PIM BSR داخل MPLS وتسميتها بـ 28. من أين تأتي؟ يمكننا أن نفترض أنه بما أن هذه الحزمة وصلت إلى CE2 (ومن ثم PE2) ، فإن بعض LSP قبل 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 : *
من تحليل قاعدة بيانات mLDP ، يمكن ملاحظة أنه في PE2 توجد شجرة معينة (معرف LSM: 3) ، جذرها هو PE1 (IP = 1.1.1.1) ، معتم = 01 0004 0001FFFF ولهذه الشجرة تم إنشاء تسمية محلية 34 ، والتي تم إرسالها إلى الجار R6 ( P2).
كيف عرف PE2 عن الشجرة ، التي جذرها PE1 ، وحتى أنها حصلت على معتم لها؟ الجواب بسيط - باستخدام طريق BGP من النوع 3.
عندما استقبل PE1 PIM BSR ، أنشأ مسار BGP إضافيًا يصف المجموعة (* ، 224.0.0.13) (تذكر أن هذا عنوان محجوز لإرسال جميع رسائل خدمة PIM). يعمل هذا المسار على الإعلان عن شجرة MLDP جديدة متعددة البث. داخل منطقة التجارة التفضيلية توجد قيمة غير شفافة تستخدم للإشارة عبر 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
وبالتالي ، من خلال استيراد هذا المسار ، يمكن لـ PE2 بدء إشارة mLDP نحو PE1 للشجرة (* ، 224.0.0.13). بالنسبة للملصق المستلم من PE2 ، يقوم P2 (R6) بإنشاء الملصق المحلي الخاص به (29) وإرساله نحو 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) بنفس الشيء ، حيث يقوم بإنشاء ملصق محلي للشجرة وإرساله إلى 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
بصريا ، تظهر العملية برمتها في الشكل أدناه:
الانضمام إلى شجرة مشتركة وبناء شجرة جذر P2MP (ROOT = RP-PE)
الخطوة 2. يظهر مستقبل حركة المرور على الشبكة. بعد حصول Egress PE (PE2) على انضمام PIM من CE لـ C - (* ، G) ، يقوم PE2 بإجراء فحص RPF للعثور على BGP Next-Hop نحو C-RP. سيتم استخدام Next-Hop (1.1.1.1) كجذر MDT مقسم لـ mLDP.
بالإضافة إلى ذلك ، ينشئ PE2 واجهة Lspvif داخل 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
الخطوة 3. يولد خروج PE (PE2) رسالة تعيين mLDP نحو RP-PE (ROOT P2MP MDT) باستخدام قيمة غير شفافة من تحديث 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
الخطوة 4. يولد Egress PE مسار BGP من النوع السادس (الانضمام إلى الشجرة المشتركة باتجاه RP-PE). يتم استيراد هذا المسار فقط إلى 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
الخطوة 5. يترجم RP-PE مسار BGP المستلم من النوع السادس في PIM Join نحو RP. في هذه المرحلة ، يكون RP جاهزًا لإرسال حركة مرور متعددة البث نحو Egress PE. تحتاج إلى توصيل حركة المرور من المصدر إلى 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
الخطوة 6. عندما يتلقى S-PE (PE4) أول حزمة إرسال متعدد من المصدر (CE4) ، يتم تغليف حركة المرور داخل رسالة PIM Register وإرسالها كحزمة أحادية الإرسال باتجاه C-RP (باستخدام قواعد MPLS L3 VPN العادية).
الخطوة 7. بعد استلام سجل PIM ، يبدأ C-RP عملية بناء شجرة C (14.14.14.14، 230.1.1.1). تتلقى RP-PE انضمام PIM لـ C- (14.14.14.14، 230.1.1.1) من C-RP. تمت ترجمة هذه الرسالة إلى نوع مسار BGP 7. ومع ذلك ، قبل الإرسال إلى جانب المصدر ، تحتاج إلى إنشاء شجرة MDT مقسمة جديدة باستخدام PE كـ ROOT.
الخطوة 8. يقوم RP-PE بإجراء فحوصات RPF للعثور على BGP Next-Hop باتجاه المصدر. سيتم استخدام هذا العنوان كجذر MDT مقسم لـ mLDP.
الخطوة 9. باستخدام مسار BGP Next-Hop و BGP المستلم من النوع الثالث من Ingress PE ، يقوم RP-PR بإنشاء رسالة تعيين mLDP تجاه عنوان IP الخاص بـ Ingress PE ، وبالتالي بناء شجرة جذر P2MP إلى Ingress PE.
الخطوة 10. يرسل RP-PE طريق BGP من النوع 7 (الانضمام من RP) باتجاه الدخول إلى PE.
الخطوة 11. يحول Ingress PE مسار BGP المستلم من النوع السابع إلى PIM Join ويرسله نحو مصدر حركة المرور.
إرفاق شجرة المصدر وبناء P2MP (ROOT = S-PE)
الخطوة 12. يرسل Ingress PE أيضًا مسار Type 5 BGP إلى جميع mVPN PEs ، وبالتالي يخبرهم بوجود مصدر نشط على الشبكة. هذا المسار هو مشغل للتبديل إلى شجرة SPT.
الخطوة 13. يستخدم Egress PE نوع مسار BGP المستلم 5 لتوليد رسالة تعيين mLDP تجاه دخول PE (يتم أخذ معلومات MDT من نوع مسار BGP 3).
وبالتالي ، يمكن الآن إعادة توجيه حركة المرور بالطريقة المثلى من المصدر إلى الوجهة باستخدام علامات mpls (mLDP).
