فهم أهمية سمة مسار وزن BGP

المقدمة

يصف هذا المستند أهمية سمة مسار وزن بروتوكول العبارة الحدودية (BGP) في سيناريوهات تجاوز فشل الشبكة. 

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• بروتوكول البوابة الحدودية (BGP)
• إعادة توزيع بروتوكولات التوجيه
• الموجه الذي يشغل برنامج Cisco IOS^®

المكونات المستخدمة

تستند المعلومات الواردة في هذا المستند إلى موجه Cisco باستخدام الإصدار 15.6(2) من Cisco IOS®

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

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

وعادة ما يتم إستخدام BGP للإعلان عن بادئات الشبكة لشبكة منطقة WAN (WAN) بمجرد استقبالها عبر بروتوكول العبارة الداخلية (IGP) من شبكة منطقة LAN (LAN) والعكس. بدون وجود التكوين الصحيح، يمكن أن يفشل BGP في إستعادة مسار التوجيه الأصلي عبر شبكة الاتصال واسعة النطاق بعد إسترداد الشبكة من فشل إرتباط.

يمكن أن تحتوي الموجهات التي تم نشرها في سيناريوهات تجاوز الفشل على مسارات عالقة يمكن أن تتسبب في إعادة توجيه حركة المرور عبر مسار النسخ الاحتياطي بعد فشل حدث شبكة الاسترداد. قد يحدث ذلك بسبب طبيعة سمة مسار وزن BGP.

بعد حدوث فشل في الشبكة (عادة مع إرتباط شبكة الاتصال واسعة النطاق (WAN))، يمكن للشبكة التقارب واستخدام مسار النسخ الاحتياطي المتوفر الذي تم إستقباله عبر بروتوكول العبارة الداخلية.

ومع ذلك، عند إسترداد المسار الأساسي، يمكن للموجه إستخدام مسار النسخ الاحتياطي وليس إستعادة المسار الأصلي عبر إرتباط شبكة WAN.

يمكن رؤية عواقب مثل مسارات التوجيه غير المتماثلة ودون المثالية.

في سيناريوهات التكرار مع موجهات شبكة WAN، يمكن أن تقوم هذه بتشغيل BGP لتبادل بادئات الشبكة مع شبكة WAN. يمكن إستخدام بروتوكول العبارة الداخلي المحسن مثل بروتوكول توجيه العبارة الداخلي (EIGRP) لتبادل بادئات الشبكة مع أجهزة شبكة LAN. وعادة ما تكون إعادة التوزيع المتبادل بين هذه البروتوكولات ضرورية لتحقيق إمكانية اتصال الشبكة بالكامل. 

ملاحظة: يستخدم هذا المستند بادئة المصطلحات والموجه بالتبادل.

التصميم عالي المستوى لهذا يمكن رؤيته في المخطط التالي:

تم تعيين سمة مسار وزن BGP في المسارات التي تم إنشاؤها محليا

يصف السيناريو التالي سلوك سمة مسار وزن BGP في حالات الفشل.

الخطوة 1. يتم إستلام المسار عبر BGP.

كما هو موضح في الصورة، يستقبل الموجه المسمى WAN RTR الشبكة 192.168.1.0/24 عبر BGP.

بمسافة إدارية (AD) تبلغ 20، يتم تثبيت المسار في جدول التوجيه.

جدول BGP:

WAN_RTR#show ip bgp
<snip>
     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.1.0      10.1.2.2                 0             0 2 i

يوضح جدول التوجيه التوجيه الذي تم تثبيته بواسطة BGP:

WAN_RTR#show ip route
<snip>
B     192.168.1.0/24 [20/0] via 10.1.2.2, 00:00:42

الخطوة 2. يتم إستلام المسار عبر EIGRP.

تنزل جلسة BGP بسبب فشل الارتباط. وعن طريق تقارب الشبكات، يتم الآن تلقي نفس المسار 192.168.1.0/24 عبر EIGRP.

النقطة الأساسية هي أن BGP يمكن أن يعلن أو يعيد توزيع مسارات EIGRP (مع مساعدة تكوين الموجه التالي). وإذا كان هذا هو الحال، تتم الآن إضافة مسار EIGRP إلى جدول BGP. 

ملاحظة: يتم تعيين سمة مسار وزن BGP على 32768 بشكل افتراضي عندما يقوم الموجه بإنشاء بادئات الشبكة محليا.

تكوين BGP:

WAN_RTR#show running-config | begin router bgp
<snip>
router bgp 1
 redistribute eigrp 1
 neighbor 10.1.2.2 remote-as 2
!

ملاحظة: يمكن لشبكة أمر BGP 192.168.1.0 القناع 255.255.255.0 إظهار النتائج نفسها.

