VPLS مع ملاحظة فنية حول إرسال إشارات BGP
المحتويات
المقدمة
يصف هذا المستند الاكتشاف التلقائي المستند إلى بروتوكول العبارة الحدودية (BGP) لخدمة شبكة LAN الخاصة الظاهرية (VPLS) مع إشارات BGP. الاكتشاف التلقائي هو وسيلة لحافة الموفر (PE) للتعرف على نقاط الوصول (PE) البعيدة التي تعد أعضاء في مجال VPLS معين.يعد إرسال الإشارات وسيلة ل PE للتعرف على تسمية المستخدم الزائفة المتوقعة من قبل PE بعيد محدد لمجال VPLS معين.
ارجع إلى مستندات فريق عمل هندسة الإنترنت التالية:
- تصف خدمة شبكة المنطقة المحلية الخاصة الظاهرية (VPLS) المتوافقة مع المعيار RFC 4762 التي تستخدم إرسال إشارات بروتوكول توزيع التسمية (LDP) الاكتشاف التلقائي لبروتوكول BGP باستخدام إرسال إشارات بروتوكول توزيع التسمية (LDP) إلى VPLS (المعروف أيضا باسم Martini).
- تصف خدمة شبكة LAN الخاصة الظاهرية (VPLS) المتوافقة مع المعيار RFC 4761 التي تستخدم بروتوكول BGP للاكتشاف التلقائي وإرسال الإشارات بروتوكول BGP الاكتشاف التلقائي وإرسال إشارات BGP لبروتوكول VPLS (المعروف أيضا باسم Kompella).
يركز هذا المستند على RFC 4761. باستخدام RFC 4761، تحتوي معلومات قابلية الوصول إلى طبقة الشبكة (NLRI) لبروتوكول BGP على معلومات الاكتشاف التلقائي وإرسال الإشارات. عندما تتلقى موجهات PE البعيدة تحديث BGP هذا، فإنها تحتوي على جميع المعلومات اللازمة لإعداد شبكة كاملة من الأسلاك الزائفة ل VPLS. يستخدم الاكتشاف التلقائي ل BGP وإرسال إشارات BGP نفس مجموعة عناوين BGP.
واجهة سطر الأوامر (CLI) والمخرجات من برنامج Cisco IOS®. ويكون التكوين والوظيفة مماثلين جدا في برنامج Cisco IOS-XR وبرنامج Cisco NX-OS.
المشكلة
يتكون VPLS من مجموعة من الأسلاك الزائفة (PW) بطريقة من نقطة إلى عدة نقاط. حتى الآن، تم إستخدام LDP للإشارة إلى الأسلاك الزائفة بين موجهات PE. لذا، فقد أشارت جلسة LDP المستهدفة إلى البطاقات التي يجب إستخدامها والتي تحتوي على علامات زائفة بين زوج من موجهات PE. أنت يستطيع يدويا شكلت المجموعة من PE مسحاج تخديد أن يساهم في واحد VPLS مجال، أو أنت يستطيع استعملت BGP أن يكتشف التشكيل تلقائيا. ولإجراء هذا الاكتشاف التلقائي، أعلنت BGP عن أي PE كان عضوا في مجال VPLS الخاص به. ومع ذلك، حتى مع الاكتشاف التلقائي لبروتوكول BGP، تم إستخدام بروتوكول LDP للإشارة إلى ملصقات الدائرة الظاهرية لتحويل التسمية متعدد البروتوكولات (MPLS) ومعرف التشفير.
من الممكن الآن إستخدام BGP للإشارة إلى الأسلاك الزائفة بين موجهات PE.
عند إعداد مجموعة زائفة بين زوج من الموجهات، فإن الموجهات الأخرى لا تحتاج إلى المعلومات المتعلقة بهذه المجموعة الزائفة. على سبيل المثال، مثل هذه المعلومات هي تسمية VC التي سيتم إستخدامها.
باستخدام LDP كبروتوكول إرسال الإشارات لإعداد أسلاك زائفة، يتم تلقي المعلومات فقط بواسطة زوج الموجهات، لأن LDP يقوم بالإشارات بطريقة من نقطة إلى نقطة.
باستخدام BGP كبروتوكول إرسال الإشارات لإعداد أسلاك زائفة، يتم تلقي المعلومات بواسطة جميع الموجهات الأخرى لأن BGP الداخلي (iBGP) يقوم بالإشارة بطريقة من نقطة إلى عدة نقاط. يتلقى iBGP متطلبات شبكة كاملة، لذلك يرسل موجه واحد تحديث iBGP إلى جميع موجهات iBGP الأخرى. كما يمكن القيام بذلك باستخدام عاكس مسار.
باستخدام iBGP كبروتوكول إرسال الإشارات، ستكون هناك طريقتان لإرسال التحديثات:
- يقوم كل موجه PE بالإعلان عن تحديث BGP واحد لجميع جيران iBGP لكل PW، ويتم في كل مرة إرفاق ملصق MPLS VC. وبالتالي، يرسل موجه PE واحد عدد تحديثات BGP يساوي عدد موجهات PE. ومع ذلك، يمكن إستخدام تسمية VC المرفقة بتحديث BGP من قبل موجه PE فقط - موجه PE في الطرف الآخر من PW.
- لتجنب هذه المشكلة الخاصة بعدد كبير من تحديثات BGP، تم تصميم بنية حيث يرسل موجه PE محلي مجموعة أو مجموعة من تسميات VC المحلية إلى جميع موجهات PE البعيدة. يختار كل موجه PE بعيد أحد تسميات VC لاستخدامها كتسمية VC بعيدة ل PW تجاه موجه PE المحلي. يجب أن ينتقي موجه PE البعيد تسمية VC عن بعد بشكل فريد حتى لا يختار أي موجه PE آخر نفس تسمية VC من مجموعة التسميات المعلن عنها. نظرا لأنه يتم إرسال مجموعة من التسميات، يجب أن يكون هناك تسميات كافية متوفرة لخدمة كافة علامات PW المحتملة التي يمكن إعدادها، ولكن يجب ألا يكون هناك العديد من التسميات المحجوزة بحيث لا يتم إستخدامها أو إهدارها.
يصف هذا المستند كيفية إستخدام بروتوكول BGP للإشارة إلى الأسلاك الظاهرية؛ لاحظ أن BGP يتم إستخدامه أيضا للاكتشاف التلقائي في نفس الوقت.
بنية الحل
لأن هذا VPLS، ما يزال هناك بروتوكول إرسال إشارات خطوة بخطوة مطلوب في القلب in order to حملت الربط المعنونة من PE إلى PE router. ويتعين على هندسة حركة مرور LDP أو MPLS تنفيذ وظيفة النقل هذه في المركز.
يحتاج BGP إلى إرسال المعلومات الضرورية من أجل إعداد الأسلاك الزائفة بطريقة من نقطة إلى عدة نقاط والتي تحتاجها VPLS. تتضمن معلومات الإرسال هذه:
- تعريف نقطة نهاية موجه PE
- VPLS الهوية
- كتلة تسميات MPLS
- معلومات التضمين
تعريف نقطة نهاية موجه PE
يتم تحديد تعريف نقطة نهاية موجه PE من موجه PE الذي هو مرسل BGP للتحديث.
يتم تعريف تحديث BGP المتعلق بالشبكات الخاصة الظاهرية (L2VPN) من الطبقة 2 بواسطة AFI/SAFI 25/65. يتم التفاوض على عائلة العناوين هذه عندما يرسل BGP الرسالة المفتوحة.
تسميات هوية VPLS و MPLS
يحمل NLRI، المعروف أيضا بالبادئة، المعلومات حول هوية VPLS وكتلة تسميات MPLS. ويبلغ طول ترميزه 19 بايت:
+------------------------------------+
| Length (2 octets) |
+------------------------------------+
| Route Distinguisher (8 octets) |
+------------------------------------+
| VE ID (2 octets) |
+------------------------------------+
| VE Block Offset (2 octets) |
+------------------------------------+
| VE Block Size (2 octets) |
+------------------------------------+
| Label Base (3 octets) |
+------------------------------------+
تتعلق أداة تمييز المسار (RD) بهوية مناطق VPLS.
يرتبط معرف التوسيع الظاهري (VE) ومقابل الكتلة VE وحجم الكتلة VE وقاعدة التسمية (LB) بكتلة التسميات المعلن عنها، كما هو موضح في القسم التالي.
معلومات التضمين
يتم إرفاق معلومات التضمين أيضا بالبادئة ويتم ترميزها كمجتمع موسع 'مجتمع معلومات الطبقة2 الموسع' إلى تحديث BGP. القيمة 0x800a ويتم تشفيرها على النحو التالي:
+------------------------------------+
| Extended community type (2 octets) |
+------------------------------------+
| Encaps Type (1 octet) |
+------------------------------------+
| Control Flags (1 octet) |
+------------------------------------+
| Layer-2 MTU (2 octet) |
+------------------------------------+
| Reserved (2 octets) |
+------------------------------------+
نوع التضمين ل VPLS هو 19.
يتم تشفير علامات التحكم (متجه البت) بهذه الطريقة:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |C|S| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+
| الاسم | القيمة | معنى |
| C | 1 | يجب أن تكون كلمة التحكم موجودة عند إرسال حزم VPLS إلى هذا PE. |
| 0 | يجب ألا تكون كلمة التحكم موجودة عند إرسال حزم VPLS إلى هذا PE. | |
| S | 1 | يجب إستخدام التسليم التسلسلي للإطارات عند إرسال حزم VPLS إلى هذا PE. |
| 0 | يجب عدم إستخدام التسليم التسلسلي للإطارات عند إرسال حزم VPLS إلى هذا PE. |
كما توجد أهداف مسار (RT) مرفقة بتحديث BGP. تتحكم RTs في الاستيراد إلى ال L2VPN والتصدير منه، بنفس الطريقة مثل MPLS L3VPN.
بادئة الاكتشاف التلقائي VPLS BGP وبادئة إرسال إشارات VPLS BGP
بادئة VPLS BGP Auto-Discovery هي بادئة /96، في حين أن بادئة إرسال إشارات VPLS BGP هي بادئة /136. وهذه أمثلة على كل منها:
PE2#show bgp l2vpn vpls all
BGP table version is 264, local router ID is 10.100.1.2
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,
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:100
*>i 1:100:VEID-1001:Blk-150/136
10.100.1.1 0 100 0 ?
*> 1:100:10.100.1.2/96
0.0.0.0 32768 ?
PE2#show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 150
BGP routing table entry for 1:100:VEID-1001:Blk-150/136, version 262
Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)
Not advertised to any peer
Refresh Epoch 1
Local
10.100.1.1 (metric 21) from 10.100.1.4 (10.100.1.4)
Origin incomplete, metric 0, localpref 100, valid, internal, best
AGI version(0), VE Block Size(50) Label Base(10105)
Extended Community: RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500
Originator: 10.100.1.1, Cluster list: 10.100.1.4
rx pathid: 0, tx pathid: 0x0
PE2#show bgp l2vpn vpls rd 1:100 10.100.1.2
BGP routing table entry for 1:100:10.100.1.2/96, version 43
Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)
Not advertised to any peer
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (10.100.1.2)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local,
best, AGI version(0)
Extended Community: RT:1:100 L2VPN AGI:1:100
rx pathid: 0, tx pathid: 0x0
نموذج تكوين برنامج Cisco IOS Software
هذا نموذج لتكوين برنامج Cisco IOS Software:
!
l2vpn vfi context one
vpn id 100
autodiscovery bgp signaling bgp <<< "signaling ldp" would be RFC 4762
ve id 1001
ve range 50
route-target export 32:64
route-target import 32:64
mpls label range 10000 20000
!
bridge-domain 1
member Ethernet0/0 service-instance 100
member vfi one
!
l2 router-id 10.100.1.1
!
interface Ethernet0/0
no ip address
service instance 100 ethernet
!
!
router bgp 1
bgp log-neighbor-changes
neighbor 10.100.1.4 remote-as 1
neighbor 10.100.1.4 update-source Loopback0
!
address-family l2vpn vpls
neighbor 10.100.1.4 activate
neighbor 10.100.1.4 send-community extended
neighbor 10.100.1.4 suppress-signaling-protocol ldp
exit-address-family
كتلة التسمية المعلن عنها
يجب أن يعلن موجه PE واحد عن كتلة تسمية واحدة على الأقل. كتلة التسمية هي مجموعة متصلة من تسميات MPLS ويتم إستخدامها من قبل موجهات PE البعيدة لتحديد تسمية VC بعيدة واحدة. يتم إستخدام التسمية البعيدة ل PW بين موجه PE المحلي والبعيد. (يمكن لموجه PE الإعلان عن كتل تسميات متعددة، كما هو موضح في الأقسام اللاحقة.)
يجب تكوين VE-ID على كل PE. وهو يحدد موجهات PE داخل مجال VPLS.
حجم كتلة VE (VBS) هو حجم كتلة التسمية وله قيمة افتراضية مقدارها 10. إذا تم تكوين 've range'، فإنها تلك القيمة. يمكن تكوين 've range' ليكون [11 -100].
قاعدة التسمية (LB) هي قيمة التسمية الأولى لمجموعة حرة من التسميات التي يمكن حجزها بواسطة موجه PE لاستخدامه لمجال VPLS هذا.
VE Block Offset (VBO) هي قيمة الإزاحة التي سيتم إستخدامها عندما يجب إنشاء كتل تسميات متعددة بواسطة موجه PE. يتم حساب VBO باستخدام هذه المعادلة: VBO = RND(VE-ID/VBS) * VBS
وهذه أمثلة على العمليات الحسابية:
- إذا كان VBS = 8 و VE-ID = 2، VBO = RND(2/8) * 8 = 1
- إذا كان VBS = 8 و VE-ID = 20، VBO = RND (20/8) * 8 = 16
- إذا كان VBS = 50 و VE-ID = 199، VBO = RND (199/50) * 50 = 150
- إذا كان VBS = 50 و VE-ID = 1002، VBO = RND (1002/50) * 50 = 1000
كتلة التسمية المعلن عنها لموجهات PE البعيدة هي {LB، LB + 1، ؟ و LB + VBS - 1}. يتم تعريف كتلة التسمية عن طريق LB و VBS، وتبدأ الكتلة من LB وتنتهي ب (LB + VBS - 1).
يمكن إنشاء كتل تسميات متعددة بواسطة كل موجه PE، عند الحاجة. يجب أن يضمن الموجه أنه مجموعة مستمرة من التسميات الحرة.
مميز المسار وأهداف المسار
مثال تكوين PE1
router bgp 1
l2vpn vfi context one
vpn id 100
autodiscovery bgp signaling bgp
ve id 1001
ve range 50
route-target export 32:64
route-target import 32:64
mpls label range 10000 20000
هذا شرح لقيم التكوين:
- تم تكوين معرف VPN على هيئة 100.
- يتم أخذ سطح المكتب البعيد من [معرف ASN:VPN]، ما لم يتم تكوين سطح المكتب البعيد بشكل صريح. هنا، الثالث هو 1:100.
- أهداف مسار الاستيراد/التصدير هي 32:64.
- اللوح من المدى [10000 20000]. تعتمد قيمة LB المحددة على المجموعة الأولى من التسميات المحلية المستمرة المجانية التي تكون كبيرة بما يكفي لضم كل التسميات التي تحددها VBS.
- تم تكوين VE-ID ك 1001.
- يتم تكوين VBS على هيئة 50.
- يتم حساب VBO على أنه: VBO = RND(VE-ID/VBS) * VBS أو RND(1001/50) * 50 = 1000.
فحص نطاق التسمية
يمكنك التحقق من نطاق التسمية باستخدام الأمر show mpls label range:
PE1#show mpls label range
Downstream Generic label region: Min/Max label: 10000/20000
هناك نطاق تسمية افتراضي حسب النظام الأساسي، والذي يمكنك تغييره باستخدام أمر نطاق تسمية MPLS.
فحص التسميات
يمكنك التحقق من التسميات المستخدمة الفعلية لكتلة تسمية واحدة في قاعدة معلومات إعادة توجيه التسمية (LFIB) باستخدام الأمر show mpls forwarding-table.
PE1#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop Label
Label or Tunnel Id Switched interface
10000 No Label lbl-blk-id(1:0) 0 drop
10001 No Label lbl-blk-id(1:1) 0 drop
10002 No Label lbl-blk-id(1:2) 0 drop
?
10048 No Label lbl-blk-id(1:48) 0 drop
10049 No Label lbl-blk-id(1:49) 0 drop
10050 Pop Label 10.100.1.4/32 0 Et1/0 10.1.1.4
في هذا المثال، قام PE1، الموجه المحلي، بحجز 50 تسمية محلية لكتلة التسمية. يعني "lbl-blk-id(1:0)" معرف الكتلة 1 ومثيل الكتلة 0، الذي يحدد التسمية الأولى للكتلة. التسمية الأخيرة لهذه الكتلة هي التسمية 10049.
تكون الواجهة 'الصادرة' في LFIB 'drop' طالما لم يتم إعداد PW لتلك التسمية المحلية. إذا تم إعداد PW، فإن الواجهة 'Outgoing' هي 'none point2point.'
فحص كتلة التسمية
كما يمكن التحقق من كتلة التسمية المعينة باستخدام الأمر show mpls infrastructure lfd block-database summary عند تكوين 'service internal'.
PE1#show mpls infrastructure lfd block-database summary
Block-DB entry for block-id : 0x1
Block-size : 50, App-Key type : AToM PWID, Labels : 10000 - 10049
LB هو 10000. في هذا المثال، كتلة التسمية من LB إلى (LB + VBS - 1) أو من 10000 إلى (10000 + 50 - 1) = 10049.
فحص البادئة المعلن عنها
يمكنك التحقق من البادئة المعلن عنها باستخدام الأمر show bgp l2vpn vpls rd 1:100:
PE1#show bgp l2vpn vpls rd 1:100
BGP table version is 3, local router ID is 10.100.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,
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:100
*> 1:100:VEID-1001:Blk-1000/136
0.0.0.0 32768 ?
عرض البادئة بالتفصيل
لعرض هذه البادئة بالتفصيل، أستخدم الأمر show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 1000. لاحظ أنك تحدد معرف VE وكتلة التسمية، والتي يمكن العثور عليها في NLRI (Blk-1000).
PE1#show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 1000
BGP routing table entry for 1:100:VEID-1001:Blk-1000/136, version 3
Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)
Advertised to update-groups:
1
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (10.100.1.1)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
AGI version(0), VE Block Size(50) Label Base(10000)
Extended Community: RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500
rx pathid: 0, tx pathid: 0x0
يعرض NLRI رقم 3 من 1:100، VE-ID من 1001، VBO من 1000، VBS من 50، و LB من 10000.
يحمل مجتمع معلومات الطبقة 2 الموسع هذه المعلومات:
- نوع ENCAP هو 19 (VPLS)
- علامات التحكم: C = 0 (يجب عدم تعيين كلمة التحكم)؛ S = 0 (لا يوجد تسليم متسلسل للإطارات)
- وحدة الحد الأقصى للنقل (MTU) تبلغ 1500
يحمل مجتمع RT الموسع هذه المعلومات:
- آر تي 1:100
- آر تي 32:64
الإعلان عن كتل التسمية واستقبالها ومعالجتها في رسائل تحديث BGP
عندما يعلن موجه PE محلي عن بادئة/كتلة تسمية VPN VPLS/L2VPN، يجب أن يحاول كل موجه PE بعيد انتقاء تسمية واحدة من ذلك النطاق للاستخدام كتسمية VC بعيدة.
- إذا نجح موجه PE البعيد، فإنه يستخدم تسمية VC البعيدة تلك ويبرمجها في مستوى البيانات. لا توجد إشارات أخرى بواسطة BGP.
- إذا فشل موجه PE عن بعد، فيجب عليه انتظار بادئة VPN VPLS أخرى من L2VPN ليتم الإعلان عنها بواسطة الموجه PE المحلي، ثم حاول انتقاء تسمية VC بعيدة أخرى من كتلة التسمية هذه.
بافتراض أن PE1 هو PE محلي باستخدام التكوين السابق وأن PE2 هو PE بعيد بهذا التكوين:
l2vpn vfi context one
vpn id 100
autodiscovery bgp signaling bgp
ve id 1002
ve range 50
!
mpls label range 3000 60000
PE2: تلقي تحديث BGP
يستقبل PE2 تحديث BGP هذا من PE1:
PE2#show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 1000
BGP routing table entry for 1:100:VEID-1001:Blk-1000/136, version 5
Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)
Not advertised to any peer
Refresh Epoch 2
Local
10.100.1.1 (metric 21) from 10.100.1.4 (10.100.1.4)
Origin incomplete, metric 0, localpref 100, valid, internal, best
AGI version(0), VE Block Size(50) Label Base(10000)
Extended Community: RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500
Originator: 10.100.1.1, Cluster list: 10.100.1.4
rx pathid: 0, tx pathid: 0x0
PE2: البحث عن تسمية
يحتاج PE2 إلى العثور على ملصق يمكنه إستخدامه كملصق VC بعيد ل PW باتجاه PE1.
يجب أن يحدد PE2 أولا ما إذا كان VBO ضمن نطاق التكوين الخاص به. يتحقق PE2 من VE-ID الخاص به مقابل النطاق المعلن عنه بواسطة PE1 باستخدام VBO الحسابي <= VBO-ID < VBO + VBS. في هذه الحالة، 1000 <= 1002 < 1000 + 50، وبالتالي ينجح PE2.
بعد ذلك، يحتاج PE2 إلى انتقاء تسمية VC عن بعد. يتم حساب تسمية المفكك (VC) التي سيتم إستخدامها من قبل PE البعيد على أنها (LB + VE-ID - VBO).
من البادئة السابقة، LB هو 10000، و VBO هو 1000. VE-ID هو واحد من PE2 وهو 1002. إذا، عنوان انتقاء PE2 (LB + VE-ID - VBO) = (10000 + 1002 - 1000) = 10002.
أستخدم الأمر show l2vpn vfi name one للتحقق من ذلك:
PE2#show l2vpn vfi name one
Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No
VFI name: one, state: up, type: multipoint, signaling: BGP
VPN ID: 100, VE-ID: 1002, VE-SIZE: 50
RD: 1:100, RT: 1:100
Bridge-Domain 100 attachment circuits:
Pseudo-port interface: pseudowire100001
Interface Peer Address VE-ID Local Label Remote Label S
pseudowire100002 10.100.1.1 1001 3101 10002 Y
PE2: إرسال البادئة إلى PE1
يرسل PE2 بعد ذلك البادئة إلى PE1:
PE1#show bgp l2vpn vpls rd 1:100 ve-id 1002 block-offset 1000
BGP routing table entry for 1:100:VEID-1002:Blk-1000/136, version 4
Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)
Not advertised to any peer
Refresh Epoch 1
Local
10.100.1.2 (metric 21) from 10.100.1.4 (10.100.1.4)
Origin incomplete, metric 0, localpref 100, valid, internal, best
AGI version(0), VE Block Size(50) Label Base(3100)
Extended Community: RT:1:100 L2VPN L2:0x0:MTU-1500
Originator: 10.100.1.2, Cluster list: 10.100.1.4
rx pathid: 0, tx pathid: 0x0
PE1: البحث عن تسمية
أصبح PE1 الآن هو PE البعيد ويحتاج إلى العثور على ملصق يمكن إستخدامه كملصق VC بعيد ل PW باتجاه PE2.
يجب أن يحدد PE1 أولا ما إذا كان VBO ضمن نطاق التكوين الخاص به. يتحقق PE1 من VE-ID الخاص به مقابل النطاق المعلن عنه بواسطة PE2 باستخدام VBO الحسابي <= VBO-ID < VBO + VBS. في هذه الحالة، 1000 <= 1001 < 1000 + 50، فينجح PE1.
بعد ذلك، يحتاج PE1 إلى انتقاء تسمية VC عن بعد. يتم حساب تسمية المفكك (VC) التي سيتم إستخدامها من قبل PE البعيد على أنها (LB + VE-ID - VBO).
من البادئة السابقة، LB هو 3100، و VBO هو 1000. VE-ID هو واحد من PE1 وهو 1001. إذا، عنوان انتقاء PE1 (LB + VE-ID - VBO) = (3100 + 1001 - 1000) = 3101.
أستخدم الأمر show l2vpn vfi name one للتحقق من ذلك:
PE1#show l2vpn vfi name one
Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No
VFI name: one, state: up, type: multipoint, signaling: BGP
VPN ID: 100, VE-ID: 1001, VE-SIZE: 50
RD: 1:100, RT: 1:100, 32:64
Bridge-Domain 1 attachment circuits:
Pseudo-port interface: pseudowire100001
Interface Peer Address VE-ID Local Label Remote Label S
pseudowire100002 10.100.1.2 1002 10002 3101 Y
أوامر التحقق الإضافية
PE1#show mpls l2transport vc detail
Local interface: VFI one vfi up
Interworking type is Ethernet
Destination address: 10.100.1.2, VC ID: 100, VC status: up
Output interface: Et1/0, imposed label stack {17 3101}
Preferred path: not configured
Default path: active
Next hop: 10.1.1.4
Create time: 02:06:08, last status change time: 02:06:08
Last label FSM state change time: 02:06:08
Signaling protocol: BGP
Status TLV support (local/remote) : Not Applicable
LDP route watch : Not Applicable
Label/status state machine : established, LruRru
Last local dataplane status rcvd: No fault
Last BFD dataplane status rcvd: Not Applicable
Last BFD peer monitor status rcvd: Not Applicable
Last local AC circuit status rcvd: No fault
Last local AC circuit status sent: No fault
Last local PW i/f circ status rcvd: No fault
Last local LDP TLV status sent: Not Applicable
Last remote LDP TLV status rcvd: Not Applicable
Last remote LDP ADJ status rcvd: Not Applicable
MPLS VC labels: local 10002, remote 3101
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Control Word: Off
Dataplane:
SSM segment/switch IDs: 8195/4097 (used), PWID: 3
VC statistics:
transit packet totals: receive 0, send 0
transit byte totals: receive 0, send 0
transit packet drops: receive 0, seq error 0, send 0
PE1#show mpls infrastructure lfd block-database id 1
Block-DB entry for block-id : 0x1
Block-size : 50, App-Key type : AToM PWID
App-Key entries:
l2ckt(1) 10000
l2ckt(2) 10001
l2ckt(3) 10002
l2ckt(4) 10003
l2ckt(5) 10004
l2ckt(6) 10005
l2ckt(7) 10006
l2ckt(8) 10007
l2ckt(9) 10008
l2ckt(10) 10009
l2ckt(11) 10010
l2ckt(12) 10011
l2ckt(13) 10012
l2ckt(14) 10013
l2ckt(15) 10014
l2ckt(16) 10015
l2ckt(17) 10016
l2ckt(18) 10017
l2ckt(19) 10018
l2ckt(20) 10019
l2ckt(21) 10020
l2ckt(22) 10021
l2ckt(23) 10022
l2ckt(24) 10023
l2ckt(25) 10024
l2ckt(26) 10025
l2ckt(27) 10026
l2ckt(28) 10027
l2ckt(29) 10028
l2ckt(30) 10029
l2ckt(31) 10030
l2ckt(32) 10031
l2ckt(33) 10032
l2ckt(34) 10033
l2ckt(35) 10034
l2ckt(36) 10035
l2ckt(37) 10036
l2ckt(38) 10037
l2ckt(39) 10038
l2ckt(40) 10039
l2ckt(41) 10040
l2ckt(42) 10041
l2ckt(43) 10042
l2ckt(44) 10043
l2ckt(45) 10044
l2ckt(46) 10045
l2ckt(47) 10046
l2ckt(48) 10047
l2ckt(49) 10048
l2ckt(50) 10049
PE1#show l2vpn atom vc destination 10.100.1.2
Service
Interface Dest Address VC ID Type Name Status
--------- --------------- ---------- ------ ------------------------ ----------
pw100002 10.100.1.2 100 vfi one UP
PE1#show l2vpn atom vc destination 10.100.1.2 detail
pseudowire100002 is up, VC status is up PW type: Ethernet
Create time: 02:11:13, last status change time: 02:11:13
Last label FSM state change time: 02:11:13
Destination address: 10.100.1.2 VC ID: 100
Output interface: Et1/0, imposed label stack {17 3101}
Preferred path: not configured
Default path: active
Next hop: 10.1.1.4
Member of vfi service one
Bridge-Domain id: 1
Service id: 0xe7000001
Signaling protocol: BGP
Local VE ID: 1001, Remote VE ID: 1002
Status TLV support (local/remote) : Not Applicable
LDP route watch : Not Applicable
Label/status state machine : established, LruRru
Local dataplane status received : No fault
BFD dataplane status received : Not Applicable
BFD peer monitor status received : Not Applicable
Status received from access circuit : No fault
Status sent to access circuit : No fault
Status received from pseudowire i/f : No fault
Status sent to network peer : Not Applicable
Status received from network peer : Not Applicable
Adjacency status of remote peer : Not Applicable
Bindings
Parameter Local Remote
------------ ------------------------------ ------------------------------
Label 10002 3101
Group ID 0 0
Interface
MTU 1500 1500
Control word off off
PW type Ethernet Ethernet
VCCV CV type 0x32 0x32
LSPV [2], BFD/Raw [5] LSPV [2], BFD/Raw [5]
BFD/Raw + sig [6] BFD/Raw + sig [6]
VCCV CC type 0x07 0x07
CW [1], RA [2], TTL [3] CW [1], RA [2], TTL [3]
Status TLV disabled N/A
Dataplane:
SSM segment/switch IDs: 8195/4097 (used), PWID: 3
Rx Counters
0 input transit packets, 0 bytes
0 drops, 0 seq err
Tx Counters
0 output transit packets, 0 bytes
0 drops
PE1#show l2vpn signaling rib rd 1:100
+- Origin of entry (i=iBGP/e=eBGP)
| +- Provisioned (Yes/No)?
| | +- Stale entry (Yes/No)?
| | |
v v v
O P S RD VE-ID VBO VBS LB Next-Hop
-+-+-+-----------------+-------+-------+-------+---------+-----------------+
i Y N 1:100 1002 1000 50 3100 10.100.1.2
PE1#show l2vpn signaling rib rd 1:100 detail
Route 1:100:1002 (epoch:0) from iBGP peer 10.100.1.2
Provisioned (Y) Stale (N)
Route-Target: 1:100
NLRI [FF000001]
VE-ID:1002 VBO:1000 VBS:50 LB:3100
MTU: 1500 Control Word: off
RIB Filter [27000002]
RD: 1:100
VE-ID: 1001, VBO: 1000, VBS: 50 LB: 10000
Forwarder [58000001] VFI one
PE1#show l2vpn atom pwid
AToM Pseudowire IDs: In use: 50, In holddown: 0
Label Peer-Address VCID PWID In-Use FirstUse ResuedAt FreedAt
------ --------------- ---------- ---------- ------ -------- -------- --------
10000 0.0.0.0 0 1 Yes 00:00:15 Never Never
10001 0.0.0.0 0 2 Yes 00:00:15 Never Never
10002 10.100.1.2 100 3 Yes 00:00:15 Never Never
10003 0.0.0.0 0 4 Yes 00:00:15 Never Never
10004 0.0.0.0 0 5 Yes 00:00:15 Never Never
PE1#show l2vpn atom summary
Destination address: 10.100.1.2, total number of vc: 1
0 unknown, 1 up, 0 down, 0 admin down, 0 recovering, 0 standby, 0 hotstandby
1 active vc on MPLS interface Et1/0
بادئات L2VPN VPLS المتعددة المعلن عنها بواسطة موجه PE لواحدة من شبكات VFI
من المحتمل أن يحتاج أحد مؤشرات الترابط (PE) إلى الإعلان عن وكالات تسميات متعددة لمثيل إعادة توجيه ظاهري (VFI) واحد.
إذا لم يكن معرف Ve-ID الخاص ب PE البعيد موجودا في النطاق المعلن عنه بواسطة PE المحلي، فلن يتمكن PE البعيد من انتقاء تسمية بعيدة ل PW. هذه العملية الحسابية، الموضحة مسبقا، هي VBO <= VE-ID < VBO + VBS.
في حالة فشل هذا الفحص، يكون معرف Ve-ID الخاص ب PE البعيد خارج النطاق. يتجاهل PE البعيد البادئة المستلمة من PE المحلي. يتعلم PE المحلي أن PE البعيد خارج النطاق عندما يستلم البادئة التي يقوم PE البعيد بالإعلان عنها. يحتاج PE المحلي إلى تحديد التسمية البعيدة التي يجب إستخدامها لموجه PE البعيد هذا. كما يرسل PE المحلي بادئة ثانية جديدة لمجموعة جديدة من التسميات المحلية إلى PE البعيد، والتي يجب أن يكون PE البعيد قادرا على إستخدامها لتحديد تسمية بعيدة.
تكوين PE1
المثال السابق يستمر هنا، والخيار 1 لا يزال يحتوي:
l2vpn vfi context one
vpn id 100
autodiscovery bgp signaling bgp
ve id 1001
ve range 50
route-target export 32:64
route-target import 32:64
!
mpls label range 10000 20000
تكوين PE2
يحتوي PE2 الآن على VE-ID لعام 1002 وهذا التكوين:
l2vpn vfi context one
vpn id 100
autodiscovery bgp signaling bgp
ve id 10002
ve range 50
!
mpls label range 3000 60000
كتل التسمية الأولية
يبدأ كل من PE1 و PE2 بكتل التسميات الأولية هذه.
PE1#show bgp l2vpn vpls rd 1:100
BGP table version is 2, local router ID is 10.100.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,
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:100
*> 1:100:VEID-1001:Blk-1000/136
0.0.0.0 32768 ?
PE2#show bgp l2vpn vpls rd 1:100
BGP table version is 3, local router ID is 10.100.1.2
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,
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:100
*> 1:100:VEID-10002:Blk-10000/136
0.0.0.0 32768 ?
تبادل PE1 و PE2
أستخدم الأمر debug bgp l2vpn vpls update لمراجعة تبادل PE1 و PE2، ثم أستخدم الأمر show bgp l2vpn vpls rd 1:100 لمراجعة التفاصيل.
PE1#
%BGP-5-ADJCHANGE: neighbor 10.100.1.4 Up
BGP(9): update formatted for 1:100:VEID-1001:Blk-1000:VBS-50:LB-10000/136 VE ID
1001 VE Block Offset 1000 VE Block Size 50 Label Base 10000 /136
BGP(9): (base) 10.100.1.4 send UPDATE (format) 1:100:VEID-1001:Blk-1000:VBS-50:
LB-10000/136, next 10.100.1.1, metric 0, path Local, extended community RT:1:100
RT:32:64 L2VPN L2:0x0:MTU-1500
BGP(9): 10.100.1.4 rcvd UPDATE w/ attr: nexthop 10.100.1.2, origin ?,
localpref 100, metric 0, originator 10.100.1.2, clusterlist 10.100.1.4, extended
community RT:1:100 L2VPN L2:0x0:MTU-1500
BGP(9): 10.100.1.4 rcvd 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136
BGP(9): bump net 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136, non bpath added
BGP(9): nettable_walker called for 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136
BGP(9): best path[0] 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136 source
10.100.1.1 nh 10.100.1.2 vpls-id: L2VPN L2:0x0:MTU-1500
BGP(9): add XC RIB route 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136 masklen 136
L2VPN L2:0x0:MTU-1500 pathcount: 1 [0] LDP source:10.100.1.1 nexthop:10.100.1.2
RT:1:100
BGP(9): bump net 1:100:VEID-1001:Blk-10000:VBS-50:LB-10053/136, non bpath added
BGP(9): nlri update add VBS 50 LB 10053
BGP(9): nlri update add export extcomm count 4
BGPSSA ssacount is 0
BGP(9): update formatted for 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136 VE ID
10002 VE Block Offset 10000 VE Block Size 50 Label Base 3000 /136
BGP(9): nettable_walker called for 1:100:VEID-1001:Blk-10000:VBS-50:LB-10053/136
BGP(9): nettable_walker 1:100:VEID-1001:Blk-10000:VBS-50:LB-10053/136 route sourced
locally
BGP(9): update formatted for 1:100:VEID-1001:Blk-10000:VBS-50:LB-10053/136 VE ID
1001 VE Block Offset 10000 VE Block Size 50 Label Base 10053 /136
BGP(9): (base) 10.100.1.4 send UPDATE (format) 1:100:VEID-1001:Blk-10000:VBS-50:
LB-10053/136, next 10.100.1.1, metric 0, path Local, extended community RT:1:100
RT:32:64 L2VPN L2:0x0:MTU-1500 L2VPN L2:0x0:MTU-1500
BGP(9): 10.100.1.4 rcvd UPDATE w/ attr: nexthop 10.100.1.2, origin ?, localpref 100,
metric 0, originator 10.100.1.2, clusterlist 10.100.1.4, extended community
RT:1:100 L2VPN L2:0x0:MTU-1500
BGP(9): 10.100.1.4 rcvd 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136
BGP(9): bump net 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136, non bpath added
BGP(9): nettable_walker called for 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136
BGP(9): best path[0] 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136 source 10.100.1.1
nh 10.100.1.2 vpls-id: L2VPN L2:0x0:MTU-1500
BGP(9): add XC RIB route 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136 masklen 136
L2VPN L2:0x0:MTU-1500 pathcount: 1 [0] LDP source:10.100.1.1 nexthop:10.100.1.2
RT:1:100
BGP(9): update formatted for 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136 VE ID
10002 VE Block Offset 1000 VE Block Size 50 Label Base 3053 /136
BGPSSA ssacount is 0
PE1#show bgp l2vpn vpls rd 1:100
BGP table version is 5, local router ID is 10.100.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,
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:100
*> 1:100:VEID-1001:Blk-1000/136
0.0.0.0 32768 ?
*> 1:100:VEID-1001:Blk-10000/136
0.0.0.0 32768 ?
*>i 1:100:VEID-10002:Blk-1000/136
10.100.1.2 0 100 0 ?
*>i 1:100:VEID-10002:Blk-10000/136
10.100.1.2 0 100 0 ?
PE2#show bgp l2vpn vpls rd 1:100
BGP table version is 6, local router ID is 10.100.1.2
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,
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:100
*>i 1:100:VEID-1001:Blk-1000/136
10.100.1.1 0 100 0 ?
*>i 1:100:VEID-1001:Blk-10000/136
10.100.1.1 0 100 0 ?
*> 1:100:VEID-10002:Blk-1000/136
0.0.0.0 32768 ?
*> 1:100:VEID-10002:Blk-10000/136
0.0.0.0 32768 ?
تحليل تبادل PE1 و PE2
لقد أعلن PE1 و PE2 الآن عن وحدتي ملصقات لكل منهما للأخرى.
يعلن PE1 أولا عن تحديث BGP أولي إلى PE2:
BGP(9): update formatted for 1:100:VEID-1001:Blk-1000:VBS-50:LB-10000/136 VE ID
1001 VE Block Offset 1000 VE Block Size 50 Label Base 10000 /136
BGP(9): (base) 10.100.1.4 send UPDATE (format) 1:100:VEID-1001:Blk-1000:VBS-50:
LB-10000/136, next 10.100.1.1, metric 0, path Local, extended community
RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500
يحتوي هذا التحديث على تعيين NLRI وفقا للتكوين على PE1.
ثم يستقبل PE1 تحديث BGP الأولي من PE2.
BGP(9): 10.100.1.4 rcvd UPDATE w/ attr: nexthop 10.100.1.2, origin ?, localpref
100, metric 0, originator 10.100.1.2, clusterlist 10.100.1.4, extended
community RT:1:100 L2VPN L2:0x0:MTU-1500
BGP(9): 10.100.1.4 rcvd 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136
يعلن PE2 عن البادئة الأولية مع القيم VE-ID 10002، VBO = 10000، VBS = 50، LB = 3000.
يشير PE1 إلى أن PE2 خارج النطاق منذ بدء تشغيل PE1 باستخدام كتلة التسمية من LB إلى (LB + VBS - 1) أو من 10000 إلى (10000 + 50 - 1) = 10049.
يجب أن يحدد PE1 ما إذا كان VBO ضمن نطاق التكوين الخاص به. لذلك، يجب التحقق من معرف Ve-ID الخاص ب PE2 مقابل النطاق المعلن عنه بواسطة PE1. العملية الحسابية هي VBO <= VE-ID < VBO + VBS. في هذه الحالة، 1000 <= 10002 < 1000 + 50، وهذا غير صحيح. لذلك، يحتاج PE1 لإرسال كتلة تسمية جديدة من أجل إستيعاب VE-ID خارج النطاق ل PE2. كرد فعل للتحديث الأولي من PE2، يقوم PE1 بتنسيقات وإرسال تحديث BGP جديد إضافي إلى PE2. يستخدم PE1 الآن شبكة VBO جديدة تتكون من 10000.
BGP(9): update formatted for 1:100:VEID-1001:Blk-10000:VBS-50:LB-10053/136
VE ID 1001 VE Block Offset 10000 VE Block Size 50 Label Base 10053 /136
BGP(9): (base) 10.100.1.4 send UPDATE (format) 1:100:VEID-1001:Blk-10000:
VBS-50:LB-10053/136, next 10.100.1.1, metric 0, path Local, extended
community RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500 L2VPN L2:0x0:MTU-1500
ل PE1، ال VBO 10000، VBS 50، LB هو 10053. إن التحقق من PE2 هو VBO <= VE-ID < VBO + VBS. في هذه الحالة، 10000 <= 10002 < 10000 + 50، وهذا صحيح. يمكن ل PE2 انتقاء تسمية عن بعد من كتلة التسمية الجديدة هذه [10053 - 10102] من PE1. وبمعنى آخر، أضاف PE1 كتلة تسمية جديدة لاستيعاب PE2 وأرسل رسالتين لتحديث BGP.
ويحدث نفس الشيء في الإتجاه المعاكس. يستقبل PE2 تحديث BGP الأولي من PE1. يحتوي هذا التحديث على هذه القيم VE-ID 1001، VBO = 1000، VBS = 50، LB = 10000.
يشير PE2 إلى أن VE-ID ل PE1 خارج النطاق مع التحديث الأولي ل PE2. التحقق من PE1 هو VBO <= VE-ID </VBO + VBS أو 10000 <= 1001 </10000 + 50. وفي إستجابة لذلك، يرسل PE2 هذا التحديث الثاني لبروتوكول BGP، مع كتلة تسمية جديدة [3053 - 3102] التي تستوعب معرف VE الخاص ب 1001 من PE1 لأن التحقق من نوع PE1 هو VBO <= VBO-ID </VBO + VBS أو 1000 <= 1001 </1000 + 50.
BGP(9): 10.100.1.4 rcvd UPDATE w/ attr: nexthop 10.100.1.2, origin ?,
localpref 100, metric 0, originator 10.100.1.2, clusterlist 10.100.1.4,
extended community RT:1:100 L2VPN L2:0x0:MTU-1500
BGP(9): 10.100.1.4 rcvd 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136
تفاصيل البادئة
هذه تفاصيل البادئات التي تم إنشاؤها بواسطة PE1:
PE1#show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 1000
BGP routing table entry for 1:100:VEID-1001:Blk-1000/136, version 2
Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)
Not advertised to any peer
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (10.100.1.1)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
AGI version(0), VE Block Size(50) Label Base(10000)
Extended Community: RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500
rx pathid: 0, tx pathid: 0x0
PE1#show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 10000
BGP routing table entry for 1:100:VEID-1001:Blk-10000/136, version 4
Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)
Not advertised to any peer
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (10.100.1.1)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
AGI version(0), VE Block Size(50) Label Base(10053)
Extended Community: RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500
L2VPN L2:0x0:MTU-1500
rx pathid: 0, tx pathid: 0x0
هنا، يحتوي موجهان من موجهات PE على مخططات أرقام منفصلة، مما يتسبب في إرسال كل PE تحديثين BGP. إذا كان هناك العديد من موجهات PE ذات مخططات الأرقام غير المتصلة، فإن عدد تحديثات BGP ينمو بسرعة كبيرة للغاية.
يقول www.cisco.com: على سبيل المثال، إن تسلسل أرقام VE-ID مثل 1، 2، 3 أو 501، 502، 503 جيد لأن معرفات VE متصلة. مخطط الترقيم مثل 100 و 200 و 300 سيئ لأنه غير متصل.
الأمثلة الأولى من 1 أو 2 أو 3 أو 501 أو 502 أو 503 هي أرقام متصلة، لذلك يحتاج كل موجه PE إلى إرسال بادئة L2VPN VPLS واحدة فقط. مع المثال الثالث (100 و 200 و 300)، يجب على كل PE إرسال العديد من بادئات L2VPN VPLS. بالنسبة للأرقام غير المتتالية، فإن نطاق VE الكبير يكفي يبقي عدد البادئات التي يتم الإعلان عنها أقل. ومع ذلك، فإن مقدار التسميات المحجوزة (المهدرة) لا يزال أكبر.
قابلية التشغيل البيني
إذا كان عاكس مسار BGP (RR) يشغل برنامجا لا يفهم RFC 4761، ولكنه يتلقى دعم RFC 4762، فإن أمر التكوين الخاص المجاور BGP x.x.x.x prefix-length-size 2 يكون ضروريا على RR بحيث يمكن أن يعكس تحديثات BGP المستخدمة ل RFC 4761.
يتم إرسال البادئات عادة بطول 1 بايت. قام برنامج Cisco IOS software بتنفيذ مسودة 'draft-ietf-l2vpn-signaling-08'، والتي أصبحت فيما بعد RFC 6074. تم إختيار حقل طول مكون من 1 بايت في ذلك الوقت، يشير إلى الطول في وحدات بت.
يحدد التوفير والاكتشاف التلقائي وإرسال الإشارات من الطبقة 2 للشبكات الخاصة الظاهرية (L2VPNs) وفقا لمعيار RFC 6074 أن يكون تشفير NLRI للاكتشاف التلقائي لبروتوكول BGP طوله 2 بايت. تشير 2 بايت إلى عدد وحدات البايت للبادئة في بادئة طول متغيرة.
يذكر القسم 7 من RFC 6074، "التوافق بين بروتوكول بوابة الحدود (BGP) وبروتوكول بوابة الحدود (VPLS-BGP)":
"يستخدم كل من BGP-ad و VPLS-BGP [RFC4761] نفس AFI/FI. in order for على حد سواء BGP-AD و VPLS-BGP أن يتواجد، ال NLRI طول ينبغي استعملت كمفكك.
يبلغ طول NLRI لبروتوكول BGP-AD 12 بايت، ويحتوي فقط على RD سعة 8 بايت ومعرف VSI-ID سعة 4 بايت. يستخدم VPLS-BGP [RFC4761] طول NLRI يبلغ 17 بايت. لذلك، يجب أن تتجاهل عمليات تنفيذ BGP-AD NLRI التي تزيد عن 12 بايت.
إذا لم يكن الأمر المجاور x.x.x.x prefix-length-size 2 موجودا على نقاط الوصول عن بعد، فإن جار BGP لا يظهر، ويفسر RR حقل الطول على أنه 1 بايت فقط. يظهر هذا الإعلام على RR:
%BGP-3-NOTIFICATION: sent to neighbor 10.100.1.2 3/10 (illegal network) 1 bytes FF
%BGP-4-MSGDUMP: unsupported or mal-formatted message received from 10.100.1.2:
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 005E 0200 0000 4780 0E1C 0019 4104 0A64
0102 0000 1100 0000 0100 0000 6427 1227 1000 3200 BB80 4001 0102 4002 0080 0404
*Feb 15 12:14:11.561: %BGP_SESSION-5-ADJCHANGE: neighbor 10.100.1.2 L2VPN Vpls
topology base removed from session BGP Notification sent
*Feb 15 12:14:11.561: %BGP_SESSION-5-ADJCHANGE: neighbor 10.100.1.2 IPv4 Unicast
topology base removed from session BGP Notification sent
يظهر هذا الإعلام على موجه PE:
%BGP-3-NOTIFICATION: received from neighbor 10.100.1.4 3/10 (illegal network)
1 bytes FD
يحدث هذا لأنه، في التنفيذ الأصلي للاكتشاف التلقائي BGP في برنامج Cisco IOS، كان حقل الطول 1 بايت.
إذا قمت بوضع الأمر المجاور x.x.x.x prefix-length-size 2 على RR، فلن تظهر الإعلامات.
router bgp 1
neighbor 10.100.1.2 remote-as 1
neighbor 10.100.1.2 update-source Loopback0
!
address-family l2vpn vpls
neighbor 10.100.1.2 activate
neighbor 10.100.1.2 send-community extended
neighbor 10.100.1.2 prefix-length-size 2
neighbor 10.100.1.2 route-reflector-client
التعليقات