بروتوكول بوابة الحدود

📅 آخر تحديث: ٢٥ يوليو ٢٠٢٦
✍️ نُشر في: ٢٥ يوليو ٢٠٢٦
📷 يحتوي على 3 صور
الموسوعة الحرة

بروتوكول بوابة الحدود ( BGP ) هو بروتوكول بوابة خارجية قياسي مصمم لتبادل معلومات التوجيه وإمكانية الوصول بين الأنظمة المستقلة (AS) على الإنترنت . [ 2 ] يُصنف BGP كبروتوكول توجيه متجه المسار ، [ 3 ] ويتخذ قرارات التوجيه بناءً على المسارات أو سياسات الشبكة أو مجموعات القواعد التي يُحددها مسؤول الشبكة .

يُطلق على بروتوكول BGP المستخدم للتوجيه داخل نظام مستقل اسم بروتوكول بوابة الحدود الداخلية ( iBGP ). في المقابل، يُطلق على تطبيق البروتوكول على الإنترنت اسم بروتوكول بوابة الحدود الخارجية ( EBGP ).

تاريخ

في يناير 1989، وخلال الاجتماع الثاني عشر لفريق عمل هندسة الإنترنت (IETF) في أوستن، تكساس ، اجتمع ياكوف ريختر ، ولين بوساك ، وكيرك لوغيد لتصميم ما أصبح لاحقًا بروتوكول بوابة الحدود (BGP). دُوّن التصميم الأولي لبروتوكول BGP على منديلين، ولذا يُشار إليه غالبًا باسم "بروتوكول المنديلين". [ 4 ] ثمّ وُسّع التصميم المكتوب على المنديلين ليُصبح ثلاث ورقات مكتوبة بخط اليد، ومنها طُوّر أول تطبيق قابل للتشغيل البيني لبروتوكول BGP بسرعة. تُعلّق الآن نسخة من هذه الورقات الثلاث على جدار منطقة تطوير بروتوكولات التوجيه في شركة سيسكو سيستمز في ميلبيتاس، كاليفورنيا . في العام نفسه، نُشرت RFC 1105 [ 5 ] ، ويُستخدم بروتوكول BGP (بأشكال مختلفة) على الإنترنت منذ عام 1994. [ 6 ] 

بعد ستة أشهر من النشر الأولي، تم تغيير تعريف البروتوكول في عام 1990 مع نشر RFC 1136 [ 7 ] . وفي أكتوبر 1991، تم تعريف الإصدار الثالث من بروتوكول BGP في RFC 1267 [ 8 ] ، مما أدى إلى إلغاء الإصدارين السابقين. وفي عام 1994، نُشر الإصدار الحالي (BGP4) في RFC 1654 [ 9 ] . وتم استبدال تعريفه في مارس 1995 بواسطة RFC 1771 [ 10 ] . وفي يناير 2006، نُشر RFC 4271 [ 11 ] ، وهو حاليًا أحدث تعريف لبروتوكول BGP4 (على الرغم من تحديثه بواسطة العديد من RFCs الأخرى).     

صحّح RFC 4271 الأخطاء، وأزال الغموض، وحدّث المواصفات لتتوافق مع الممارسات الشائعة في هذا المجال. تمثّل التحسين الرئيسي لبروتوكول BGP4 في دعم التوجيه بين النطاقات غير المصنفة (CIDR) واستخدام تجميع المسارات لتقليل حجم جداول التوجيه . في شكله الأصلي، يعمل بروتوكول BGP4 فقط مع عناوين IPv4. منذ نشر RFC 2283 [ 12 ] عام 1998، أصبح بالإمكان نقل معلومات التوجيه لمجموعة واسعة من "عائلات العناوين" ( IPv4 ، IPv6 ، IPX ، إلخ). تم تحديث "امتدادات البروتوكولات المتعددة" عام 2000 مع RFC 2858 [ 13 ] ، وأخيرًا عام 2007 مع RFC 4760 [ 14 ] . مع هذه الامتدادات، يُشار إلى البروتوكول أيضًا باسم BGP متعدد البروتوكولات (MP-BGP).   

عملية

يتم إنشاء جيران بروتوكول BGP، الذين يُطلق عليهم النظراء، يدويًا بين أجهزة التوجيه لإنشاء جلسة TCP على المنفذ 179. ويرسل جهاز توجيه BGP رسائل إبقاء الاتصال (Keep-alive) بحجم 19 بايت كل 30 ثانية (القيمة الافتراضية للبروتوكول، قابلة للتعديل) للحفاظ على الاتصال. [ 15 ] ومن بين بروتوكولات التوجيه، يتميز BGP باستخدامه بروتوكول TCP كبروتوكول نقل.

عندما يعمل بروتوكول BGP بين نظيرين في نفس النظام المستقل (AS)، يُشار إليه باسم BGP الداخلي ( iBGP أو بروتوكول بوابة الحدود الداخلية ). أما عندما يعمل بين أنظمة مستقلة مختلفة، فيُسمى BGP الخارجي ( eBGP أو بروتوكول بوابة الحدود الخارجية ). تُسمى أجهزة التوجيه الموجودة على حدود نظام مستقل واحد والتي تتبادل المعلومات مع نظام مستقل آخر بأجهزة توجيه الحدود أو أجهزة توجيه الحافة ، أو ببساطة نظراء eBGP ، وعادةً ما تكون متصلة مباشرةً، بينما يمكن ربط نظراء iBGP عبر أجهزة توجيه وسيطة أخرى. كما توجد بنيات نشر أخرى ممكنة، مثل تشغيل نظير eBGP داخل نفق VPN ، مما يسمح لموقعين بعيدين بتبادل معلومات التوجيه بطريقة آمنة ومعزولة.

يكمن الاختلاف الرئيسي بين التناظر عبر بروتوكول iBGP والتناظر عبر بروتوكول eBGP في الطريقة التي يتم بها عادةً نشر المسارات التي يتم استلامها من أحد النظراء بشكل افتراضي إلى النظراء الآخرين:

  • يتم إعادة الإعلان عن المسارات الجديدة التي تم تعلمها من نظير eBGP إلى جميع نظراء iBGP و eBGP.
  • يتم إعادة الإعلان عن المسارات الجديدة التي تم تعلمها من نظير iBGP لجميع نظراء eBGP فقط.

تتطلب قواعد نشر المسار هذه فعليًا أن تكون جميع نظراء iBGP داخل نظام مستقل متصلة ببعضها البعض في شبكة كاملة مع جلسات iBGP.

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

التفاوض على تمديد العقد

أثناء عملية المصافحة بين الشبكات، عند تبادل رسائل OPEN، يمكن لمتحدثي بروتوكول BGP التفاوض على إمكانيات اختيارية للجلسة، [ 16 ] بما في ذلك امتدادات البروتوكولات المتعددة [ 17 ] وأنماط الاسترداد المختلفة. إذا تم التفاوض على امتدادات البروتوكولات المتعددة لبروتوكول BGP عند إنشاء الجلسة، فيمكن لمتحدث BGP إضافة بادئة عائلة عناوين إلى معلومات إمكانية الوصول إلى طبقة الشبكة (NLRI) التي يعلن عنها. تشمل هذه العائلات IPv4 (الافتراضي)، وIPv6، وشبكات IPv4/IPv6 الافتراضية الخاصة، وبروتوكول BGP متعدد البث. يتزايد استخدام بروتوكول BGP كبروتوكول إشارة عام لنقل معلومات حول المسارات التي قد لا تكون جزءًا من الإنترنت العالمي، مثل شبكات VPN. [ 18 ]

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

الحالة الأولى هي حالة الخمول. في هذه الحالة، يقوم بروتوكول BGP بتهيئة جميع الموارد، ويرفض جميع محاولات الاتصال الواردة، ويبدأ اتصال TCP مع الجهاز النظير. الحالة الثانية هي حالة الاتصال. في هذه الحالة، ينتظر الموجه اكتمال اتصال TCP، وينتقل إلى حالة OpenSent في حال نجاح الاتصال. في حال فشل الاتصال، يبدأ الموجه مؤقت إعادة محاولة الاتصال، وينتقل إلى حالة Active عند انتهاء صلاحيته. في حالة Active، يعيد الموجه ضبط مؤقت إعادة محاولة الاتصال إلى الصفر، ويعود إلى حالة الاتصال. في حالة OpenSent، يرسل الموجه رسالة Open، وينتظر ردًا عليها للانتقال إلى حالة OpenConfirm. يتم تبادل رسائل Keepalive، وعند استلامها بنجاح، ينتقل الموجه إلى حالة Established. في حالة Established، يمكن للموجه إرسال واستقبال رسائل Keepalive وUpdate وNotification من وإلى الجهاز النظير.

  • حالة الخمول :
    • رفض جميع اتصالات بروتوكول بوابة الحدود (BGP) الواردة.
    • ابدأ عملية تهيئة مشغلات الأحداث.
    • يبدأ اتصال TCP مع نظير BGP المُهيأ له.
    • يستمع إلى اتصال TCP من نظيره.
    • يغير حالته إلى "متصل".
    • في حال حدوث خطأ في أي مرحلة من مراحل عملية FSM، يتم إنهاء جلسة BGP فورًا والعودة إلى حالة الخمول. من بين الأسباب التي قد تمنع جهاز التوجيه من الانتقال من حالة الخمول ما يلي:
      • المنفذ TCP رقم 179 غير مفتوح.
      • منفذ TCP عشوائي فوق الرقم 1023 غير مفتوح.
      • تم تكوين عنوان النظير بشكل غير صحيح على أي من جهازي التوجيه.
      • تم تكوين رقم النظام المستقل (AS) بشكل غير صحيح على أي من جهازي التوجيه.
  • حالة الاتصال :
    • ينتظر إتمام عملية التفاوض الناجحة لبروتوكول TCP مع النظير.
    • لا يقضي بروتوكول BGP الكثير من الوقت في هذه الحالة إذا تم إنشاء جلسة TCP بنجاح.
    • يرسل رسالة فتح إلى النظير ويغير الحالة إلى OpenSent.
    • في حال حدوث خطأ، ينتقل بروتوكول BGP إلى الحالة النشطة. ومن أسباب هذا الخطأ ما يلي:
      • المنفذ TCP رقم 179 غير مفتوح.
      • منفذ TCP عشوائي فوق الرقم 1023 غير مفتوح.
      • تم تكوين عنوان النظير بشكل غير صحيح على أي من جهازي التوجيه.
      • تم تكوين رقم النظام المستقل (AS) بشكل غير صحيح على أي من جهازي التوجيه.
  • الحالة النشطة :
    • إذا لم يتمكن جهاز التوجيه من إنشاء جلسة TCP ناجحة، فإنه ينتهي به الأمر في الحالة النشطة.
    • يحاول BGP FSM إعادة تشغيل جلسة TCP أخرى مع النظير، وإذا نجح، فإنه يرسل رسالة فتح إلى النظير.
    • إذا لم تنجح العملية مرة أخرى، تتم إعادة ضبط آلة الحالة المحدودة إلى حالة الخمول.
    • قد تؤدي الأعطال المتكررة إلى تذبذب جهاز التوجيه بين حالتي الخمول والنشاط. ومن أسباب ذلك ما يلي:
      • المنفذ TCP رقم 179 غير مفتوح.
      • منفذ TCP عشوائي فوق الرقم 1023 غير مفتوح.
      • خطأ في تكوين بروتوكول BGP.
      • ازدحام الشبكة .
      • واجهة الشبكة المتذبذبة.
  • حالة OpenSent :
    • يستمع نظام BGP FSM لرسالة فتح من نظيره.
    • بمجرد استلام الرسالة، يقوم جهاز التوجيه بالتحقق من صحة رسالة الفتح.
    • إذا حدث خطأ، فذلك لأن أحد الحقول في رسالة الفتح لا يتطابق بين النظراء، على سبيل المثال، عدم تطابق إصدار BGP، أو أن جهاز التوجيه الذي يربط النظراء يتوقع عنوان AS مختلفًا، وما إلى ذلك. ثم يرسل جهاز التوجيه رسالة إشعار إلى النظير توضح سبب حدوث الخطأ.
    • في حالة عدم وجود خطأ، يتم إرسال رسالة Keepalive، ويتم ضبط المؤقتات المختلفة، ويتم تغيير الحالة إلى OpenConfirm.
  • حالة تأكيد الفتح :
    • يستمع الجهاز النظير لرسالة Keepalive من الجهاز النظير.
    • إذا تم استلام رسالة Keepalive ولم ينتهِ أي مؤقت قبل استلام رسالة Keepalive، فإن بروتوكول BGP ينتقل إلى حالة Established.
    • إذا انتهت صلاحية المؤقت قبل استلام رسالة Keepalive، أو إذا حدثت حالة خطأ، فإن جهاز التوجيه يعود إلى حالة الخمول.
  • الدولة القائمة :
    • في هذه الحالة، يرسل النظراء رسائل التحديث لتبادل المعلومات حول كل مسار يتم الإعلان عنه لنظير BGP.
    • إذا كان هناك أي خطأ في رسالة التحديث، فسيتم إرسال رسالة إشعار إلى النظير، ويعود بروتوكول BGP إلى حالة الخمول.