جدول BGP:

WAN_RTR#show ip bgp
<snip>

     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.1.0      10.1.3.3            156160         32768 ?

يوضح جدول التوجيه التوجيه الذي تم تثبيته بواسطة EIGRP:

WAN_RTR#show ip route
<snip>

D     192.168.1.0/24 [90/156160] via 10.1.3.3, 00:00:02, FastEthernet0/1
WAN_RTR#

الخطوة 3. المسار الذي تم إستلامه عبر BGP مرة أخرى.

مع إعادة توزيع مسار EIGRP الآن إلى BGP وبعد إستلام المسار الأصلي عبر BGP مرة أخرى، هناك الآن إدخالان للشبكة 192.168.1.0/24 في جدول BGP.

جدول BGP:

WAN_RTR#show ip bgp
<snip>

     Network          Next Hop            Metric LocPrf Weight Path
 *   192.168.1.0      10.1.2.2                 0             0 2 i
 *>                   10.1.3.3            156160         32768 ?

 في جدول BGP:

 - لا يزال الإدخال الذي تم إنشاؤه في الخطوة 2 بواسطة مسار EIGRP الذي تمت إعادة توزيعه إلى BGP ممكنا رؤيته.

 - تتم إضافة المسار الأصلي مرة أخرى من خلال إعادة إنشاء جلسة بروتوكول بوابة الحدود (BGP).

من وجهة نظر تحديد مسار بروتوكول بوابة الحدود (BGP) الأفضل:

- تم تعيين قيمة سمة مسار الوزن الخاصة بمسار EIGRP الذي تمت إعادة توزيعه إلى BGP على 32768 نظرا لأنه تم إنشاؤها محليا في الموجه من وجهة نظر BGP.

- قيمة سمة مسار الوزن للمسار الأصلي الذي تم إستقباله عبر جلسة BGP مع شبكة WAN هي 0.

- يحتوي المسار الأول على أعلى وزن، وبالتالي يتم انتخابه كأفضل مسار في جدول BGP.

- يتسبب ذلك في عدم تقارب جدول التوجيه مرة أخرى إلى الحالة الأصلية والاحتفاظ بإدخال مسار EIGRP.

ملاحظة: سمة مسار وزن BGP هي أول سمة مسار تتحقق BGP في إختيار أفضل مسار في جدول BGP على موجهات Cisco IOS. يفضل BGP مسار الإدخال بأعلى وزن. الوزن عبارة عن معلمة خاصة ب Cisco، وهي مهمة محليا فقط في الموجه حيث تم تكوينها. مزيد من المعلومات عبر خوارزمية تحديد مسار BGP الأفضل.

جدول التوجيه:

WAN_RTR#show ip route
<snip>
D     192.168.1.0/24 [90/156160] via 10.1.3.3, 00:08:55, FastEthernet0/1

تعديل سمة مسار وزن BGP

يمكن تعديل القيمة الافتراضية لسمة مسار وزن BGP في نظير BGP الذي تم تكوينه باستخدام الأمر weight أو خريطة المسار.

تعمل الأوامر التالية على تعيين سمة مسار الوزن على 40000 لجميع المسارات التي يتم استقبالها من نظير BGP.

مثال 1

router bgp 1
 neighbor 10.1.2.2 weight 40000

مثال 2

route-map FROM-WAN permit 10
 set weight 40000
!
router bgp 1
 neighbor 10.1.2.2 route-map FROM-WAN in
!
clear ip bgp * soft in

مثال 3

ip prefix-list NETWORKS permit 192.168.1.0/24
!
route-map FROM-WAN permit 10
 match ip address prefix NETWORKS
 set weight 40000
route-map FROM-WAN permit 100
!
router bgp 1
 neighbor 10.1.2.2 route-map FROM-WAN in
!
clear ip bgp * soft in

مع زيادة قيمة سمة مسار الوزن، تكون للمسارات الأصلية التي يتم استقبالها عبر BGP الأولوية كما هو موضح في الحالة التالية:

الخطوة 1. يتم إستلام المسار عبر BGP.

يوضح جدول BGP أن المسارات المستلمة عبر BGP تحتوي الآن على قيمة وزن تبلغ 40000 بدلا من صفر.

جدول BGP:

WAN_RTR#show ip bgp
<snip>

     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.1.0      10.1.2.2                 0         40000 2 i

WAN_RTR#

 جدول التوجيه:

WAN_RTR#show ip route
<snip>
B     192.168.1.0/24 [20/0] via 10.1.2.2, 00:09:53

الخطوة 2. يتم إستلام المسار عبر EIGRP.

