تنفيذ IOS لميزة iBGP PE-CE

خيارات التنزيل

PDF (578.2 KB)
عرض باستخدام Adobe Reader على مجموعة متنوعة من الأجهزة
ePub (175.6 KB)
العرض في تطبيقات مختلفة على iPhone أو iPad أو نظام تشغيل Android أو قارئ Sony أو نظام التشغيل Windows Phone
Mobi (Kindle) (179.5 KB)
عرض على جهاز Kindle أو تطبيق Kindle على أجهزة متعددة

تم التحديث:٤ أبريل ٢٠١٤

معرّف المستند:117567

لغة خالية من التحيز

تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.

حول هذه الترجمة

ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).

المحتويات

المقدمة

معلومات أساسية

تنفيذ بروتوكول iBGP PE-CE

سمة مسار عميل BGP

التكوين

أمر جديد

نظرة مفصلة على ATTR_SET

معالجة الخطوة التالية

ميزة iBGP PE-CE مع نظام التشغيل المحلي

قواعد تبادل المسار بين مواقع VRF المختلفة

انعكاس VRF-Lite من CE-to-CE

برنامج Cisco IOS الأقدم على موجه PE

Next-hop-self ل eBGP على VRF

المقدمة

يوضح هذا المستند كيفية تنفيذ بروتوكول العبارة الحدودية الداخلية (iBGP) بين ميزة Provider Edge (PE) و Customer Edge (CE) في برنامج Cisco IOS^®.

معلومات أساسية

وحتى ميزة eBGP PE-CE الجديدة، لم يتم دعم iBGP بين PE و CE (وبالتالي على واجهة التوجيه وإعادة التوجيه الظاهري (VRF) على موجه PE) بشكل رسمي. أحد الاستثناءات هي iBGP على واجهات VRF في إعداد CE متعدد VRF (VRF-Lite). الدافع لنشر هذه الميزة هو:

يريد العميل الحصول على رقم نظام مستقل واحد (ASN) على مواقع متعددة ل VRF، دون نشر بروتوكول العبارة الحدودية الخارجية (eBGP) الذي يتضمن التجاوز.
يريد العميل توفير انعكاس مسار داخلي باتجاه موجهات CE، حيث يعمل كما لو كان مركز مزود الخدمة (SP) هو عاكس مسار واحد شفاف (RR).

باستخدام هذه الميزة، يمكن أن تحتوي مواقع VRF على نفس ASN الخاص بمركز SP. ومع ذلك، في حالة أختلاف ASN لمواقع VRF عن ASN الخاص ب SP core، يمكن جعلها تظهر بشكل مماثل باستخدام ميزة النظام الذاتي المحلي (AS).

تنفيذ بروتوكول iBGP PE-CE

فيما يلي الجزءان الرئيسيان لجعل هذه الميزة تعمل:

تمت إضافة سمة جديدة ATTR_SET إلى بروتوكول BGP لحمل سمات VPN BGP عبر لب SP بطريقة شفافة.
جعل موجه PE موجهات RR لجلسات عمل iBGP تجاه موجهات CE في VRF وك RR نحو جيران VPNv4 (موجهات PE أو RRs الأخرى).

تتيح سمة ATTR_SET الجديدة ل SP حمل جميع سمات BGP الخاصة بالعميل بطريقة شفافة ولا تتعارض مع سمات SP ونهج BGP. هذه السمات هي قائمة المجموعات، والتفضيل المحلي، والمجتمعات، وما إلى ذلك.

سمة مسار عميل BGP

ATTR_SET هي سمة BGP الجديدة المستخدمة لحمل سمات VPN BGP الخاصة بعميل SP. إنها سمة انتقالية إختيارية. في هذه السمة، يمكن حمل جميع سمات BGP للعميل من رسالة تحديث BGP، باستثناء سمات MP_REACH و MP_UNREACH.

تحتوي سمة ATTR_SET على هذا التنسيق:

 
                      +------------------------------+
                      | Attr Flags (O|T) Code = 128  |
                      +------------------------------+
                      | Attr. Length (1 or 2 octets) |
                      +------------------------------+
                      | Origin AS (4 octets)         |
                      +------------------------------+
                      | Path Attributes (variable)   |
                      +------------------------------+

علامات السمة هي علامات سمة BGP العادية (راجع RFC 4271). يشير طول السمة إلى ما إذا كان طول السمة ثمانية واحد أو إثنين. والغرض من حقل الأصل AS هو منع تسريب أحد المسارات الذي تم إنشاؤه في أحد AS ليتم تسريبه إلى آخر AS دون التلاعب المناسب في AS_PATH. يحمل حقل سمات مسار الطول المتغير سمات VPN BGP التي يجب نقلها عبر لب SP.

على موجه PE المخرج، يتم دفع سمات VPN BGP إلى هذه السمة. على موجه PE المدخل، يتم فصل هذه السمات من السمة، قبل إرسال بادئة BGP إلى موجه CE. توفر هذه السمة عزل سمات BGP بين شبكة SP وشبكة VPN الخاصة بالعميل والعكس. على سبيل المثال، لا يتم عرض سمة قائمة مجموعات انعكاس مسار بروتوكول SP والنظر فيها داخل شبكة VPN. ولكن أيضا، لا يتم عرض سمة قائمة مجموعات انعكاس مسار الشبكة الخاصة الظاهرية (VPN) والنظر فيها داخل شبكة SP.