اتصال جهاز التوجيه وتعلم المسارات

في أبسط ترتيب، يجب تكوين جميع أجهزة التوجيه داخل نظام مستقل واحد والمشاركة في توجيه بروتوكول BGP في شبكة كاملة: يجب تكوين كل جهاز توجيه كنظير لكل جهاز توجيه آخر. يتسبب هذا في مشاكل في قابلية التوسع، حيث يزداد عدد الاتصالات المطلوبة بشكل تربيعي مع عدد أجهزة التوجيه المشاركة. للتخفيف من هذه المشكلة، يوفر بروتوكول BGP خيارين: عاكسات المسار (RFC 4456) واتحادات BGP (RFC 5065). يفترض النقاش التالي حول معالجة التحديثات الأساسية وجود شبكة iBGP كاملة.

قد يقبل موجه BGP تحديثات معلومات إمكانية الوصول على مستوى الشبكة (NLRI) من عدة جيران، ويعلن عن هذه المعلومات لنفس الجيران أو لمجموعة مختلفة منهم. وتحتفظ عملية BGP بعدة قواعد بيانات لمعلومات التوجيه .

  • RIB: جدول قاعدة بيانات معلومات التوجيه الرئيسية لأجهزة التوجيه.
  • Loc-RIB: قاعدة معلومات التوجيه المحلية: يحتفظ بروتوكول BGP بجدول التوجيه الرئيسي الخاص به بشكل منفصل عن جدول التوجيه الرئيسي لجهاز التوجيه.
  • Adj-RIB-In: بالنسبة لكل جار، تحتفظ عملية BGP بقاعدة معلومات توجيه مجاورة مفاهيمية، واردة ، تحتوي على NLRI المستلم من الجار.
  • Adj-RIB-Out: بالنسبة لكل جار، تحتفظ عملية BGP بقاعدة معلومات توجيه مجاورة مفاهيمية، صادرة ، تحتوي على NLRI المرسل إلى الجار.

يُحدد مُنفذ كود بروتوكول BGP التخزين المادي وبنية هذه الجداول المفاهيمية. لا تكون بنيتها مرئية لأجهزة توجيه BGP الأخرى، على الرغم من إمكانية الاستعلام عنها عادةً باستخدام أوامر الإدارة على جهاز التوجيه المحلي. من الشائع، على سبيل المثال، تخزين كل من جدول التوجيه (RIB) وجدول التوجيه الفرعي Adj-RIB-In( RIB Adj-RIB-Out) معًا Loc-RIBفي نفس بنية البيانات ، مع إرفاق معلومات إضافية بإدخالات جدول التوجيه الفرعي. تُخبر هذه المعلومات الإضافية عملية BGP بأمور مثل ما إذا كانت إدخالات مُعينة تنتمي إلى جدول Adj-RIBsالتوجيه الفرعي لجيران مُحددين، وما إذا كانت عملية اختيار مسار النظير-الجار قد جعلت السياسات المُستلمة مؤهلة لجدول التوجيه الفرعي Loc-RIB، وما إذا Loc-RIBكانت الإدخالات مؤهلة للإرسال إلى عملية إدارة جدول التوجيه لجهاز التوجيه المحلي.

يُرسل بروتوكول BGP المسارات التي يراها الأنسب إلى عملية جدول التوجيه الرئيسي. وبحسب آلية تنفيذ هذه العملية، قد لا يتم اختيار مسار BGP بالضرورة. على سبيل المثال، يُفضّل عادةً استخدام بادئة متصلة مباشرةً، يتم الحصول عليها من جهاز التوجيه نفسه. وطالما أن واجهة هذا المسار المتصل مباشرةً نشطة، فلن يُضاف مسار BGP إلى الوجهة في جدول التوجيه. بمجرد تعطل الواجهة وعدم وجود مسارات مفضلة أخرى، يُضاف مسار Loc-RIB إلى جدول التوجيه الرئيسي.

يحمل بروتوكول BGP المعلومات التي تُمكّن القواعد داخل أجهزة التوجيه التي تستخدم BGP من اتخاذ قرارات السياسة. ومن بين المعلومات التي يتم حملها والمخصصة صراحةً لاستخدامها في قرارات السياسة ما يلي:

عملية اختيار المسار

يحدد معيار BGP عددًا من عوامل القرار، أكثر من تلك المستخدمة في أي عملية توجيه شائعة أخرى، لاختيار NLRI لإدراجه في جدول التوجيه المحلي (Loc-RIB). أول معيار لتقييم NLRI هو أن يكون عنوان الوجهة التالية قابلاً للوصول (أو قابلاً للتحليل). بعبارة أخرى، يجب أن يكون عنوان الوجهة التالية قابلاً للوصول، أي أن يكون هناك مسار نشط، موجود بالفعل في جدول التوجيه الرئيسي للموجه، إلى البادئة التي يمكن الوصول من خلالها إلى عنوان الوجهة التالية.

بعد ذلك، يطبق بروتوكول BGP، لكل جار، معايير قياسية ومعيارية مختلفة تعتمد على التنفيذ لتحديد المسارات التي ينبغي إدراجها في جدول توجيه الجوار (Adj-RIB-In). يمكن للجار إرسال عدة مسارات محتملة إلى وجهة معينة، ولكن الأولوية تُعطى لمستوى الجار. سيتم تثبيت مسار واحد فقط لكل وجهة في جدول توجيه الجوار (Adj-RIB-In). كما ستحذف هذه العملية أي مسارات يسحبها الجار من جدول توجيه الجوار (Adj-RIB-In).

عند حدوث أي تغيير في جدول التوجيه الداخلي (Adj-RIB-In)، يقرر بروتوكول BGP الرئيسي ما إذا كانت أي من المسارات الجديدة للجيران مفضلة على المسارات الموجودة بالفعل في جدول التوجيه المحلي (Loc-RIB). في حال تفضيلها، يتم استبدالها. إذا قام أحد الجيران بسحب مسار معين، ولم يكن هناك مسار آخر إلى تلك الوجهة، يُزال المسار من جدول التوجيه المحلي (Loc-RIB) ولا يُرسله بروتوكول BGP إلى مدير جدول التوجيه الرئيسي. إذا لم يكن لدى الموجه مسار إلى تلك الوجهة من أي مصدر غير BGP، فسيتم إزالة المسار المسحوب من جدول التوجيه الرئيسي.

طالما استمر التعادل ، تنتقل عملية اختيار المسار إلى الخطوة التالية.

خطوات تحديد أفضل مسار، حسب ترتيب كسر التعادل : [ 19 ] [ 20 ]
خطوةنِطَاقاسمتقصيرمفضلحقل BGPملحوظات
1محلي إلى جهاز التوجيهالوزن المحلي"عن"أعلىمعلمات خاصة بشركة سيسكو
2داخلي لـ ASالتفضيل المحلي"إيقاف"، تم ضبط كل شيء على 100.أعلىتفضيلات محليةإذا كان هناك عدة مسارات iBGP من الجار، فسيتم اختيار المسار ذي الأفضلية المحلية الأعلى ما لم يكن هناك عدة مسارات لها نفس الأفضلية المحلية.
3بروتوكول البوابة الداخلية المتراكمة (AIGP)"عن"الأقل سعرًاالحكومة الألمانيةRFC 7311 
4خارج نطاق ASقفزات النظام المستقل (AS)"تشغيل"، يتم تخطيه إذا تم تجاهله في الإعداداتالأقل سعرًامسار ASعدد القفزات في نظام التوجيه الذاتي (AS) هو عدد أرقام نظام التوجيه الذاتي التي يجب اجتيازها للوصول إلى الوجهة المعلن عنها. يُعد المسار AS1–AS2–AS3 أقصر ويحتوي على عدد قفزات أقل من المسار AS4–AS5–AS6–AS7.
5نوع المنشأ"IGP"الأقل سعرًاأصل٠ = IGP ١ = EGP ٢ = غير مكتمل
6مُمَيِّز المخارج المتعددة (MED)"تشغيل"، مستورد من نظام مستقل نظيرالأقل سعرًاقرص متعدد المخارجافتراضيًا، تتم مقارنة المسارات التي لها نفس النظام المستقل (AS) فقط. يمكن ضبط الإعدادات لتجاهل ذلك. افتراضيًا، لا تتم إضافة مقياس بروتوكول التوجيه الداخلي (IGP). يمكن ضبط الإعدادات لإضافة مقياس بروتوكول التوجيه الداخلي (IGP).

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

7محلي إلى جهاز التوجيه (Loc-RIB)مسارات eBGP عبر مسارات iBGP"على"متصل مباشرة، عبر اتصال غير مباشر
8مقياس IGP إلى القفزة التالية لبروتوكول BGP"تشغيل"، مستورد من IGPالأقل سعرًايُفضّل استخدام المسار ذي التكلفة الداخلية الأقل للوصول إلى الوجهة التالية، وفقًا لجدول التوجيه الرئيسي. فإذا أعلن جاران عن نفس المسار، وكان أحدهما متاحًا عبر رابط ذي معدل نقل بيانات منخفض والآخر عبر رابط ذي معدل نقل بيانات عالٍ، وقام بروتوكول التوجيه الداخلي بحساب أقل تكلفة بناءً على أعلى معدل نقل بيانات، فسيتم تفضيل المسار عبر الرابط ذي معدل نقل البيانات العالي وتجاهل المسارات الأخرى.

إذا تم استخدام امتداد BGP لدعم التوجيه متعدد المسارات ، فقد يتوقف اختيار أفضل مسار هنا، وسيتم إضافة جميع المسارات المختارة حتى هذه النقطة إلى جدول التوجيه.

9المسار الذي تم استلامه أولاً"على"الأقدميُستخدم لتجاهل التغييرات في الخطوات التالية لتقليل تقلبات المسار.
10معرّف جهاز التوجيه المجاور"على"الأقل سعرًا
11طول قائمة المجموعات"على"الأقل سعرًا
12عنوان IP المجاور"على"الأقل سعرًا

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

المجتمعات

مجتمعات بروتوكول بوابة الحدود (BGP) هي علامات سمات يمكن تطبيقها على البادئات الواردة أو الصادرة لتحقيق هدف مشترك. [ 21 ] على الرغم من شيوع القول بأن بروتوكول BGP يسمح للمسؤول بوضع سياسات حول كيفية تعامل مزودي خدمة الإنترنت مع البادئات، إلا أن هذا غير ممكن عمليًا. فعلى سبيل المثال، لا يتضمن بروتوكول BGP في جوهره مفهومًا يسمح لنظام مستقل (AS) بإبلاغ نظام مستقل آخر بتقييد الإعلان عن بادئة ما لعملاء التناظر في أمريكا الشمالية فقط. بدلًا من ذلك، ينشر مزود خدمة الإنترنت عادةً قائمة بمجتمعات معروفة أو خاصة مع وصف لكل منها، وهو ما يُشكل في جوهره اتفاقًا حول كيفية التعامل مع البادئات.