لا تزال قيمة المسارات التي تم إنشاؤها محليا تبلغ 32768 في جدول BGP.

جدول BGP:

WAN_RTR#show ip bgp
<snip>
     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.1.0      10.1.3.3            156160         32768 ?

جدول التوجيه:

WAN_RTR#show ip route
<snip>
D     192.168.1.0/24 [90/156160] via 10.1.3.3, 00:01:41, FastEthernet0/1

الخطوة 3. المسار الذي تم إستلامه عبر BGP مرة أخرى.

باستخدام الوزن 40000، يتم الآن إختيار المسارات التي يتم استقبالها من خلال بروتوكول BGP بدلا من المسارات الأصلية المحلية. وهذا يجعل الشبكة تتقارب بشكل صحيح مرة أخرى إلى حالتها الأصلية.

جدول BGP:

WAN_RTR#show ip bgp
<snip>
     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.1.0      10.1.2.2                 0         40000 2 i

جدول التوجيه:

WAN_RTR#show ip route
<snip>
B     192.168.1.0/24 [20/0] via 10.1.2.2, 00:00:25

سيناريو حالة حقيقية

خذ على سبيل المثال السيناريو التالي:

الخطوة 1. حالة الشبكة الأصلية.

يستقبل المحول Core Layer 3 المسار 192.168.1.0/24 عبر EIGRP من WAN RTR A و WAN RTR B. يتم إختيار المسار عبر WAN RTR A.

يوضح الإخراج التالي كيفية احتفاظ المحول الأساسي بتجاور EIGRP مع كل من موجهات WAN واختيار WAN RTR A للوصول إلى شبكة 192.168.1.0/24.

CORE#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
0   10.1.2.2  (WAN_RTR_A)   Fa0/0                    10 00:05:15   79  1066  0  10
1   10.1.3.3  (WAN_RTR_B)   Fa0/1                    12 00:06:22   76   456  0  5


CORE#show ip route
<snip>
D EX  192.168.1.0/24 [170/28416] via 10.1.2.2, 00:00:32, FastEthernet0/0


CORE#show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(1)/ID(10.10.10.10)
<snip>
P 192.168.1.0/24, 1 successors, FD is 28416, tag is 4
        via 10.1.2.2 (28416/2816), FastEthernet0/0
        via 10.1.3.3 (281856/2816), FastEthernet0/1

الخطوة 2. فشل إرتباط شبكة WAN الأساسية.

في حال فشل إرتباط، يقوم المحول Core Switch الآن بتثبيت المسار عبر ثاني أفضل مسار EIGRP وهو WAN RTR B.

CORE#show ip route
<snip>
D EX  192.168.1.0/24 [170/281856] via 10.1.3.3, 00:00:05, FastEthernet0/1


CORE#show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(1)/ID(10.10.10.10)
<snip>
P 192.168.1.0/24, 1 successors, FD is 28416, tag is 4
        via 10.1.3.3 (281856/2816), FastEthernet0/1

الخطوة 3. إستعادة الارتباط الأساسي بشبكة WAN.

تمت إستعادة إرتباط شبكة WAN الأساسي. ومع ذلك، لا يزال المحول الأساسي يقوم بالتوجيه عبر مسار النسخ الاحتياطي كما هو موضح على الإخراج التالي:

CORE#show ip route
<snip>
D EX  192.168.1.0/24 [170/281856] via 10.1.3.3, 00:06:09, FastEthernet0/1


CORE#show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(1)/ID(10.10.10.10)
<snip>
P 192.168.1.0/24, 1 successors, FD is 28416, tag is 4
        via 10.1.3.3 (281856/2816), FastEthernet0/1

يكمن سبب هذا السلوك في سمة مسار وزن BGP كما تمت مناقشته.

في الحالة الحالية، يعرض WAN RTR A المسار في جدول التوجيه عبر EIGRP وفي جدول BGP الذي تتم إعادة توزيعه من EIGRP بسبب أعلى قيمة لسمة مسار الوزن التي تربح على قيمة وزن المسار المستلمة عبر BGP من إرتباط WAN الذي تمت إعادة إنشاؤه.

WAN_RTR_A#show ip bgp
<snip>
    Network          Next Hop            Metric LocPrf Weight Path
*   192.168.1.0      10.2.4.4                 0             0 4 i
*>                   10.1.2.1            284416         32768 ?


WAN_RTR_A#show ip bgp summary
BGP router identifier 10.20.20.20, local AS number 2
<snip>
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.2.4.4        4            4      12      12       16    0    0 00:03:54   (UP) 4


WAN_RTR_A#show ip route
<snip>
D EX  192.168.1.0/24 [170/284416] via 10.1.2.1, 00:08:22, FastEthernet0/0

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