انظر الشكل 1 لعرض نشر بادئة BGP للعميل عبر شبكة SP.

شكل 1

CE1 و CE2 في نفس شبكة SP: 65000. يحتوي PE1 على بروتوكول iBGP مكون نحو CE1. يعكس PE1 مسار البادئة 10.100.1.1/32 نحو RR في شبكة SP. يعكس RR مسار iBGP نحو موجهات PE كالمعتاد. يعكس PE2 المسار نحو CE2.

لكي يعمل هذا بشكل صحيح، يجب:

تحتوي على رمز في PE1 و PE2 يحتوي على دعم ميزة iBGP PE-CE
قم بتكوين PE1 و PE2 لإجراء انعكاس المسار على جلسة BGP الخاصة بهم نحو موجهات CE المعنية
احصل على الخطوة التالية على موجهات PE لجلسة BGP تجاه موجهات CE الخاصة بها
تأكد من أن كل موقع من مواقع شبكات VPN يستخدم أدوات تمييز مسار مختلفة (RD)

التكوين

ارجع إلى الشكل 1.

فيما يلي التكوين المطلوب ل PE1 و PE2:

PE1

vrf definition customer1
 rd 65000:1
 route-target export 1:1
 route-target import 1:1
 !
 address-family ipv4
 exit-address-family

router bgp 65000
 bgp log-neighbor-changes
 neighbor 192.168.100.3 remote-as 65000
 neighbor 192.168.100.3 update-source Loopback0
 !
 address-family vpnv4
  neighbor 192.168.100.3 activate
  neighbor 192.168.100.3 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf customer1
  neighbor 10.1.1.4 remote-as 65000
  neighbor 10.1.1.4 activate
  neighbor 10.1.1.4 internal-vpn-client
  neighbor 10.1.1.4 route-reflector-client
  neighbor 10.1.1.4 next-hop-self
 exit-address-family

PE2

vrf definition customer1
 rd 65000:2
 route-target export 1:1
 route-target import 1:1
 !
 address-family ipv4
 exit-address-family

router bgp 65000
 bgp log-neighbor-changes
 neighbor 192.168.100.3 remote-as 65000
 neighbor 192.168.100.3 update-source Loopback0
 !
 address-family vpnv4
  neighbor 192.168.100.3 activate
  neighbor 192.168.100.3 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf customer1
  neighbor 10.1.2.5 remote-as 65000
  neighbor 10.1.2.5 activate
  neighbor 10.1.2.5 internal-vpn-client
  neighbor 10.1.2.5 route-reflector-client
  neighbor 10.1.2.5 next-hop-self
 exit-address-family

ملاحظة: إذا لم يكن ل PE الأمر المجاور <internal-CE> internal-vpn-client لجارة CE، فإنه لا ينشر البادئات من CE إلى موجهات SP RRs/PE.

ملاحظة: إذا لم يكن PE هو RR في VRF، فإنه لا ينشر البادئات من موجهات RRs/PE نحو موجه CE.

أمر جديد

هناك أمر جديد، مجاور <internal-CE> داخلي-VPN-client، لجعل هذه الميزة تعمل. يجب تكوينها على موجه PE فقط لجلسة عمل iBGP تجاه موجهات CE.

ملاحظة: لا تزال ميزة iBGP PE-CE المتعدد VRF CE (VRF-Lite) مدعومة دون الأمر المجاور <internal-CE> internal-vpn-client.

ملاحظة: عند تكوين الأمر المجاور <internal-CE> internal-vpn-client، يتم وضع أوامر المجاور <internal-CE> route-reflector-client وneighbor <internal-CE> next-hop-self تلقائيا في التكوين أيضا. عندما يكون أي من المجاور <internal-CE> route-reflector-client ومجاور <internal-CE> next-hop-self أمر (أو كلا) أزلت ويتم إعادة تحميل، بعد ذلك هم تلقائيا وضعت في التشكيل.

نظرة مفصلة على ATTR_SET

ارجع إلى الشكل 1.

هذه هي البادئة التي يعلن عنها بواسطة CE1:

CE1#show bgp ipv4 unicast 10.100.1.1/32
BGP routing table entry for 10.100.1.1/32, version 2
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     4         
  Refresh Epoch 1
  Local
    0.0.0.0 from 0.0.0.0 (10.100.1.1)
      Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
      rx pathid: 0, tx pathid: 0x0

عندما يستقبل PE1 بادئة BGP 10.100.1.1/32 من CE1، فإنه يخزنها مرتين:

PE1#show bgp vpnv4 unicast all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 21
Paths: (2 available, best #1, table customer1)
  Advertised to update-groups:
     5         
  Refresh Epoch 1
  Local, (Received from ibgp-pece RR-client)
    10.1.1.4 (via vrf customer1) from 10.1.1.4 (10.100.1.1)
      Origin IGP, metric 0, localpref 200, valid, internal, best
      mpls labels in/out 18/nolabel
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  Local, (Received from ibgp-pece RR-client), (ibgp sourced)
    10.1.1.4 (via vrf customer1) from 10.1.1.4 (10.100.1.1)
      Origin IGP, localpref 100, valid, internal
      Extended Community: RT:1:1
      mpls labels in/out 18/nolabel
      rx pathid: 0, tx pathid: 0

المسار الأول هو المسار الفعلي على PE1، لأنه يتم إستقباله من CE1.

المسار الثاني هو المسار المعلن عنه تجاه موجهات RR/PE. يتم وضع علامة عليه ب ibgp sourced. يحتوي على سمة ATTR_SET. لاحظ أن هذا المسار له هدف مسار (RT) واحد أو أكثر مرتبط به.

يعلن PE1 عن البادئة كما هو موضح هنا:

PE1#show bgp vpnv4 unicast all neighbors 192.168.100.3 advertised-routes 
BGP table version is 7, local router ID is 192.168.100.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: 65000:1 (default for vrf customer1)
 *>i 10.100.1.1/32    10.1.1.4                 0    200      0 i

Total number of prefixes 1

هذه هي الطريقة التي يرى بها RR المسار:

RR#show bgp vpnv4 un all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 10
Paths: (1 available, best #1, no table)
  Advertised to update-groups:
     3         
  Refresh Epoch 1
  Local, (Received from a RR-client)
    192.168.100.1 (metric 11) (via default) from 192.168.100.1 (192.168.100.1)
      Origin IGP, localpref 100, valid, internal, best
      Extended Community: RT:1:1
      Originator: 10.100.1.1, Cluster list: 192.168.100.1
      ATTR_SET Attribute: 
        Originator AS 65000
        Origin IGP
        Aspath 
        Med 0
        LocalPref 200
        Cluster list 
        192.168.100.1, 
        Originator 10.100.1.1
      mpls labels in/out nolabel/18
      rx pathid: 0, tx pathid: 0x0

لاحظ أن التفضيل المحلي لبادئة البث الأحادي VPNv4 هذه في المركز هو 100. في ATTR_SET، يتم تخزين التفضيل المحلي الأصلي ل 200. ومع ذلك، فهذا يعد أمرا شفافا بالنسبة إلى RR في مركز SP.

في PE2، ترى البادئة كما هو موضح هنا:

PE2#show bgp vpnv4 unicast all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 5
Paths: (1 available, best #1, no table)
  Not advertised to any peer
  Refresh Epoch 2
  Local
    192.168.100.1 (metric 21) (via default) from 192.168.100.3 (192.168.100.3)
      Origin IGP, localpref 100, valid, internal, best
      Extended Community: RT:1:1
      Originator: 10.100.1.1, Cluster list: 192.168.100.3, 192.168.100.1
      ATTR_SET Attribute: 
        Originator AS 65000
        Origin IGP
        Aspath 
        Med 0
        LocalPref 200
        Cluster list 
        192.168.100.1, 
        Originator 10.100.1.1
      mpls labels in/out nolabel/18
      rx pathid: 0, tx pathid: 0x0
BGP routing table entry for 65000:2:10.100.1.1/32, version 6
Paths: (1 available, best #1, table customer1)
  Advertised to update-groups:
     1         
  Refresh Epoch 2
  Local, imported path from 65000:1:10.100.1.1/32 (global)
    192.168.100.1 (metric 21) (via default) from 192.168.100.3 (192.168.100.3)
      Origin IGP, metric 0, localpref 200, valid, internal, best
      Originator AS(ibgp-pece): 65000
      Originator: 10.100.1.1, Cluster list: 192.168.100.1
      mpls labels in/out nolabel/18
      rx pathid:0, tx pathid: 0x0

المسار الأول هو المسار الذي تم إستقباله من RR، باستخدام ATTR_SET. لاحظ أن RD هو 65000:1، تاريخ الأصل. المسار الثاني هو المسار المدرج من جدول VRF مع RD 65000:1. تمت إزالة ATTR_SET.

هذا هو المسار كما يرى في CE2:

CE2#show bgp ipv4 unicast 10.100.1.1/32
BGP routing table entry for 10.100.1.1/32, version 10
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.1.2.2 from 10.1.2.2 (192.168.100.2)
      Origin IGP, metric 0, localpref 200, valid, internal, best
      Originator: 10.100.1.1, Cluster list: 192.168.100.2, 192.168.100.1
      rx pathid: 0, tx pathid: 0x0

لاحظ أن الخطوة التالية هي 10.1.2.2، وهي PE2. تحتوي قائمة نظام المجموعة على الموجهات PE1 و PE2. هذه هي وحدات الاستجابة السريعة (RRs) التي تشكل أهمية داخل الشبكة الخاصة الظاهرية (VPN). لم يتم إدراج SP RR (10.100.1.3) في قائمة المجموعات.

تم الاحتفاظ بالتفضيل المحلي ل 200 داخل شبكة VPN عبر شبكة SP.

يعرض أمر تحديثات البث الأحادي debug bgp vpnv4 التحديث الذي تم نشره في شبكة SP:

PE1#
BGP(4): Revise route installing 1 of 1 routes for 10.100.1.1/32 -> 10.1.1.4
(customer1) to customer1 IP table
BGP(4): 192.168.100.3 NEXT_HOP changed SELF for ibgp rr-client pe-ce net
65000:1:10.100.1.1/32, 
BGP(4): 192.168.100.3 Net 65000:1:10.100.1.1/32 from ibgp-pece 10.1.1.4 format
ATTR_SET
BGP(4): (base) 192.168.100.3 send UPDATE (format) 65000:1:10.100.1.1/32, next
192.168.100.1, label 16, metric 0, path Local, extended community RT:1:1
BGP: 192.168.100.3 Next hop is our own address 192.168.100.1
BGP: 192.168.100.3 Route Reflector cluster loop; Received cluster-id 192.168.100.1
BGP: 192.168.100.3 RR in same cluster. Reflected update dropped

RR#
BGP(4): 192.168.100.1 rcvd UPDATE w/ attr: nexthop 192.168.100.1, origin i, localpref
100, originator 10.100.1.1, clusterlist 192.168.100.1, extended community RT:1:1,
[ATTR_SET attribute:  originator AS 65000, origin IGP, aspath , med 0, localpref 200,
cluster list 192.168.100.1 , originator 10.100.1.1]
BGP(4): 192.168.100.1 rcvd 65000:1:10.100.1.1/32, label 16
RT address family is not configured. Can't create RTC route  
BGP(4): (base) 192.168.100.1 send UPDATE (format) 65000:1:10.100.1.1/32, next
192.168.100.1, label 16, metric 0, path Local, extended community RT:1:1

PE2#
BGP(4): 192.168.100.3 rcvd UPDATE w/ attr: nexthop 192.168.100.1, origin i, localpref
100, originator 10.100.1.1, clusterlist 192.168.100.3 192.168.100.1, extended community
RT:1:1, [ATTR_SET attribute:  originator AS 65000, origin IGP, aspath , med 0, localpref
200, cluster list 192.168.100.1 , originator 10.100.1.1]
BGP(4): 192.168.100.3 rcvd 65000:1:10.100.1.1/32, label 16
RT address family is not configured. Can't create RTC route  
BGP(4): Revise route installing 1 of 1 routes for 10.100.1.1/32 -> 192.168.100.1
(customer1) to customer1 IP table
BGP(4): 10.1.2.5 NEXT_HOP is set to self for net 65000:2:10.100.1.1/32,

ملاحظة: تلقى PE1 تحديثه الخاص من RR ثم قام بإسقاطه. وذلك لأن PE1 و PE2 هما في نفس مجموعة التحديث على RR.

ملاحظة: إذا كنت تريد تفريغ رسالة التحديث الكامل في صورة سداسية عشرية، فاستخدم الكلمة الأساسية detail للأمر debug BGP Update.

PE2#   debug bgp vpnv4 unicast updates detail
BGP updates debugging is on with detail for address family: VPNv4 Unicast

PE2#
BGP(4): 192.168.100.3 rcvd UPDATE w/ attr: nexthop 192.168.100.1, origin i,
localpref 100, originator 10.100.1.1, clusterlist 192.168.100.3 192.168.100.1,
extended community RT:1:1, [ATTR_SET attribute:  originator AS 65000, origin IGP,
aspath , med 0, localpref 200, cluster list 192.168.100.1 , originator 10.100.1.1]
BGP(4): 192.168.100.3 rcvd 65000:1:10.100.1.1/32, label 17
RT address family is not configured. Can't create RTC route  
BGP: 192.168.100.3 rcv update length 125
BGP: 192.168.100.3 rcv update dump: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
0090 0200 00
PE2#00 7980 0E21 0001 800C 0000 0000 0000 0000 C0A8 6401 0078 0001 1100 00FD E800
0000 010A 6401 0140 0101 0040 0200 4005 0400 0000 64C0 1008 0002 0001 0000 0001 800A
08C0 A864 03C0 A864 0180 0904 0A64 0101 C080 2700 00FD E840 0101 0040 0200 8004 0400
0000 0040 0504 0000 00C8 800A 04C0 A864 0180 0904 0A64 0101
BGP(4): Revise route installing 1 of 1 routes for 10.100.1.1/32 -> 192.168.100.1
(customer1) to customer1 IP table
BGP(4): 10.1.2.5 NEXT_HOP is set to self for net 65000:2:10.100.1.1/32,

معالجة الخطوة التالية

يجب تكوين الخطوة التالية الذاتية على موجهات PE لهذه الميزة. السبب وراء ذلك هو أنه عادة ما يتم نقل الخطوة التالية دون تغيير مع iBGP. ومع ذلك، توجد هنا شبكتين منفصلتين: شبكة VPN وشبكة SP، التي تشغل بروتوكولات العبارة الداخلية المنفصلة (IGPs). وبالتالي، لا يمكن مقارنة قياس IGP بسهولة واستخدامه لأفضل حساب مسار بين الشبكتين. والنهج الذي اختاره RFC 6368 هو أن تكون الخطوة التالية إلزامية لجلسة بروتوكول بوابة الحدود الداخلية نحو مؤتمر التكامل الأوروبي، مما يتفادى الإصدار الذي سبق وصفه معا. ومن المزايا في هذا الصدد أن مواقع التردد اللاسلكي VRF يمكنها تشغيل بروتوكولات العبارة الداخلية المختلفة باستخدام هذا النهج.

RD

يشير RFC 6368 إلى أنه يوصى بأن تستخدم مواقع VRF المختلفة الخاصة بنفس شبكة VPN مصادر بيانات مختلفة (فريدة). في Cisco IOS، هذا إلزامي لهذه الميزة.

ميزة iBGP PE-CE مع نظام التشغيل المحلي

ارجع إلى الشكل 2. يحتوي عميل شبكة VPN1 على ASN 65001.

شكل 2

CE1 في AS 65001. لإنشاء بروتوكول BGP الداخلي هذا من وجهة نظر PE1، فإنه يحتاج إلى ميزة iBGP المحلية-as.

CE1

router bgp 65001
 bgp log-neighbor-changes
 network 10.100.1.1 mask 255.255.255.255
 neighbor 10.1.1.1 remote-as 65001

PE1

router bgp 65000
 bgp log-neighbor-changes
 neighbor 192.168.100.3 remote-as 65000
 neighbor 192.168.100.3 update-source Loopback0
 !
 address-family vpnv4
  neighbor 192.168.100.3 activate
  neighbor 192.168.100.3 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf customer1
  neighbor 10.1.1.4 remote-as 65001
  neighbor 10.1.1.4 local-as 65001
  neighbor 10.1.1.4 activate
  neighbor 10.1.1.4 internal-vpn-client
  neighbor 10.1.1.4 route-reflector-client
  neighbor 10.1.1.4 next-hop-self
 exit-address-family

يتم تكوين PE2 و CE2 بشكل مماثل.

يرى PE1 بادئة BGP كما هو موضح هنا:

PE1#show bgp vpnv4 unicast all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 41
Paths: (2 available, best #1, table customer1)
  Advertised to update-groups:
     5         
  Refresh Epoch 1
  Local, (Received from ibgp-pece RR-client)
    10.1.1.4 (via vrf customer1) from 10.1.1.4 (10.100.1.1)
      Origin IGP, metric 0, localpref 200, valid, internal, best
      mpls labels in/out 18/nolabel
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  Local, (Received from ibgp-pece RR-client), (ibgp sourced)
    10.1.1.4 (via vrf customer1) from 10.1.1.4 (10.100.1.1)
      Origin IGP, localpref 100, valid, internal
      Extended Community: RT:1:1
      mpls labels in/out 18/nolabel
      rx pathid: 0, tx pathid: 0

البادئة هي BGP داخلي.

يرى PE2 ما يلي:

PE2#show bgp vpnv4 unicast all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 33
Paths: (1 available, best #1, no table)
  Not advertised to any peer
  Refresh Epoch 5
  Local
    192.168.100.1 (metric 21) (via default) from 192.168.100.3 (192.168.100.3)
      Origin IGP, localpref 100, valid, internal, best
      Extended Community: RT:1:1
      Originator: 10.100.1.1, Cluster list: 192.168.100.3, 192.168.100.1
      ATTR_SET Attribute: 
        Originator AS 65001
        Origin IGP
        Aspath 
        Med 0
        LocalPref 200
        Cluster list 
        192.168.100.1, 
        Originator 10.100.1.1
      mpls labels in/out nolabel/18
      rx pathid: 0, tx pathid: 0x0
BGP routing table entry for 65000:2:10.100.1.1/32, version 34
Paths: (1 available, best #1, table customer1)
  Advertised to update-groups:
     5         
  Refresh Epoch 2
  Local, imported path from 65000:1:10.100.1.1/32 (global)
    192.168.100.1 (metric 21) (via default) from 192.168.100.3 (192.168.100.3)
      Origin IGP, metric 0, localpref 200, valid, internal, best
      Originator AS(ibgp-pece): 65001
      Originator: 10.100.1.1, Cluster list: 192.168.100.1
      mpls labels in/out nolabel/18
      rx pathid: 0, tx pathid: 0x0

المنشئ كما هو 65001، أي كما هو مستخدم عندما يتم إرسال البادئة من PE2 إلى CE2. إذا، ال "As" محفوظة، وكذلك التفضيل المحلي في هذا المثال.

CE2#show bgp ipv4 unicast 10.100.1.1/32
BGP routing table entry for 10.100.1.1/32, version 3
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.1.2.2 from 10.1.2.2 (192.168.100.2)
      Origin IGP, metric 0, localpref 200, valid, internal, best
      Originator: 10.100.1.1, Cluster list: 192.168.100.2, 192.168.100.1
      rx pathid: 0, tx pathid: 0x0

يمكنك رؤية محلي بدلا من مسار AS. وهذا يعني أنه مسار BGP داخلي تم إنشاؤه في AS 65001، وهو أيضا ال ASN الذي تم تكوينه للموجه CE2. تم أخذ جميع سمات BGP من سمة ATTR_SET. يتوافق هذا مع قواعد الحالة 1 في القسم التالي.

قواعد تبادل المسار بين مواقع VRF المختلفة

يحتوي ATTR_SET على المنشئ اعتبارا من VRF الأصلي. يتم التحقق من هذا Originating AS بواسطة PE البعيد، عندما يزيل ATTR_SET قبل أن يرسل البادئة إلى موجه CE.

الحالة 1: إذا تطابقت Originating AS مع ما تم تكوينه لموجه CE، فسيتم أخذ سمات BGP من سمة ATTR_SET عندما يقوم PE باستيراد المسار إلى VRF الوجهة.

الحالة 2: إذا لم يطابق Originating AS التكوين الخاص بموجه CE، فسيتم أخذ مجموعة السمات للمسار الذي تم إنشاؤه كما هو موضح هنا:

يتم ضبط خصائص المسار على السمات الموجودة في سمة ATTR_SET.
يتم تجاهل السمات الخاصة ب iBGP (local_pref، ومصدرها، و cluster_list).
يتم إضافة رقم الأصل AS الموجود في سمة ATTR_SET إلى AS_PATH ويتبع القواعد التي تنطبق على تناظر BGP الخارجي بين نقاط الوصول إلى المصدر والوجهة.
إذا كان النظام الذاتي المرتبط ب VRF هو نفسه النظام الذاتي لمزود VPN ولم تكن سمة AS_PATH الخاصة بمسار VPN فارغة، فسيتم تسميتها إلى سمة AS_PATH الخاصة بمسار VRF.

ارجع إلى الشكل 3. يحتوي CE1 و PE1 على AS 65000 ويتم تكوينه باستخدام ميزة iBGP PE-CE. يحتوي CE2 على ASN 65001. وهذا يعني وجود بروتوكول eBGP بين PE2 و CE2.

شكل 3

يرى الخط PE2 المسار كما يلي:

PE2#show bgp vpnv4 unicast all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 43
Paths: (1 available, best #1, no table)
  Not advertised to any peer
  Refresh Epoch 6
  Local
    192.168.100.1 (metric 21) (via default) from 192.168.100.3 (192.168.100.3)
      Origin IGP, localpref 100, valid, internal, best
      Extended Community: RT:1:1
      Originator: 10.100.1.1, Cluster list: 192.168.100.3, 192.168.100.1
      ATTR_SET Attribute: 
        Originator AS 65000
        Origin IGP
        Aspath 
        Med 0
        LocalPref 200
        Cluster list 
        192.168.100.1, 
        Originator 10.100.1.1
      mpls labels in/out nolabel/17
      rx pathid: 0, tx pathid: 0x0
BGP routing table entry for 65000:2:10.100.1.1/32, version 44
Paths: (1 available, best #1, table customer1)
  Advertised to update-groups:
     6         
  Refresh Epoch 6
  Local, imported path from 65000:1:10.100.1.1/32 (global)
    192.168.100.1 (metric 21) (via default) from 192.168.100.3 (192.168.100.3)
      Origin IGP, metric 0, localpref 200, valid, internal, best
      Originator AS(ibgp-pece): 65000
      Originator: 10.100.1.1, Cluster list: 192.168.100.1
      mpls labels in/out nolabel/17
      rx pathid: 0, tx pathid: 0x0

هذه هي البادئة كما تظهر في CE2:

CE2#show bgp ipv4 unicast 10.100.1.1/32
BGP routing table entry for 10.100.1.1/32, version 5
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  65000
    10.1.2.2 from 10.1.2.2 (192.168.100.2)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

هذه هي الحالة الثانية. يتم إعداد رقم الأصل AS الموجود في سمة ATTR_SET مسبقا إلى AS_PATH بواسطة PE2 ويتبع القواعد التي تنطبق على تجانس eBGP بين المصدر والوجهة AS. يتم تجاهل السمات الخاصة ب iBGP بواسطة PE2 عند إنشاء الموجه الذي يجب الإعلان عنه إلى CE2. لذلك، التفضيل المحلي هو 100 وليس 200 (كما يرى في السمة ATTR_SET).

انعكاس VRF-Lite من CE-to-CE

ارجع إلى الشكل 4.

الشكل 4

الشكل 4 يوضح موجه CE إضافي، CE3، متصل ب PE1. CE1 و CE3 كلاهما متصل ب PE1 على نفس مثيل VRF: customer1. وهذا يعني أن CE1 و CE3 هما موجهات Multi-VRF CE (تعرف أيضا باسم VRF-Lite) من PE1. يعتبر PE1 نفسه الخطوة التالية عند الإعلان عن البادئات من CE1 إلى CE3. في حالة عدم وجود رغبة في هذا السلوك، يمكنك تكوين المجاور 10.1.3.6 دون تغيير في الخطوة التالية على PE1. in order to شكلت هذا، أنت ينبغي أزلت جار 10.1.3.6 التالي-hop-self على PE1. ثم يرى CE3 أن المسارات من CE1 مع CE1 هي الخطوة التالية لبادئات BGP هذه. ومن أجل تنفيذ هذا العمل، تحتاج إلى المسارات الخاصة بالخطوات التالية لبروتوكول BGP هذه في جدول التوجيه ل CE3. أنت تحتاج بروتوكول تحشد حركي (IGP) أو مسحاج تخديد ثابت على CE1، PE1، و CE3 in order to تأكدت أن المسحاج تخديد يتلقى مسار لبعضهم بعضا من التالي جنجل عنوان. مهما، هناك مشكلة مع هذا تشكيل.

التكوين على PE1 هو:

router bgp 65000
 !
 address-family ipv4 vrf customer1
  neighbor 10.1.1.4 remote-as 65000
  neighbor 10.1.1.4 activate
  neighbor 10.1.1.4 internal-vpn-client
  neighbor 10.1.1.4 route-reflector-client
  neighbor 10.1.1.4 next-hop-self
  neighbor 10.1.3.6 remote-as 65000
  neighbor 10.1.3.6 activate
  neighbor 10.1.3.6 internal-vpn-client
  neighbor 10.1.3.6 route-reflector-client
  neighbor 10.1.3.6 next-hop-unchanged
 exit-address-family

تظهر البادئة من CE1 بشكل جيد على CE3:

CE3#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 9
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.1.1.4 from 10.1.3.1 (192.168.100.1)
      Origin IGP, metric 0, localpref 200, valid, internal, best
      Originator: 10.100.1.1, Cluster list: 192.168.100.1
      rx pathid: 0, tx pathid: 0x0

ومع ذلك، تظهر البادئة من CE2 في CE3 كما هو موضح هنا:

CE3#show bgp ipv4 unicast 10.100.1.2               
BGP routing table entry for 10.100.1.2/32, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    192.168.100.2 (inaccessible) from 10.1.3.1 (192.168.100.1)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 10.100.1.2, Cluster list: 192.168.100.1, 192.168.100.2
      rx pathid: 0, tx pathid: 0

ال BGP التالي 192.168.100.2، الاسترجاع عنوان من PE2. لم يقم PE1 بإعادة كتابة الخطوة التالية BGP إلى نفسها عند الإعلان عن البادئة 10.100.1.2/32 إلى CE3. وهذا يجعل هذه البادئة غير قابلة للاستخدام على CE3.

لذلك، في حالة وجود مزيج من ميزة iBGP PE-CE عبر MPLS-VPN و iBGP VRF-Lite، يجب عليك التأكد من أن لديك دائما الطرف التالي - الذاتي على موجهات PE.

لا يمكنك الحفاظ على الخطوة التالية عندما يكون موجه PE هو RR يعكس مسارات iBGP من واحد CE إلى آخر CE عبر واجهات VRF محليا على PE. عند تشغيل iBGP PE-CE عبر شبكة MPLS VPN، يجب عليك إستخدام Internal-VPN-client لجلسات عمل iBGP نحو موجهات CE. عندما يكون لديك أكثر من CE محلي واحد في VRF على موجه PE، فيجب عليك الحفاظ على نفس الخطوة التالية لنظراء BGP هؤلاء.

يمكنك النظر في خرائط المسار لتعيين الخطوة التالية على نفسها للبادئات المستلمة من موجهات PE الأخرى، ولكن ليس للبادئات المنعكسة من موجهات CE الأخرى المتصلة محليا. ومع ذلك، لا يتم حاليا دعم تعيين الخطوة التالية على نفسها في خريطة مسار صادرة. ويتم توضيح هذا التكوين هنا:

router bgp 65000

 address-family ipv4 vrf customer1
  neighbor 10.1.1.4 remote-as 65000
  neighbor 10.1.1.4 activate
  neighbor 10.1.1.4 internal-vpn-client
  neighbor 10.1.1.4 route-reflector-client
  neighbor 10.1.1.4 next-hop-self
  neighbor 10.1.3.6 remote-as 65000
  neighbor 10.1.3.6 activate
  neighbor 10.1.3.6 internal-vpn-client
  neighbor 10.1.3.6 route-reflector-client
  neighbor 10.1.3.6 route-map NH-setting out
 exit-address-family

ip prefix-list PE-loopbacks seq 10 permit 192.168.100.0/24 ge 32
!

route-map NH-setting permit 10
 description set next-hop to self for prefixes from other PE routers
 match ip route-source prefix-list PE-loopbacks
 set ip next-hop self
!

route-map NH-setting permit 20
 description advertise prefixes with next-hop other than the prefix-list in
route-map entry 10 above
!

ومع ذلك، فهذا غير مدعوم:

PE1(config)#route-map NH-setting permit 10
PE1(config-route-map)# set ip next-hop self
% "NH-setting" used as BGP outbound route-map, set use own IP/IPv6 address for the nexthop not supported

برنامج Cisco IOS الأقدم على موجه PE

إذا كان PE1 يشغل برنامج Cisco IOS software الأقدم الذي يفتقر إلى ميزة iBGP PE-CE، فإن PE1 لا يحدد نفسه أبدا على أنه الخطوة التالية لبادئات iBGP المنعكسة. وهذا يعني أن بادئة BGP المنعكسة (10.100.1.1/32) من CE1 (10.100.1.1) إلى CE2 - عبر PE1- سيكون لها CE1 (10.1.1.4) كالخطوة التالية.

CE3#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 32
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.1.1.4 from 10.1.3.1 (192.168.100.1)
      Origin IGP, metric 0, localpref 200, valid, internal, best
      Originator: 10.100.1.1, Cluster list: 192.168.100.1
      rx pathid: 0, tx pathid: 0x0

يتم ملاحظة البادئة من CE2 (10.100.1.2/32) مع PE2 كالخطوة التالية، لأن PE1 لا يقوم بالخطوة التالية الذاتية لهذه البادئة إما:

CE3#show bgp ipv4 unicast 10.100.1.2
BGP routing table entry for 10.100.1.2/32, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    192.168.100.2 (inaccessible) from 10.1.3.1 (192.168.100.1)
      Origin IGP, localpref 100, valid, internal
      Originator: 10.100.1.2, Cluster list: 192.168.100.1, 192.168.100.3, 192.168.100.2
      ATTR_SET Attribute: 
        Originator AS 65000
        Origin IGP
        Aspath 
        Med 0
        LocalPref 100
        Cluster list 
        192.168.100.2, 
        Originator 10.100.1.2
      rx pathid: 0, tx pathid: 0

لكي تعمل ميزة iBGP PE-CE بشكل صحيح، يجب أن تحتوي جميع موجهات PE للشبكة الخاصة الظاهرية (VPN) التي تم تمكين الميزة فيها على الرمز لدعم الميزة وتمكين الميزة.

Next-hop-self ل eBGP على VRF

ارجع إلى الشكل 5.

شكل 5

الشكل 5 يوضح إعداد VRF-Lite. جلسة العمل من PE1 إلى CE4 هي eBGP. لا تزال الجلسة من PE1 إلى CE3 هي iBGP.

بالنسبة لبادئات eBGP، يتم تعيين الخطوة التالية دائما على نفسها عند الإعلان عن البادئات باتجاه جار iBGP على VRF. هذا بغض النظر عن الحقيقة إذا كانت جلسة العمل تجاه جار iBGP عبر VRF لها إعداد نفس الخطوة التالية أم لا.

في الشكل 5، يرى CE3 البادئات من CE4 مع PE1 على أنها الخطوة التالية.

CE3#show bgp ipv4 unicast 10.100.1.4
BGP routing table entry for 10.100.1.4/32, version 103
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  65004
    10.1.3.1 from 10.1.3.1 (192.168.100.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

يحدث ذلك مع وضع-hop-self التالي على PE1 تجاه CE3 أو بدون.

إذا لم تكن الواجهات في PE1 نحو CE3 و CE4 في تردد الراديو الظاهري (VRF)، ولكن في السياق العالمي، فإن الخطوة التالية الذاتية نحو CE3 تحدث فرقا.

بدون الخطوة التالية على PE1 تجاه CE3، سترى:

PE1#show bgp vrf customer1 vpnv4 unicast neighbors 10.1.3.6
BGP neighbor is 10.1.3.6,  vrf customer1,  remote AS 65000, internal link
...
 For address family: VPNv4 Unicast
  Translates address family IPv4 Unicast for VRF customer1
  Session: 10.1.3.6
  BGP table version 1, neighbor version 1/0
  Output queue size : 0
  Index 12, Advertise bit 0
  Route-Reflector Client
  12 update-group member
  Slow-peer detection is disabled
  Slow-peer split-update-group dynamic is disabled
  Interface associated: (none)

على الرغم من تمكين الخطوة التالية الذاتية بشكل ضمني، إلا أن الإخراج لا يشير إلى ذلك.

مع الخطوة التالية الذاتية على PE1 تجاه CE3، ترى:

PE1#show bgp vrf customer1 vpnv4 unicast neighbors 10.1.3.6 
BGP neighbor is 10.1.3.6,  vrf customer1,  remote AS 65000, internal link
..
 For address family: VPNv4 Unicast
...
  NEXT_HOP is always this router for eBGP paths

حيث أن، إذا كانت الواجهات نحو CE3 و CE4 في سياق عام، الخطوة التالية للبادئات من CE4 هي CE4 نفسه عندما لا يتم تكوين نفس الخطوة التالية:

CE3#show bgp ipv4 unicast 10.100.1.4
BGP routing table entry for 10.100.1.4/32, version 124
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  65004
    10.1.4.7 from 10.1.3.1 (192.168.100.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

للحصول على الخطوة التالية على PE1 تجاه CE3:

CE3#show bgp ipv4 unicast 10.100.1.4
BGP routing table entry for 10.100.1.4/32, version 125
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  65004
    10.1.3.1 from 10.1.3.1 (192.168.100.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

تم القيام بذلك استنادا إلى RFC 4364.

إذا كنت تريد عدم تعيين نفس الخطوة التالية لبادئات eBGP نحو جلسة عمل iBGP عبر واجهة VRF، فيجب عليك تكوين لم تتغير الخطوة التالية. حصل الدعم ل هذا فقط مع cisco بق id CSCuj11720.

router bgp 65000
...
 address-family ipv4 vrf customer1
  neighbor 10.1.1.4 remote-as 65000
  neighbor 10.1.1.4 activate
  neighbor 10.1.1.4 route-reflector-client
  neighbor 10.1.3.6 remote-as 65000
  neighbor 10.1.3.6 activate
  neighbor 10.1.3.6 route-reflector-client
  neighbor 10.1.3.6 next-hop-unchanged
  neighbor 10.1.4.7 remote-as 65004
  neighbor 10.1.4.7 activate
 exit-address-family

والآن، يعتبر CE3 CE4 الخطوة التالية للبادئات المعلن عنها بواسطة CE4:

CE3#show bgp ipv4 unicast 10.100.1.4
BGP routing table entry for 10.100.1.4/32, version 130
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 3
  65004
    10.1.4.7 from 10.1.3.1 (192.168.100.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

إن يحاول أنت أن يشكل التالي جنجل كلمة المفتاح غير تغير لجلسة iBGP نحو CE3 على cisco ios رمز قبل cisco بق id CSCuj11720، أنت تواجه هذا خطأ:

PE1(config-router-af)# neighbor 10.1.3.6 next-hop-unchanged 
%BGP: Can propagate the nexthop only to multi-hop EBGP neighbor

بعد Cisco Bug ID CSCuj11720، تكون الكلمة الأساسية التالية -hop-unchanged صالحة لجيران eBGP المتعدد الخطوات وجيران iBGP VRF-Lite.

تمت المساهمة بواسطة مهندسو Cisco

Luc De Ghein
Cisco TAC Engineer.

هل كان هذا المستند مفيدًا؟

التعليقات

اتصل بنا

فتح حالة دعم
(تتطلب عقد خدمة Cisco)