مجتمعات BGP المعروفة [ 22 ]
قيمة السمةيصفوصفمرجع
0x00000000–0x0000FFFFمحجوزRFC 1997 
0x00010000–0xFFFEFFFFمخصص للاستخدام الخاصRFC 1997 
0xFFFF0000إغلاق سلسفي جهاز AS-peer المجاور، قم بتعيين LOCAL_PREF، وخفضه لتوجيه المسار بعيدًا عن المصدر.RFC 8326 
0xFFFF0001قبول الملكيةتُستخدم هذه الطريقة لتعديل كيفية استيراد مسار نشأ داخل شبكة VRF واحدة إلى شبكات VRF أخرى.RFC 7611 
0xFFFF0002ROUTE_FILTER_TRANSLATED_v4مسودة RFC-l3vpn-legacy-rtc
0xFFFF0003ROUTE_FILTER_v4مسودة RFC-l3vpn-legacy-rtc
0xFFFF0004ROUTE_FILTER_TRANSLATED_v6مسودة RFC-l3vpn-legacy-rtc
0xFFFF0005ROUTE_FILTER_v6مسودة RFC-l3vpn-legacy-rtc
0xFFFF0006LLGR_STALEيتم الاحتفاظ بالمسارات القديمة لفترة أطول بعد فشل الجلسةRFC 9494 
0xFFFF0007NO_LLGRلا ينبغي تطبيق إمكانية LLGRRFC 9494 
0xFFFF0008قبول المتجر التالي الخاص بكRFC draft-agrewal-idr-accept-own-nexthop
0xFFFF0009معدات احتياطيةالسماح باستعادة الاتصال بشكل أسرع في حالات الأعطال المختلفة، مع البث المتعدد في شبكات VPN من نوع BGP/MPLS.RFC 9026 
0xFFFF029Aثقب أسودللحماية المؤقتة من هجوم حجب الخدمة عن طريق مطالبة نظام AS المجاور بتجاهل جميع حركة المرور إلى البادئة (الحجب).RFC 7999 
0xFFFFFF01ممنوع التصديرالحد إلى حدود اتحاد BGPRFC 1997 
0xFFFFFF02ممنوع الإعلانيقتصر على نظير BGPRFC 1997 
0xFFFFFF03اتحاد فرعي لا للتصديريقتصر على مستوى ASRFC 1997 
0xFFFFFF04لا مثيل له"لا حاجة" للإعلان عبر رابط نظير إلى نظيرRFC 3765 

ومن أمثلة المجتمعات المشتركة ما يلي:

  • تعديلات التفضيلات المحلية،
  • جغرافي
  • قيود نوع النظراء
  • تحديد هجمات حجب الخدمة
  • خيارات البادئة AS.

قد يذكر مزود خدمة الإنترنت أن أي مسارات يتم استلامها من العملاء لها أمثلة على ذلك:

  • إلى عملاء أمريكا الشمالية (الساحل الشرقي) 3491:100
  • إلى عملاء أمريكا الشمالية (الساحل الغربي) 3491:200

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

من الأساليب الشائعة لدى المستخدمين النهائيين استخدام مجتمعات بروتوكول بوابة الحدود (عادةً ASN:70، 80، 90، 100) للتحكم في الأفضلية المحلية التي يخصصها مزود خدمة الإنترنت للمسارات المُعلَن عنها بدلاً من استخدام MED (والنتيجة متشابهة). سمة المجتمع متعدية، ولكن نادرًا ما تنتشر المجتمعات التي يطبقها المستخدم خارج نطاق نظام التوجيه الذاتي للقفزة التالية. ولا تُفصح جميع شركات تزويد خدمة الإنترنت عن مجتمعاتها للعامة. [ 25 ]

سمة المجتمع الموسعة لبروتوكول BGP

أُضيفت سمة BGP Extended Community Attribute في عام 2006، [ 26 ] بهدف توسيع نطاق هذه السمات وتوفير بنية لسمات المجتمع باستخدام حقل النوع. يتكون التنسيق الموسع من بايت واحد أو اثنين لحقل النوع، متبوعًا بسبعة أو ستة بايتات لمحتوى سمة المجتمع المعنية. تتولى هيئة IANA إدارة سجل أنواع BGP Extended Communities. [ 27 ]

سمة المجتمعات الموسعة هي سمة اختيارية متعدية في بروتوكول BGP. يحدد بت في حقل النوع ضمن السمة ما إذا كان المجتمع الموسع المشفر ذا طبيعة متعدية أم غير متعدية. ولذلك، يوفر سجل IANA نطاقات أرقام مختلفة لأنواع السمات. ونظرًا لنطاق السمة الموسع، يمكن استخدامها في تطبيقات متعددة. على سبيل المثال، يُعرّف RFC 4360 "المجتمع الموسع الخاص بنظام مستقل ثنائي البايت"، و"المجتمع الموسع الخاص بعنوان IPv4"، و"المجتمع الموسع غير الشفاف"، و"مجتمع هدف المسار"، و"مجتمع منشأ المسار". كما تستخدم العديد من مسودات جودة الخدمة (QoS) لبروتوكول BGP بنية سمة المجتمع الموسع هذه لإشارات جودة الخدمة بين النطاقات. [ 28 ]

مع إدخال أرقام الأنظمة المستقلة (AS) ذات 32 بت، برزت بعض المشكلات فورًا فيما يتعلق بسمة المجتمع التي تُعرّف حقل رقم النظام المستقل (ASN) ذي 16 بت فقط، مما يمنع المطابقة بين هذا الحقل وقيمة رقم النظام المستقل (ASN) الحقيقية. منذ عام 2014، أصبحت المجتمعات الموسعة متوافقة مع أرقام الأنظمة المستقلة (ASN) ذات 32 بت. [ 29 ] ولتوفير دعم لأرقام الأنظمة المستقلة (AS) ذات 32 بت في مجتمعات بروتوكول بوابة الحدود (BGP)، تم تعريف سمة مجتمع كبيرة بحجم 12 بايت، [ 30 ] [ 31 ] مقسمة إلى ثلاثة حقول، كل منها بحجم 4 بايت (AS:function:parameter). [ 32 ]

مُحدِّدات المخارج المتعددة

تم تعريف MEDs في معيار BGP الرئيسي، وكان الهدف منها في الأصل إظهار تفضيل نظام AS المُعلن لأي من الروابط المتعددة المُفضلة لحركة المرور الواردة إلى نظام AS مجاور آخر. ومن تطبيقات MEDs الأخرى الإعلان عن قيمة، والتي تُقاس عادةً بالتأخير، لأنظمة AS متعددة موجودة في نقطة تبادل إنترنت (IXP) ، والتي تفرضها لإرسال حركة المرور إلى وجهة معينة.

بعض أجهزة التوجيه (مثل جونيبر) ستستخدم المقياس من بروتوكول OSPF لتعيين MED.

أمثلة على استخدام MED مع BGP عند تصديرها إلى BGP على Juniper SRX

# تشغيل عرض مسار OSPF جدول التوجيه الافتراضي للطوبولوجيا: البادئة المسار المسار NH المقياس القفزة التالية القفزة التالية  النوع النوع النوع الواجهة العنوان/LSP 10.32.37.0/24 عنوان IP للتجاهل الداخلي 16777215 10.32.37.0/26 عنوان IP داخل الشبكة 101 ge-0/0/1.0 10.32.37.241 10.32.37.64/26 عنوان IP داخل الشبكة 102 ge-0/0/1.0 10.32.37.241 10.32.37.128/26 عنوان IP داخل الشبكة 101 ge-0/0/1.0 10.32.37.241# عرض مسار بروتوكول الإعلان BGP 10.32.94.169  البادئة القفزة التالية MED Lclpref مسار AS * 10.32.37.0/24 ذاتي 16777215 I * 10.32.37.0/26 ذاتي 101 I * 10.32.37.64/26 ذاتي 102 I * 10.32.37.128/26 ذاتي 101 I

تنسيق الحزمة

تنسيق رأس الرسالة

تشترك جميع رسائل بروتوكول بوابة الحدود (BGP) في تخطيط الرأس التالي.

تنسيق رأس رسالة BGP الإصدار 4 [ 11 ] : §4.1
إزاحةثمانية0123
ثمانيةقليل012345678910111213141516171819202122232425262728293031
00علامة  (ff ff ff ff ff ff ff ff ff ff ff ff ff ff)
432
864
1296
16128طوليكتب
العلامة : 128 بت
تم تضمينها للتوافق، ويجب ضبطها على جميع القيم 1.
الطول : 16 بت
الطول الإجمالي للرسالة بالبايتات، بما في ذلك رأس الرسالة.
النوع : 8 بت
نوع رسالة BGP. القيم التالية مُعرّفة:
  • مفتوح (1)
  • التحديث (2)
  • الإخطار (3)
  • حافظ على الحياة (4)
  • تحديث المسار (5)

فتح الحزمة

باستخدام حزمة مفتوحة ، يمكن بدء جلسة BGP.

تنسيق رسالة "مفتوح" في الإصدار الرابع من بروتوكول BGP
إزاحةثمانية0123
ثمانيةقليل012345678910111213141516171819202122232425262728293031
⋮⋮علامة  (ff ff ff ff ff ff ff ff ff ff ff ff ff ff)
16128الطول  (29+)النوع  (1)الإصدار  (4)
20160مجموعتي الدراسيةمدة الانتظار
24192معرّف بروتوكول بوابة الحدود (BGP)
28224طول المعلمات 
30240حدود
34272
⋮⋮
الإصدار : 8 بت
تم استخدام إصدار BGP.
نظام التشغيل الخاص بي : 16 بت
رقم النظام المستقل للمرسل .
مدة التثبيت : 16 بت
مؤقت انتهاء المهلة، يُستخدم لحساب رسائل KeepAlive. القيمة الافتراضية 90 ثانية.
معرّف بروتوكول بوابة الحدود (BGP) : 32 بت
يحتوي على عنوان IP الخاص بالمرسل.
طول المعلمات : 8 بتات
الطول الإجمالي لحقل المعلمات بالبايتات. إذا كان هذا الحقل (إلزامي) [ 11 ] : §4.2 يساوي صفرًا، فلا توجد معلمات في الرسالة.
المعلمات : متغير
معلمات اختيارية. يُستخدم هذا الحقل لتوضيح إمكانيات مُرسِل هذه الحزمة إلى الطرف الآخر. [ 33 ] تحتفظ هيئة IANA بقائمة بجميع هذه الإمكانيات .

مثال على رسالة مفتوحة

النوع: فتح رسالة (1) الإصدار: 4 رقم حسابي في نظام AS: 64496 مدة الانتظار: 90 معرّف بروتوكول بوابة الحدود (BGP): 192.0.2.254 طول المعلمات الاختيارية: 16 المعلمات الاختيارية: القدرة: قدرة امتدادات البروتوكولات المتعددة (1) القدرة: قدرة تحديث المسار (2) القدرة: قدرة محسّنة لتحديث المسار (70)

حزمة التحديث

يتم إرسال التغييرات فقط. بعد التبادل الأولي، يتم إرسال الفروقات فقط (إضافة/تغيير/حذف).

تنسيق رسالة "تحديث" في الإصدار الرابع من بروتوكول BGP
إزاحةثمانية0123
ثمانيةقليل012345678910111213141516171819202122232425262728293031
⋮⋮علامة  (ff ff ff ff ff ff ff ff ff ff ff ff ff ff)
16128الطول  (23+)النوع  (2)طول المسارات المسحوبة ↴
20160↪ الطول (تابع) 
⋮⋮المسارات المسحوبة
⋮⋮إجمالي طول سمة المسار 
⋮⋮سمات المسار
⋮⋮معلومات إمكانية الوصول إلى طبقة الشبكة
⋮⋮
طول المسارات المسحوبة : 16 بت
طول المسارات المسحوبة التالية. قد يكون صفرًا إذا لم يتم سحب أي مسارات.
المسارات المسحوبة : متغير
قائمة بالمسارات المسحوبة، محددة كسلسلة من <الطول، البادئة> صفوف .
طول سمة المسار الإجمالي : 16 بت
طول سمات المسار التالية. قد يكون صفرًا إذا لم تكن هناك سمات.
سمات المسار : متغير
قائمة سمات المسار، محددة كسلسلة من هياكل TLV .
معلومات إمكانية الوصول إلى طبقة الشبكة  (NLRI) : متغير
معلومات إمكانية الوصول، مُحددة كسلسلة من أزواج <الطول، البادئة>. يمكن حساب طول هذا الحقل على النحو التالي: الطول - 23 - طول المسارات المسحوبة - إجمالي طول سمة المسار .

مثال على رسالة التحديث

النوع: رسالة تحديث (2) طول المسارات المسحوبة: 0 إجمالي طول سمة المسار: 25 سمات المسار المنشأ: IGP AS_PATH: 64500 NEXT_HOP: 192.0.2.254 MULTI_EXIT_DISC: 0 معلومات إمكانية الوصول إلى طبقة الشبكة (NLRI) 192.0.2.0/27 192.0.2.32/27 192.0.2.64/27

إشعار

في حال حدوث خطأ، فذلك يعود إلى عدم تطابق أحد الحقول في رسالة OPEN أو UPDATE بين الجهازين. على سبيل المثال: عدم تطابق إصدار بروتوكول BGP، أو توقع جهاز التوجيه المُتصل بالنظير لـ "My AS" مختلف. عندئذٍ، يُرسل جهاز التوجيه رسالة إشعار إلى الجهاز النظير تُوضح سبب الخطأ. عادةً ما يؤدي الخطأ في الاتصال إلى إنهاء جلسة BGP. ولتجنب سلسلة من إنهاء الجلسات بسبب خطأ واحد، وهو ما قد يحدث في سيناريوهات معقدة مع أجهزة توجيه ذات إمكانيات محدودة، تُبذل جهود إضافية لعزل المشكلة والحفاظ على استمرار معظم الجلسات. [ 34 ]

تنسيق رسالة "الإشعار" في الإصدار الرابع من بروتوكول BGP
إزاحةثمانية0123
ثمانيةقليل012345678910111213141516171819202122232425262728293031
⋮⋮علامة  (ff ff ff ff ff ff ff ff ff ff ff ff ff ff)
16128الطول  (21+)النوع  (3)رمز الخطأ
20160رمز الخطأ الفرعي 
24192بيانات
28224
⋮⋮
رمز الخطأ : 8 بتات
قيمة تشير إلى نوع الخطأ أو مصدره.
رمز الخطأ الفرعي : 8 بتات
قيمة تحدد الخطأ الذي حدث.
 رموز الأخطاء  والرموز  الفرعية
رمز الخطأاسمالرموز الفرعية
شفرةاسم
1خطأ في رأس الرسالة1الاتصال غير متزامن
2رسالة سيئة
3نوع رسالة غير صحيح
2رسالة خطأ في فتح الرسالة1رقم الإصدار غير مدعوم.
2نظام نظير سيئ.
3معرف BGP غير صالح.
4رمز مصادقة غير مدعوم.
5فشل المصادقة.
6وقت انتظار غير مقبول.
3رسالة خطأ في التحديث1قائمة السمات غير الصحيحة.
2سمة معروفة غير معترف بها.
3سمة معروفة مفقودة.
4خطأ في علامات السمات.
5خطأ في طول السمة.
6سمة ORIGIN غير صالحة
7حلقة توجيه نظام AS.
8سمة NEXT_HOP غير صالحة.
9خطأ في السمة الاختيارية.
10حقل الشبكة غير صالح.
11مسار AS_PATH غير صحيح.
4انتهى وقت الانتظار
5خطأ في آلة الحالة المحدودة
6توقف
البيانات : متغير
بيانات اختيارية للمساعدة في تشخيص المشكلة.

مثال على رسالة إشعار

النوع: رسالة إشعار (3) رمز الخطأ الرئيسي: خطأ في رسالة الفتح (2) رمز الخطأ البسيط (رسالة مفتوحة): نظام مستقل نظير غير صالح (2) نظير سيئ AS: 65200

حافظ على الحياة

تُرسل رسائل KeepAlive بشكل دوري من كلا طرفي الجلسة للتحقق من أن الطرف البعيد لا يزال متصلاً. ويجب إرسالها على فترات زمنية تساوي ثلث المدة الزمنية المحددة holdtime.

تنسيق رسالة BGP الإصدار 4 'KEEPALIVE'
إزاحةثمانية0123
ثمانيةقليل012345678910111213141516171819202122232425262728293031
⋮⋮علامة  (ff ff ff ff ff ff ff ff ff ff ff ff ff ff)
16128الطول  (19)النوع  (4)

لا تحتوي حزمة "إبقاء الاتصال" على أي محتوى بيانات.

تحديث المسار

إضافة إلى أنواع رسائل BGP الأولية هي تحديث المسار، والذي يسمح بالتحديث التدريجي للمسار Adj-RIB-inدون إعادة ضبط الاتصال. [ 35 ]

قبل استخدام هذه الميزة، يجب تحديد خاصية "تحديث المسار (2)" في رسالة "فتح". ويمكن الحصول على تحديثات دقيقة للمسار عند تحديد خاصية "تحديث المسار المحسّن (70)" أيضًا.

تنسيق رسالة BGP الإصدار 4 'ROUTE-REFRESH'
إزاحةثمانية0123
ثمانيةقليل012345678910111213141516171819202122232425262728293031
⋮⋮علامة  (ff ff ff ff ff ff ff ff ff ff ff ff ff ff)
16128الطول  (23+)النوع  (5)معرّف عائلة العنوان ↴
20160↪ معهد الفيلم الأمريكي (تابع)نوع الرسالة الفرعيصافي 
⋮⋮معلومات إمكانية الوصول إلى طبقة الشبكة
⋮⋮
⋮⋮
معرّف عائلة العناوين  (AFI) : 16 بت
معرف لعائلة العناوين ( IPv4 ، IPv6 ، IPX ، AppleTalk ، إلخ). يتم الاحتفاظ بهذه القائمة بواسطة IANA .
نوع الرسالة الفرعي : 8 بت
يشير هذا الحقل إلى نوع رسالة تحديث المسار هذه. [ 36 ]
معرّف عائلة العناوين اللاحقة : 8 بت
يُقدّم هذا الحقل معلومات إضافية حول نوع معلومات إمكانية الوصول إلى طبقة الشبكة (NLRI) المُضمّنة في السمة. القيم: 1 (بث أحادي)؛ 2 (بث متعدد)؛ 3 (كلاهما).
معلومات إمكانية الوصول إلى طبقة الشبكة  (NLRI) : متغير
معلومات إمكانية الوصول، محددة كسلسلة من <الطول، البادئة> صفوف.

مثال على رسالة تحديث المسار

النوع: رسالة تحديث المسار (5) معرّف عائلة العنوان (AFI): IPv4 (1) النوع الفرعي: طلب تحديث المسار العادي (0) معرف عائلة العنوان اللاحق (SAFI): أحادي البث (1)

قابلية التوسع الداخلي

بروتوكول BGP هو "الأكثر قابلية للتوسع من بين جميع بروتوكولات التوجيه". [ 37 ]

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

عاكسات المسار

تُقلل عاكسات المسار (RRs) من عدد الاتصالات المطلوبة في نظام مستقل (AS). يمكن جعل جهاز توجيه واحد (أو اثنين لضمان التكرار) عاكس مسار: ما عليك سوى تهيئة أجهزة التوجيه الأخرى في النظام المستقل كأقران لها. يوفر عاكس المسار بديلاً لمتطلبات الشبكة الكاملة المنطقية لبروتوكول iBGP. يكمن الغرض من عاكس المسار في التركيز. يمكن لأجهزة توجيه BGP المتعددة الاتصال بنقطة مركزية، وهي عاكس المسار - الذي يعمل كخادم عاكس مسار - بدلاً من الاتصال بكل جهاز توجيه آخر في شبكة كاملة. تصبح جميع أجهزة توجيه iBGP الأخرى عملاء لعاكس المسار. [ 38 ]  

يُوفر هذا النهج، المشابه لميزة DR/BDR في بروتوكول OSPF ، قابلية توسع إضافية لبروتوكول iBGP في الشبكات الكبيرة. ففي شبكة iBGP مترابطة بالكامل تضم 10 أجهزة توجيه، يلزم 90 عبارة سطر أوامر (موزعة على جميع أجهزة التوجيه في البنية) لتحديد نظام التوجيه المستقل البعيد (AS) لكل نظير، مما يُصبح عبئًا إداريًا كبيرًا. بينما يُمكن لبنية RR تقليص هذه العبارات من 90 إلى 18 عبارة فقط، مما يُوفر حلاً عمليًا للشبكات الكبيرة التي تُديرها شركات تزويد خدمة الإنترنت.

يُعدّ جهاز التوجيه المرجعي (RR) نقطة فشل واحدة ، لذا يُنصح بتهيئة جهاز توجيه مرجعي ثانٍ على الأقل لتوفير التكرار. وبما أنه نظير إضافي لأجهزة التوجيه العشرة الأخرى، فإنه يُضاعف تقريبًا عدد أوامر واجهة سطر الأوامر (CLI)، ما يتطلب 20 أمرًا إضافيًا (11 × 2 - 2) في هذه الحالة. في بيئة BGP متعددة المسارات، يُمكن لجهاز التوجيه المرجعي الإضافي أن يُحسّن أداء الشبكة من خلال زيادة إنتاجية التوجيه المحلي إذا كان يعمل كجهاز توجيه تقليدي بدلًا من مجرد خادم توجيه مرجعي مُخصّص.

تُقلل كل من سجلات التوجيه (RRs) والاتحادات عدد نظراء بروتوكول بوابة الحدود الداخلية (iBGP) لكل موجه، وبالتالي تُقلل من عبء المعالجة. تُعد سجلات التوجيه تقنية لتحسين الأداء بشكل أساسي، بينما يمكن استخدام الاتحادات أيضًا لتطبيق سياسات أكثر دقة.

قواعد

تكوين نموذجي لنشر BGP RR. [ 39 ] : §6

تقوم خوادم RR بنشر المسارات داخل نظام AS بناءً على القواعد التالية:

  • يتم دائمًا عكس المسارات إلى نظراء eBGP.
  • لا يتم إرجاع المسارات إلى منشئ المسار.
  • إذا تم استلام مسار من نظير غير عميل، فقم بعكسه على نظراء العميل.
  • إذا تم استلام مسار من نظير عميل، فقم بعكسه على نظراء العميل وغير العميل.

تَجَمَّع

يشكل جهاز التوجيه (RR) وعملاؤه مجموعة . يُلحق مُعرّف المجموعة بكل مسار يُعلنه جهاز التوجيه (RR) لنظرائه من العملاء أو غير العملاء. مُعرّف المجموعة هو سمة تراكمية غير متعدية لبروتوكول BGP، ويجب على كل جهاز توجيه (RR) إضافة مُعرّف المجموعة المحلي إلى قائمة المجموعات لتجنب حلقات التوجيه.

الاتحاد الكونفدرالي

الاتحادات هي مجموعات من الأنظمة المستقلة. في الممارسة الشائعة، [ 40 ] لا يرى الإنترنت ككل سوى رقم نظام مستقل واحد من أرقام الاتحاد. تُستخدم الاتحادات في الشبكات الكبيرة جدًا حيث يمكن تهيئة نظام مستقل كبير ليشمل أنظمة مستقلة داخلية أصغر وأسهل إدارة.

يتألف نظام AS المتحد من عدة أنظمة AS. كل نظام AS متحد لديه اتصال iBGP كامل، ويرتبط بأنظمة AS أخرى داخل الاتحاد. على الرغم من وجود نظراء eBGP لهذه الأنظمة داخل الاتحاد، إلا أنها تتبادل التوجيه كما لو كانت تستخدم iBGP. بهذه الطريقة، يحافظ الاتحاد على معلومات القفزة التالية، والمقياس، والتفضيل المحلي. بالنسبة للعالم الخارجي، يبدو الاتحاد كنظام AS واحد. مع هذا الحل، يمكن حل مشاكل عبور iBGP لأنظمة AS، حيث يتطلب iBGP اتصالاً كاملاً بين جميع موجهات BGP، مما يؤدي إلى عدد كبير من جلسات TCP وتكرار غير ضروري لحركة مرور التوجيه.

يمكن استخدام الاتحادات بالتزامن مع عاكسات المسار. وقد تتعرض كل من الاتحادات وعاكسات المسار لتذبذب مستمر ما لم يتم اتباع قواعد تصميم محددة، تؤثر على كل من بروتوكول بوابة الحدود (BGP) وبروتوكول التوجيه الداخلي. [ 41 ]

قد تُسبب هذه البدائل مشاكل خاصة بها، بما في ذلك ما يلي:

  • تذبذب المسار
  • التوجيه دون المستوى الأمثل
  • زيادة وقت تقارب بروتوكول BGP [ 42 ]

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

استقرار

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

تُدمج خاصية تُعرف باسم "تخميد تقلبات المسار" في العديد من تطبيقات بروتوكول بوابة الحدود (BGP) [ 43 ] ، وذلك في محاولة للتخفيف من آثار تقلبات المسار. فبدون التخميد، قد يتسبب النشاط المفرط في تحميل زائد على أجهزة التوجيه، مما قد يؤدي بدوره إلى تأخير تحديثات المسارات الأخرى، وبالتالي التأثير على استقرار التوجيه بشكل عام. مع التخميد، يتلاشى تقلب المسار بشكل أُسّي . في المرة الأولى، عندما يصبح المسار غير متاح ثم يعود للظهور بسرعة، لا يُفعّل التخميد، وذلك للحفاظ على أوقات تجاوز الأعطال الطبيعية لبروتوكول BGP. عند حدوث ذلك للمرة الثانية، يتجنب بروتوكول BGP هذا المسار لفترة زمنية محددة؛ ويتم تجاهل الحالات اللاحقة لفترة أطول بشكل أُسّي. بعد توقف الحالات الشاذة ومرور فترة زمنية مناسبة للمسار المُسبب للمشكلة، يمكن إعادة المسارات إلى وضعها الطبيعي. كما يُمكن للتخميد أيضًا التخفيف من هجمات حجب الخدمة .

يُقترح أيضًا أن يكون تخميد تقلبات المسار ميزةً مرغوبةً أكثر عند تطبيقها على جلسات بروتوكول بوابة الحدود الخارجية (جلسات eBGP أو ما يُسمى ببساطة النظراء الخارجيين) وليس على جلسات بروتوكول بوابة الحدود الداخلية (جلسات iBGP أو ما يُسمى ببساطة النظراء الداخليين). [ 43 ] : §4 مع هذا النهج، عندما يتقلب مسارٌ داخل نظامٍ مستقل، لا ينتشر هذا التقلب إلى الأنظمة المستقلة الخارجية - إذ أن تقلب مسارٍ إلى eBGP سيؤدي إلى سلسلة من التقلبات لهذا المسار المحدد عبر العمود الفقري للشبكة. كما تتجنب هذه الطريقة بنجاح عبء تخميد تقلبات المسار لجلسات iBGP. 

أظهرت الأبحاث اللاحقة أن التخميد الناتج عن التذبذب قد يُطيل أوقات التقارب في بعض الحالات، وقد يتسبب في انقطاعات في الاتصال حتى عندما لا تتذبذب الروابط. [ 44 ] [ 45 ] علاوة على ذلك، مع ازدياد سرعة روابط العمود الفقري ومعالجات الموجهات، أشار بعض مهندسي الشبكات إلى أن التخميد الناتج عن التذبذب قد لا يكون بنفس أهميته السابقة، نظرًا لقدرة الموجهات على معالجة التغييرات في جدول التوجيه بسرعة أكبر بكثير. [ 43 ] وقد دفع هذا فريق عمل التوجيه التابع لـ RIPE إلى كتابة ما يلي: "مع التطبيقات الحالية للتخميد الناتج عن التذبذب في بروتوكول BGP، لا يُنصح بتطبيق التخميد الناتج عن التذبذب في شبكات مزودي خدمة الإنترنت. ... في حال تطبيق التخميد الناتج عن التذبذب، سيتسبب مزود خدمة الإنترنت الذي يُشغل تلك الشبكة في آثار جانبية على عملائه ومستخدمي الإنترنت لمحتوى وخدمات عملائه ... ومن المرجح أن تكون هذه الآثار الجانبية أسوأ من التأثير الناجم عن عدم تشغيل التخميد الناتج عن التذبذب على الإطلاق." [ 46 ]

نمو جدول التوجيه

نمو جداول بروتوكول BGP على الإنترنت
عدد أنظمة AS على الإنترنت مقابل عدد أنظمة AS المسجلة

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

حتى أواخر عام 2001، كان جدول التوجيه العالمي ينمو بشكلٍ متسارع ، مما هدد بانهيار واسع النطاق للاتصالات. في محاولةٍ لمنع ذلك، تعاون مزودو خدمات الإنترنت للحفاظ على جدول التوجيه العالمي في أصغر حجمٍ ممكن باستخدام توجيه النطاقات غير المصنفة (CIDR) وتجميع المسارات . ورغم أن هذا أدى إلى إبطاء نمو جدول التوجيه إلى عملية خطية لعدة سنوات، إلا أنه مع تزايد الطلب على تعدد الاتصالات من قبل شبكات المستخدمين النهائيين، عاد النمو ليصبح أسرع من الخطي بحلول منتصف عام 2004.

512 ألف في اليوم

حدث تجاوز مشابه لمشكلة عام 2000 في عام 2014 بالنسبة لتلك الطرازات التي لم يتم تحديثها بشكل صحيح.

بينما جدول بروتوكول BGP الكامل لبروتوكول IPv4 اعتبارًا من أغسطس 2014(512 ألف يوم) [ 47 ] [ 48 ] تجاوز 512 ألف بادئة، [ 49 ] وكان لدى العديد من أجهزة التوجيه القديمة حد أقصى يبلغ 512 ألف (512,000-524,288) [ 50 ] [ 51 ] من مدخلات جدول التوجيه. في 12 أغسطس 2014، تسببت جداول التوجيه الممتلئة في انقطاعات في خدمات eBay و LastPass و Microsoft Azure ، من بين خدمات أخرى. [ 52 ] كان عدد من أجهزة توجيه Cisco الشائعة الاستخدام مزودة بذاكرة TCAM ، وهي نوع من ذاكرة الوصول العشوائي عالية السرعة ، لتخزين مسارات BGP المعلن عنها. في أجهزة التوجيه المتأثرة، تم تخصيص ذاكرة TCAM افتراضيًا على شكل 512 ألف مسار IPv4 و256 ألف مسار IPv6. بينما بلغ عدد مسارات IPv6 المُعلنة حوالي 20 ألف مسار فقط، وصل عدد مسارات IPv4 المُعلنة إلى الحد الأقصى الافتراضي، مما تسبب في زيادة غير متوقعة في عدد المسارات، حيث حاولت أجهزة التوجيه تعويض هذه المشكلة باستخدام توجيه برمجي بطيء (بدلاً من التوجيه المادي السريع عبر ذاكرة TCAM). وتتمثل الطريقة الرئيسية للتعامل مع هذه المشكلة في قيام المشغلين بتغيير تخصيص ذاكرة TCAM للسماح بمزيد من مسارات IPv4 عن طريق إعادة تخصيص جزء من ذاكرة TCAM المحجوزة لمسارات IPv6، وهو ما يتطلب إعادة تشغيل معظم أجهزة التوجيه. وقد توقع عدد من متخصصي تكنولوجيا المعلومات مشكلة الـ 512 ألف مسار. [ 53 ] [ 54 ] [ 55 ]

كانت التخصيصات الفعلية، التي رفعت عدد المسارات إلى أكثر من 512 ألف مسار، هي الإعلان عن حوالي 15 ألف مسار جديد في وقت قصير، بدءًا من الساعة 07:48 بالتوقيت العالمي المنسق. كانت جميع هذه المسارات تقريبًا إلى أنظمة فيريزون المستقلة 701 و705، والتي أُنشئت نتيجةً لفك تجميع الكتل الأكبر، مما أدى إلى ظهور آلاف المسارات الجديدة من نوع / 24 ، ووصول جدول التوجيه إلى 515 ألف مدخل. يبدو أنه أُعيد تجميع المسارات الجديدة في غضون 5 دقائق، لكن عدم الاستقرار عبر الإنترنت استمر على ما يبدو لعدة ساعات. [ 56 ] حتى لو لم تكن فيريزون هي السبب في تجاوز جدول التوجيه 512 ألف مدخل في تلك الفترة القصيرة، لكان ذلك قد حدث سريعًا من خلال النمو الطبيعي.

يُستخدم تلخيص المسارات غالبًا لتحسين تجميع جدول التوجيه العالمي لبروتوكول BGP، مما يقلل من حجم الجدول المطلوب في أجهزة التوجيه الخاصة بنظام مستقل (AS). على سبيل المثال، إذا تم تخصيص نطاق العناوين الكبير 172.16.0.0/16 لنظام AS1 ، فسيتم احتسابه كمسار واحد في الجدول. ولكن نظرًا لمتطلبات العملاء أو لأغراض هندسة حركة البيانات، يرغب نظام AS1 في الإعلان عن مسارات أصغر وأكثر تحديدًا، وهي 172.16.0.0/18 و 172.16.64.0 / 18 و 172.16.128.0 / 18 . لا يحتوي البادئة 172.16.192.0/18 على أي مضيفين ، لذا لا يُعلن نظام AS1 عن مسار محدد بهذا العنوان . وبذلك ، يُحتسب كل هذا على أنه إعلان من نظام AS1 عن أربعة مسارات.

سيرى AS2 المسارات الأربعة من AS1 ( 172.16.0.0 / 16 ، 172.16.0.0 / 18 ، 172.16.64.0 / 18 ، و 172.16.128.0 / 18 )، ويعود الأمر إلى سياسة التوجيه الخاصة بـ AS2 لتحديد ما إذا كان سيتم أخذ نسخة من المسارات الأربعة أم لا، أو، نظرًا لأن 172.16.0.0 / 16 يتداخل مع جميع المسارات المحددة الأخرى، تخزين الملخص فقط، 172.16.0.0 / 16 .

إذا أراد نظام AS2 إرسال بيانات إلى البادئة 172.16.192.0 / 18 ، فسيتم إرسالها إلى أجهزة توجيه نظام AS1 عبر المسار 172.16.0.0 / 16. عند نظام AS1، سيتم إما إسقاطها أو إرسال رسالة ICMP تفيد بأن الوجهة غير قابلة للوصول، وذلك حسب إعدادات أجهزة توجيه نظام AS1.

إذا قرر نظام AS1 لاحقًا حذف المسار 172.16.0.0/16 ، تاركًا المسارات 172.16.0.0/18 و 172.16.64.0 / 18 و 172.16.128.0 / 18 ، فإن عدد المسارات التي يعلن عنها AS1 سينخفض ​​إلى ثلاثة. وبناءً على سياسة التوجيه الخاصة بنظام AS2، سيقوم بتخزين نسخة من هذه المسارات الثلاثة، أو دمج المسارين 172.16.0.0/18 و 172.16.64.0/18 في المسار 172.16.0.0/17 ، مما يقلل عدد المسارات المخزنة لدى AS2 إلى مسارين ( 172.16.0.0/17 و 172.16.128.0 / 18 ) .

إذا أراد AS2 الآن إرسال البيانات إلى البادئة 172.16.192.0 / 18 ، فسيتم إسقاطها أو سيتم إرسال رسالة ICMP تفيد بأن الوجهة غير قابلة للوصول إلى أجهزة التوجيه الخاصة بـ AS2 (وليس AS1 كما كان من قبل)، لأن 172.16.192.0 / 18 غير موجودة في جدول التوجيه.

استنفاد رقم النظام المستقل وأرقام الأنظمة المستقلة ذات 32 بت

في عام 1995، اعتمدت أول مواصفات بروتوكول BGP-4 ترميز أرقام الأنظمة المستقلة على 16 بت، [ 10 ] مما وفر 64,510 رقمًا عامًا محتملاً للأنظمة المستقلة. [ أ ] في عام 2011، لم يتبق سوى 15,000 رقم نظام مستقل، وتوقعت التنبؤات [ 57 ] نفادًا تامًا لأرقام الأنظمة المستقلة المتاحة في سبتمبر 2013.

في عام 2007، تم توسيع ترميز AS من 16 إلى 32 بت، [ 58 ] مع الإبقاء على نطاق AS ذي 16 بت (من 0 إلى 65535) وأرقام AS المحجوزة. يتيح هذا الآن ما يصل إلى 4 مليارات رقم AS متاح. كما تم تعريف نطاق AS خاص إضافي. [ 59 ] [ ب ] للسماح بمرور مجموعات الموجهات غير القادرة على إدارة أرقام AS الجديدة هذه، يتم استخدام السمة الجديدة AS4_PATH (اختيارية متعدية) ورقم AS الخاص ذي 16 بت AS_TRANS (AS23456). [ 61 ] بدأ تخصيص أرقام AS ذات 32 بت في عام 2007.

موازنة الأحمال

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

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

إحدى طرق معالجة مشكلة جدول التوجيه المرتبطة بموازنة الأحمال هي نشر بوابات بروتوكول فصل المحددات/المعرفات (BGP/LISP) ضمن نقطة تبادل الإنترنت للسماح بهندسة حركة المرور الواردة عبر روابط متعددة. لا تزيد هذه التقنية من عدد المسارات الظاهرة في جدول BGP العالمي.

حماية

بحكم تصميمها، تقبل أجهزة التوجيه التي تعمل ببروتوكول BGP المسارات المُعلَن عنها من أجهزة توجيه BGP أخرى بشكل افتراضي. يتيح هذا التوجيه التلقائي واللامركزي لحركة البيانات عبر الإنترنت، ولكنه يجعل الإنترنت عرضةً للاضطراب العرضي أو المتعمد، المعروف باسم اختطاف BGP . ونظرًا لتغلغل بروتوكول BGP في الأنظمة الأساسية للإنترنت، وكثرة الشبكات المختلفة التي تُشغّلها العديد من المؤسسات التي تُشكّل مجتمعةً الإنترنت، فإن معالجة هذه الثغرة الأمنية (مثل استخدام مفاتيح التشفير للتحقق من هوية أجهزة توجيه BGP) تُعدّ مشكلةً صعبةً من الناحيتين التقنية والاقتصادية. [ 62 ]

الإضافات

بروتوكول MBGP (امتدادات البروتوكولات المتعددة لبروتوكول BGP)، والذي يُشار إليه أحيانًا باسم بروتوكول BGP متعدد البروتوكولات أو بروتوكول BGP متعدد البث، والمُعرّف في RFC 4760 ، هو امتداد لبروتوكول BGP يسمح بتوزيع أنواع مختلفة من العناوين (المعروفة باسم عائلات العناوين) بالتوازي. بينما يدعم بروتوكول BGP القياسي عناوين IPv4 أحادية البث فقط، يدعم بروتوكول BGP متعدد البروتوكولات عناوين IPv4 وIPv6، كما يدعم متغيرات أحادية البث ومتعددة البث لكل منهما. يسمح بروتوكول BGP متعدد البروتوكولات بتبادل معلومات حول بنية طوبولوجيا أجهزة التوجيه القادرة على البث المتعدد عبر بروتوكول الإنترنت بشكل منفصل عن طوبولوجيا أجهزة التوجيه أحادية البث العادية من نوع IPv4. وبالتالي، فإنه يسمح بطوبولوجيا توجيه متعددة البث تختلف عن طوبولوجيا توجيه أحادية البث. على الرغم من أن بروتوكول MBGP يُتيح تبادل معلومات توجيه البث المتعدد بين النطاقات، إلا أنه يتطلب بروتوكولات أخرى، مثل عائلة بروتوكول البث المتعدد المستقل عن البروتوكول، لبناء الأشجار وتوجيه حركة مرور البث المتعدد. يتم أيضًا نشر بروتوكول BGP متعدد البروتوكولات على نطاق واسع في حالة MPLS L3 VPN، لتبادل تسميات VPN التي تم تعلمها للمسارات من مواقع العملاء عبر شبكة MPLS، وذلك للتمييز بين مواقع العملاء المختلفة عندما تأتي حركة المرور من مواقع العملاء الأخرى إلى جهاز توجيه الحافة الخاص بالمزود للتوجيه. 

يُعدّ التوجيه متعدد المسارات امتدادًا آخر لبروتوكول BGP . ويتطلب هذا عادةً تطابقًا في كلٍّ من MED والوزن والمنشأ ومسار AS، مع أن بعض التطبيقات تُتيح إمكانية تخفيف شرط التحقق من مسار AS بحيث يُشترط فقط تساوي طول المسار، بدلًا من اشتراط تطابق أرقام AS الفعلية فيه. ويمكن توسيع هذا الامتداد باستخدام ميزات مثل dmzlink-bw من Cisco، التي تُتيح مشاركة حركة البيانات بنسبة مُحددة بناءً على قيم عرض النطاق الترددي المُكوّنة على كل رابط.

يدعم بروتوكول BGP افتراضيًا الإعلان عن أفضل مسار واحد مُختار محليًا فقط إلى جيرانه عبر رسائل التحديث. يُعرّف RFC 7911 امتداد ADD-PATH ، الذي يسمح لجهاز BGP بالإعلان عن مسارات متعددة لنفس الوجهة إلى النظراء. أحد تطبيقات ذلك هو عند استخدام عاكسات المسار (RRs)، حيث يُمكن لعاكس المسار حينها الإعلان عن جميع مسارات التوجيه المعروفة لعملائه، بدلًا من إرسال مسار واحد فقط اختاره بناءً على عملية اتخاذ القرار المحلية، والذي غالبًا ما لا يكون أفضل مسار لجميع عملائه. 

الاستخدامات

يُعدّ بروتوكول BGP4 معيارًا لتوجيه الإنترنت، وهو مطلوب من معظم مزودي خدمة الإنترنت لإنشاء مسارات التوجيه فيما بينهم. تستخدم شبكات IP الخاصة الكبيرة جدًا بروتوكول BGP داخليًا. ومن الأمثلة على ذلك ربط عدد من شبكات OSPF الكبيرة عندما لا يكون بروتوكول OSPF وحده كافيًا لتلبية احتياجات الحجم المطلوب. سبب آخر لاستخدام BGP هو تعدد نقاط الوصول في الشبكة لتحسين التكرار، سواءً إلى نقاط وصول متعددة لمزود خدمة إنترنت واحد أو إلى عدة مزودي خدمة إنترنت.

التطبيقات

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

قد تحتوي المنتجات المُسوّقة كمحولات على قيود في حجم جداول بروتوكول بوابة الحدود (BGP) أصغر بكثير من جدول الإنترنت الكامل بالإضافة إلى المسارات الداخلية. قد تكون هذه الأجهزة مناسبة ومفيدة تمامًا عند استخدامها لتوجيه BGP لجزء صغير من الشبكة، مثل اتحاد أنظمة مستقلة (AS) يُمثل إحدى المؤسسات الصغيرة العديدة المرتبطة بشبكة أساسية من الشبكات الأساسية لبروتوكول BGP ، أو مؤسسة صغيرة تُعلن عن مسارات لمزود خدمة الإنترنت ولكنها لا تقبل سوى مسار افتراضي وربما عدد قليل من المسارات المُجمّعة.

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

إذا كان أحد تطبيقات الموجه يستهلك ذاكرة أكبر لكل مسار مقارنةً بتطبيق آخر، فقد يكون هذا خيارًا تصميميًا مشروعًا، حيث يتم المفاضلة بين سرعة المعالجة والذاكرة. جدول بروتوكول بوابة الحدود (BGP) كامل لبروتوكول IPv4 اعتبارًا من سبتمبر 2025.يتجاوز عدد البادئات مليون بادئة. [ 63 ] [ 49 ] وقد تضيف شركات تزويد خدمة الإنترنت الكبيرة 50% أخرى للمسارات الداخلية ومسارات العملاء. ومرة ​​أخرى، اعتمادًا على التنفيذ، قد يتم الاحتفاظ بجداول منفصلة لكل عرض لنظام مستقل نظير مختلف.

من أبرز التطبيقات المجانية والمفتوحة المصدر لبروتوكول BGP ما يلي:

تأتي أنظمة اختبار التوافق مع بروتوكول BGP، وأداء التحميل أو الإجهاد من موردين مثل:

انظر أيضاً

ملحوظات

  1. ↑ تم حجز الأرقام ASN من 64512 إلى 65534 للاستخدام الخاص، بينما الرقمين 0 و65535 ممنوعان.
  2. ↑ الأرقام من 4200000000 إلى 4294967294 خاصة، والرقم 4294967295 محظور. [ 60 ]

وثائق معايير بروتوكول BGP-4

  • RFC 1772 – " تطبيق بروتوكول بوابة الحدود في الإنترنت، " [ 65 ] مسودة المعيار. 
  • RFC 1997 – " سمة مجتمعات BGP، " [ 21 ] معيار مقترح. 
  • RFC 2439 – " تخميد رفرف مسار BGP، " [ 43 ] معيار مقترح. 
  • RFC 2918 – " إمكانية تحديث المسار لـ BGP-4، " [ 35 ] معيار مقترح. 
  • RFC 3765 – " مجتمع NOPEER للتحكم في نطاق مسار بروتوكول بوابة الحدود (BGP) " ، [ 66 ] معلوماتي. 
  • RFC 4271 – " بروتوكول بوابة الحدود 4 (BGP-4) " ، [ 11 ] مسودة معيار. 
  • RFC 4272 – " تحليل نقاط الضعف الأمنية في بروتوكول BGP، " [ 67 ] معلوماتي. 
  • RFC 4273 – " تعريفات الكائنات المُدارة لـ BGP-4، " [ 68 ] معيار مقترح. 
  • RFC 4274 – " تحليل بروتوكول BGP-4، " [ 15 ] معلوماتي. 
  • RFC 4275 – " استطلاع تنفيذ BGP-4 MIB، " [ 69 ] معلوماتي. 
  • RFC 4276 – " تقرير تنفيذ BGP-4، " [ 70 ] إعلامي. 
  • RFC 4277 – " التجربة مع بروتوكول BGP-4، " [ 71 ] معلوماتي. 
  • RFC 4278 – " تباين نضج المعايير فيما يتعلق بخيار توقيع TCP MD5 (RFC 2385) ومواصفات BGP-4، " [ 72 ] معلوماتي. 
  • RFC 4360 – " سمة المجتمعات الموسعة لبروتوكول BGP، " [ 26 ] معيار مقترح. 
  • RFC 4456 – " انعكاس مسار BGP: بديل لشبكة BGP الداخلية الكاملة (IBGP) " ، [ 39 ] مسودة معيار. 
  • RFC 4724 – " آلية إعادة التشغيل السلس لـ BGP، " [ 73 ] معيار مقترح. 
  • RFC 4760 – " امتدادات البروتوكولات المتعددة لـ BGP-4، " [ 14 ] معيار مقترح. 
  • RFC 5065 – " اتحادات الأنظمة المستقلة لبروتوكول BGP، " [ 40 ] مسودة معيار. 
  • RFC 5492 – " إعلان القدرات مع BGP-4، " [ 33 ] مسودة المعيار. 
  • RFC 5701 – " سمة مجتمع BGP الموسعة الخاصة بعنوان IPv6، " [ 74 ] معيار مقترح. 
  • RFC 6793 – " دعم BGP لمساحة أرقام النظام المستقل (AS) المكونة من أربعة أوكتات، " [ 61 ] معيار مقترح. 
  • RFC 7153 – " سجلات IANA للمجتمعات الموسعة لبروتوكول BGP، " [ 29 ] معيار مقترح. 
  • RFC 7313 – " إمكانية تحديث المسار المحسنة لـ BGP-4، " [ 36 ] المعيار المقترح. 
  • RFC 7606 – " معالجة الأخطاء المنقحة لرسائل BGP UPDATE، " [ 34 ] معيار مقترح. 
  • RFC 7911 – " الإعلان عن مسارات متعددة في BGP، " [ 75 ] معيار مقترح. 
  • RFC 8092 – " سمة المجتمعات الكبيرة لبروتوكول BGP، " [ 30 ] معيار مقترح. 
  • RFC 8195 – " استخدام مجتمعات BGP الكبيرة، " [ 31 ] معلوماتي. 
  • RFC 8642 – " سلوك السياسة لمجتمعات BGP المعروفة جيدًا، " [ 76 ] المعيار المقترح. 
  • RFC 8955 – " نشر قواعد مواصفات التدفق، " [ 77 ] المعيار المقترح. 
  • RFC 9552 – " توزيع معلومات حالة الارتباط وهندسة حركة المرور باستخدام BGP، " [ 78 ] معيار مقترح. 

مراجع

  1. ↑ "تاريخ RFC 1105" . IETF . يونيو 1989. تم الاطلاع عليه في 1 ديسمبر 2023 .
  2. ↑ "شرح بروتوكول بوابة الحدود (BGP)" . Orbit-Computer Solutions.Com . مؤرشف من الأصل بتاريخ 28-09-2013 . تم الاطلاع عليه بتاريخ 08-10-2013 .
  3. ^ سوبرينيو ، جواو لويس (2003). "توجيه الشبكة باستخدام بروتوكولات ناقل المسار: النظرية والتطبيقات" (PDF) . أرشفة (PDF) من النسخة الأصلية بتاريخ 2010-07-14 . تم الاسترجاع في 16 مارس 2018 .
  4. ↑ جابلونر، باولا (2015-03-04). "بروتوكول المنديلين" . متحف تاريخ الحاسوب . تم الاسترجاع في 2024-10-01 .
  5. ↑ ك. لوغيد؛ ي. ريختر (أبريل 1989). بروتوكول بوابة الحدود (BGP) . مجموعة عمل الشبكة. doi : 10.17487/RFC1105 . RFC 1105 .قديم. تم إلغاؤه بموجب RFC 1136 . 
  6. ↑ "تاريخ بروتوكول بوابة الحدود" . blog.datapath.io . مؤرشف من الأصل في 29 أكتوبر 2020.
  7. ↑ ك. لوغيد؛ ي. ريختر (يونيو 1990). بروتوكول بوابة الحدود (BGP) . مجموعة عمل الشبكة. doi : 10.17487/RFC1136 . RFC 1136 .تاريخي. تم إلغاؤه بموجب RFC 1267. يلغي RFC 1136 .  
  8. ↑ ك. لوغيد؛ ي. ريختر (أكتوبر 1991). بروتوكول بوابة الحدود 3 (BGP-3) . مجموعة عمل الشبكة. doi : 10.17487/RFC1267 . RFC 1267 .تاريخي. عفا عليها الزمن RFC 1136 . 
  9. ↑ ي. ريختر ؛ ت. لي، محرران. (يوليو 1994). بروتوكول بوابة الحدود 4 (BGP-4) . مجموعة عمل الشبكة. doi : 10.17487/RFC1654 . RFC 1654 .قديم. تم إلغاؤه بموجب RFC 1771 . 
  10. 1 2 ي. ريختر ؛ ت. لي (مارس 1995). بروتوكول بوابة الحدود 4 (BGP-4) . مجموعة عمل الشبكة. doi : 10.17487/RFC1771 . RFC 1771 .مُلغى. تم إلغاؤه بموجب RFC 4271. يُلغي RFC 1654 .  
  11. 1 2 3 4 ي. ريختر ؛ ت. لي؛ س. هاريس، محررون. (يناير 2006). بروتوكول بوابة الحدود 4 (BGP-4) . مجموعة عمل الشبكة. doi : 10.17487/RFC4271 . RFC 4271 .مسودة معيار. يلغي RFC 1771. تم تحديثه بواسطة RFC 6286 و 6608 و 6793 و 7606 و 7607 و 7705 و 8212 و 8654 و 9072 .  
  12. ↑ تي. بيتس؛ آر. تشاندرا؛ دي. كاتز؛ واي. ريختر (يناير 1998). امتدادات البروتوكولات المتعددة لبروتوكول BGP-4 . مجموعة عمل الشبكة. doi : 10.17487/RFC2283 . RFC 2283 .قديم. تم إلغاؤه بموجب RFC 2858 . 
  13. ↑ تي. بيتس؛ واي. ريختر ؛ آر. تشاندرا؛ دي. كاتز (مايو 2000). امتدادات البروتوكولات المتعددة لبروتوكول BGP-4 . مجموعة عمل الشبكة. doi : 10.17487/RFC2858 . RFC 2858 .مُلغى. يُلغي RFC 2283. تم إلغاؤه بواسطة RFC 4760 .  
  14. 1 2 ت. بيتس؛ ر. تشاندرا؛ ي. ريختر (يناير 2007). امتدادات البروتوكولات المتعددة لبروتوكول BGP-4 . مجموعة عمل الشبكة التابعة لـ IETF . doi : 10.17487/RFC4760 . RFC 4760 .معيار مقترح. تم تحديثه بواسطة RFC 7606. يلغي RFC 2858 .  
  15. 1 2 د. ماير؛ ك. باتيل (يناير 2006). تحليل بروتوكول BGP-4 . مجموعة عمل الشبكة. doi : 10.17487/RFC4274 . RFC 4274 .لأغراض إعلامية.
  16. ↑ ر. تشاندرا؛ ج. سكودر (مايو 2000). إعلان القدرات باستخدام بروتوكول BGP-4 . IETF . doi : 10.17487/RFC2842 . RFC 2842 .
  17. ↑ تي. بيتس وآخرون (يونيو 2000). امتدادات البروتوكولات المتعددة لبروتوكول BGP-4 . IETF . doi : 10.17487/RFC2858 . RFC 2858 . 
  18. ^ إي روزين. ي. ريختر (أبريل 2004). شبكات VPN الخاصة بـ BGP/MPLS . فريق عمل الإنترنت . دوى : 10.17487/RFC2547 . آر إف سي 2547 .
  19. ↑ "خوارزمية اختيار أفضل مسار لبروتوكول BGP " . Cisco.com .
  20. ↑ " فهم اختيار مسار BGP" . Juniper.com .
  21. 1 2 ر. تشاندرا؛ ب. تراينا؛ ت. لي (أغسطس 1996). سمة مجتمعات بروتوكول بوابة الحدود . مجموعة عمل الشبكة. doi : 10.17487/RFC1997 . RFC 1997 .المعيار المقترح. تم تحديثه بواسطة RFC 7606 و 8642 . 
  22. ↑ "مجتمعات بروتوكول بوابة الحدود (BGP) المعروفة" . www.iana.org . تم الاطلاع عليه بتاريخ 4 ديسمبر 2022 .
  23. ↑ "دعم مجتمع BGP | iFog GmbH" . ifog.ch. تم الاطلاع عليه بتاريخ 4 ديسمبر 2022 .
  24. ↑ "مجتمعات BGP" . retn.net . تم الاسترجاع في 2022-12-04 .
  25. ↑ "أدلة مجتمع BGP" . تم الاطلاع عليها بتاريخ 13 أبريل 2015 .
  26. 1 2 س. سانغلي؛ د. تابان؛ ي. ريختر (فبراير 2006). سمة المجتمعات الموسعة لبروتوكول بوابة الحدود . مجموعة عمل الشبكة. doi : 10.17487/RFC4360 . RFC 4360 .المعيار المقترح. تم تحديثه بواسطة RFC 7153 و 7606 . 
  27. ↑ "مجتمعات بروتوكول بوابة الحدود (BGP) الموسعة" . www.iana.org . تم الاطلاع عليه بتاريخ 4 ديسمبر 2022 .
  28. ↑ مسودات IETF بشأن جودة الخدمة المُشار إليها في بروتوكول BGP، مؤرشفة بتاريخ 23 فبراير 2009 في Wayback Machine ، توماس نول، 2008
  29. 1 2 إي. روزن؛ واي. ريختر (مارس 2014). سجلات IANA لمجتمعات BGP الموسعة . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC7153 . ISSN 2070-1721 . RFC 7153 . معيار مقترح. تم تحديثه بواسطة RFC 9184. تحديثات لـ RFC 4360 و 5701 .  
  30. 1 2 ك. باتيل؛ إ. باغدوناس؛ ن. هيليارد (فبراير 2017). ج. هيتز؛ ج. سنايدرز (محرران). سمة المجتمعات الكبيرة لبروتوكول بوابة الحدود . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC8092 . RFC 8092 .المعيار المقترح.
  31. 1 2 ج. سنايدرز؛ ج. هيزلي؛ م. شميدت (يونيو 2017). استخدام مجتمعات BGP الكبيرة . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC8195 . RFC 8195 .لأغراض إعلامية.
  32. ↑ "مجتمعات BGP الكبيرة" . تم الاسترجاع في 27-11-2021 .
  33. 1 2 ج. سكودر؛ ر. تشاندرا (فبراير 2009). إعلان القدرات باستخدام بروتوكول BGP-4 . مجموعة عمل الشبكة. doi : 10.17487/RFC5492 . RFC 5492 .مسودة معيار. تلغي RFC 3392. تم تحديثها بواسطة RFC 8810 .  
  34. 1 2 ب. موهاباترا؛ ك. باتيل (أغسطس 2015). إ. تشين؛ ج. سكودر (محرران). معالجة الأخطاء المُنقحة لرسائل تحديث بروتوكول بوابة الحدود (BGP) . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC7606 . ISSN 2070-1721 . RFC 7606 . المعيار المقترح. تحديثات RFC 1997 و 4271 و 4360 و 4456 و 4760 و 5543 و 5701 و 6368 . 
  35. 1 2 إي. تشين (سبتمبر 2000). إمكانية تحديث المسار لبروتوكول BGP-4 . مجموعة عمل الشبكة. doi : 10.17487/RFC2918 . RFC 2918 .المعيار المقترح. تم تحديثه بواسطة RFC 7313 . 
  36. 1 2 ك. باتيل؛ إ. تشين؛ ب. فينكاتاتشالاباثي (يوليو 2014). تحسين قدرة تحديث المسار لبروتوكول BGP-4 . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC7313 . ISSN 2070-1721 . RFC 7313 . المعيار المقترح. تحديثات RFC 2918 . 
  37. ↑ " بروتوكول بوابة الحدود (BGP)" . Cisco.com .
  38. ↑ تي. بيتس وآخرون (أبريل 2006). انعكاس مسار بروتوكول بوابة الحدود: بديل لبروتوكول بوابة الحدود الداخلي ذي الشبكة الكاملة (iBGP) . IETF . RFC 4456 .  
  39. 1 2 ت. بيتس؛ إ. تشين؛ ر. تشاندرا (أبريل 2006). انعكاس مسار بروتوكول بوابة الحدود: بديل لبروتوكول بوابة الحدود الداخلي الكامل (IBGP) . مجموعة عمل الشبكة. doi : 10.17487/RFC4456 . RFC 4456 .مسودة معيار. تم تحديثها بواسطة RFC 7606. تلغي RFC 2796 و 1966 .  
  40. 1 2 ب. تراينا؛ د. ماكفرسون؛ ج. سكودر (أغسطس 2007). اتحادات الأنظمة المستقلة لبروتوكول BGP . مجموعة عمل الشبكة. doi : 10.17487/RFC5065 . RFC 5065 .مسودة معيار. تم تحديثها بواسطة RFC 9774. تلغي RFC 3065 .  
  41. ↑ د. ماكفرسون؛ ف. جيل؛ د. والتون؛ أ. ريتانا (أغسطس 2002). بروتوكول بوابة الحدود (BGP): حالة تذبذب المسار المستمر . مجموعة عمل الشبكة. doi : 10.17487/RFC3345 . RFC 3345 .لأغراض إعلامية.
  42. ↑ س. هاريس؛ ب. كريشناسوامي؛ م. ليب (يونيو 2005). هـ. بيركويتز؛ إ. ديفيز (محرران). مصطلحات قياس أداء تقارب أجهزة بروتوكول بوابة الحدود في مستوى التحكم . IETF . doi : 10.17487/RFC4098 . RFC 4098 .لأغراض إعلامية.
  43. 1 2 3 4 سي. فيلاميزار؛ آر. تشاندرا؛ آر. جوفيندان (نوفمبر 1998). تخميد تقلبات مسار بروتوكول بوابة الحدود . مجموعة عمل الشبكة. doi : 10.17487/RFC2439 . RFC 2439 .المعيار المقترح.
  44. ↑ "تخميد تقلبات المسار يُفاقم تقارب توجيه الإنترنت" (ملف PDF) . نوفمبر 1998. مؤرشف (ملف PDF) من الأصل بتاريخ 2022-10-09.
  45. ↑ تشانغ، بيتشوان؛ بي دان؛ دانيال ماسي؛ ليكسيا تشانغ (يونيو 2005). "تفاعل المؤقت في تخميد تقلبات المسار" (ملف PDF) . المؤتمر الدولي الخامس والعشرون لأنظمة الحوسبة الموزعة التابع لمعهد مهندسي الكهرباء والإلكترونيات . تاريخ الاسترجاع: 26 سبتمبر 2006. نُبين أن تصميم التخميد الحالي لا يُحقق السلوك المطلوب إلا في حالة تقلبات المسار المستمرة. عندما يكون عدد التقلبات قليلاً، تنحرف ديناميكيات التوجيه العالمية بشكل ملحوظ عن السلوك المتوقع مع تأخير أطول في التقارب.
  46. ↑ "توصيات فريق عمل توجيه RIPE بشأن تخميد رفرفة المسار" . مركز تنسيق شبكة RIPE. 10-05-2006 . تم الاطلاع عليه بتاريخ 04-12-2013 .
  47. ↑ "إجراءات ضبط تخصيص ذاكرة الوصول العشوائي TCAM لأجهزة التوجيه والمحولات من سلسلة CAT 6500 و7600" . سيسكو .
  48. ↑ كوي، جيم (13 أغسطس 2014). "الإنترنت يؤثر على نصف مليون مسار: انقطاعات محتملة الأسبوع المقبل" . renesys.com . مؤرشف من الأصل في 13 أغسطس 2014.
  49. 1 2 "تقارير BGP" . potaroo.net .
  50. ↑ "إجراءات تعديل تخصيص ذاكرة الوصول العشوائي TCAM لأجهزة التوجيه والمحولات من سلسلة CAT 6500 و7600" . سيسكو . 9 مارس 2015.
  51. ↑ جيم كاوي. "الإنترنت يؤثر على نصف مليون مسار: انقطاعات محتملة الأسبوع المقبل" . داين ريسيرش . مؤرشف من الأصل بتاريخ 17 أغسطس 2014. تم الاطلاع عليه بتاريخ 2 يناير 2015 .
  52. ↑ غارسيد، جولييت؛ غيبس، صموئيل (14 أغسطس 2014). "البنية التحتية للإنترنت بحاجة إلى تحديث وإلا ستحدث المزيد من انقطاعات التيار الكهربائي"" . صحيفة الغارديان . تم الاطلاع عليه بتاريخ 15 أغسطس 2014 .
  53. ↑ "تقرير BOF" (ملف PDF) . www.nanog.org. مؤرشف (ملف PDF) من الأصل بتاريخ 9 أكتوبر 2022. تم الاطلاع عليه بتاريخ 17 ديسمبر 2019 .
  54. ↑ غريغ فيرو (26 يناير 2011). "TCAM - نظرة معمقة وتأثير IPv6" . إيثريال مايند . 
  55. ↑ "موقع استنزاف عناوين IPv4" . ipv4depletion.com .
  56. ↑ " ما سبب انقطاع الإنترنت اليوم؟ " bgpmon.net
  57. ↑ تقرير النظام المستقل ذو 16 بت ، جيف هوستون (عالم) 2011 (الأصل مؤرشف على https://web.archive.org/web/20110906085724/http://www.potaroo.net/tools/asn16/ )
  58. ↑ كيو. فوهرا؛ إي. تشين (مايو 2007). دعم بروتوكول بوابة الحدود (BGP) لمساحة أرقام الأنظمة المستقلة ذات الأربعة بايتات . مجموعة عمل الشبكة. doi : 10.17487/RFC4893 . RFC 4893 .قديم. تم إلغاؤه بموجب RFC 6793 . 
  59. ↑ ج. ميتشل (يوليو 2013). حجز النظام المستقل (AS) للاستخدام الخاص . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6996 . ISSN 2070-1721 . BCP 6. RFC 6996 . أفضل الممارسات الحالية 6. تحديثات RFC 1930 . 
  60. ↑ ج. هاس؛ ج. ميتشل (يوليو 2014). حجز أرقام النظام المستقل الأخير (AS) . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC7300 . ISSN 2070-1721 . BCP 6. RFC 7300 . أفضل الممارسات الحالية 6. تحديثات RFC 1930 . 
  61. 1 2 كيو. فوهرا؛ إي. تشين (ديسمبر 2012). دعم بروتوكول بوابة الحدود (BGP) لمساحة أرقام النظام المستقل (AS) ذات الأربعة بايتات . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6793 . ISSN 2070-1721 . RFC 6793 . معيار مقترح. يلغي RFC 4893. يُحدّث RFC 4271 .  
  62. ↑ كريغ تيمبرغ (31 مايو 2015). "حل سريع لمشكلة إنترنت مبكرة لا يزال قائماً بعد ربع قرن" . صحيفة واشنطن بوست . تاريخ الاسترجاع: 1 يونيو 2015 .
  63. ↑ "تقرير جدول توجيه IPv4 - اليابان (عرض عالمي) - bgp-stats" . orbit.apnic.net . APNIC . تم الاطلاع عليه بتاريخ 2025-09-20 .
  64. ↑ "زيبرا - مشروع جنو - مؤسسة البرمجيات الحرة" .
  65. ↑ ي. ريختر ؛ ب. غروس (مارس 1995). تطبيق بروتوكول بوابة الحدود في الإنترنت . مجموعة عمل الشبكة. doi : 10.17487/RFC1772 . RFC 1772 .مشروع المعيار. عفا عليها الزمن RFC 1655 . 
  66. ↑ جي. هوستون (أبريل 2004). مجموعة عمل الشبكة NOPEER للتحكم في نطاق مسار بروتوكول بوابة الحدود (BGP) . doi : 10.17487/RFC3765 . RFC 3765 .لأغراض إعلامية.
  67. ↑ إس. مورفي (يناير 2006). تحليل ثغرات أمن بروتوكول بوابة الحدود (BGP) . مجموعة عمل الشبكة. doi : 10.17487/RFC4272 . RFC 4272 .لأغراض إعلامية.
  68. ↑ ج. هاس؛ س. هاريس، محرران. (يناير 2006). تعريفات الكائنات المُدارة لبروتوكول BGP-4 . مجموعة عمل الشبكة. doi : 10.17487/RFC4273 . RFC 4273 .المعيار المقترح. يلغي RFC 1657 و 1269 . 
  69. ↑ س. هاريس؛ د. هاريس (يناير 2006). دراسة استقصائية حول تطبيق BGP-4 MIB . مجموعة عمل الشبكة. doi : 10.17487/RFC4275 . RFC 4275 .لأغراض إعلامية.
  70. ↑ س. هاريس؛ أ. ريتانا (يناير 2006). تقرير تنفيذ بروتوكول BGP-4 . فريق عمل الشبكة. doi : 10.17487/RFC4276 . RFC 4276 .لأغراض إعلامية.
  71. ↑ د. ماكفرسون؛ ك. باتيل (يناير 2006). تجربة مع بروتوكول BGP-4 . مجموعة عمل الشبكة. doi : 10.17487/RFC4277 . RFC 4277 .لأغراض إعلامية.
  72. ↑ س. بيلوفين ؛ أ. زينين (يناير 2006). تباين نضج المعايير فيما يتعلق بخيار توقيع TCP MD5 (RFC 2385) ومواصفات BGP-4 . مجموعة عمل الشبكة. doi : 10.17487/RFC4278 . RFC 4278 .لأغراض إعلامية.
  73. ↑ س. سانغلي؛ إ. تشين؛ ر. فرناندو؛ ج. سكودر؛ ي. ريختر (يناير 2007). آلية إعادة التشغيل السلس لبروتوكول BGP . مجموعة عمل شبكة IETF . doi : 10.17487/RFC4724 . RFC 4724 .معيار مقترح. تم تحديثه بواسطة RFC 8538. تحديثات RFC 4271 .  
  74. ↑ ي. ريختر (أكتوبر 2009). سمة مجتمع BGP الموسعة الخاصة بعنوان IPv6 . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC5701 . RFC 5701 .المعيار المقترح. تم تحديثه بواسطة RFC 7153 و 7606 . 
  75. ↑ د. والتون؛ أ. ريتانا؛ إ. تشين؛ ج. سكودر (يوليو 2016). الإعلان عن مسارات متعددة في بروتوكول BGP . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC7911 . RFC 7911 .المعيار المقترح.
  76. ↑ ج. بوركنهاجن؛ ر. بوش؛ ر. بونيكا؛ س. بايراكتار (أغسطس 2019). سلوك السياسة لمجتمعات BGP المعروفة . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC8642 . ISSN 2070-1721 . RFC 8642 . المعيار المقترح. تحديثات RFC 1997 . 
  77. ↑ سي. لويبل؛ إس. هاريس؛ آر. راسزوك؛ دي. ماكفرسون؛ إم. باخر (ديسمبر 2020). نشر قواعد مواصفات التدفق . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC8955 . ISSN 2070-1721 . RFC 8955 . معيار مقترح. تم تحديثه بواسطة RFC 8956 و 9117 و 9184 . يلغي RFC 5575 و 7674 .  
  78. ↑ ك. تالاوليكار، محرر. (ديسمبر 2023). توزيع معلومات حالة الارتباط وهندسة حركة المرور باستخدام بروتوكول بوابة الحدود (BGP ). فريق عمل هندسة الإنترنت . doi : 10.17487/RFC9552 . ISSN 2070-1721 . RFC 9552 . المعيار المقترح. يلغي RFC 7752 و 9029 . 

للمزيد من القراءة

  • "بروتوكول بوابة الحدود (BGP)" ، دليل تقنية IOS ، شركة سيسكو سيستمز ، مؤرشف من الأصل بتاريخ 2011-07-08
  • فان بيجنوم، إيلجيتش (2002). بغب . شركة أورايلي ميديا ​​ISBN 978-0-596-00254-1تم الاطلاع عليه بتاريخ 31 ديسمبر 2025 .