تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.
ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).
يستخدم هذا المستند Cisco 8000 مع إصدار XR 7.3.1 للتوضيح. ومع ذلك، فإن BGP RPKI هي ميزة غير معتمدة على النظام الأساسي، تنطبق المفاهيم التي تمت مناقشتها في هذا المستند على منصات Cisco الأخرى (مع Cisco IOS، Cisco IOS-XE .) مع تحويلات CLI المكافئة المناسبة. لا يغطي هذا المستند إجراء إضافة أذون أصل المسار (ROAs) في سجلات الإنترنت الإقليمية.
يمثل بروتوكول بوابة الحدود (BGP) العمود الفقري لحركة مرور البيانات عبر الإنترنت. وعلى الرغم من أنه هو أهم مكون لجوهر الإنترنت، إلا أنه يفتقر إلى القدرة على التحقق مما إذا كان إعلان BGP الخاص بالمدخل قد تم إنشاؤه من نظام مستقل مصرح به أم لا.
وهذا التحديد الذي يفرضه بروتوكول بوابة الحدود يجعل منه مرشحا سهلا لأنواع مختلفة من الهجمات. ومن بين الهجمات الشائعة هناك ما يسمى "خطف الطريق". يمكن إستغلال هذا الهجوم من أجل:
هجوم رفض الخدمة (المعروف عادة باسم DoS) عبارة عن محاولة خبيثة لتعطيل حركة المرور العادية إلى الموجه والمحول والخادم وما إلى ذلك. هناك مجموعة متنوعة من هجمات رفض الخدمة (DoS) وهناك القليل من تلك الهجمات التي يتم مناقشتها هنا.
تأملوا في السيناريو الظاهر هنا. يرسل النظام الذاتي 3 (AS3) إعلان BGP القانوني للبادئة الخاصة به 10.0.0.0/24. بواسطة تصميم BGP، لا يوجد في BGP ما يمنع المهاجم من إعلان نفس البادئة للإنترنت.
كما هو موضح، يعلن المهاجم في AS4 عن نفس البادئة 10.0.0.0/24. خوارزمية أفضل مسار BGP تفضل مسار ذو AS_PATH أقصر. حيث فازت AS_PATH 1،5،4 على مسار أطول AS 1،5،2،3. وبالتالي، ستتم الآن إعادة توجيه حركة مرور البيانات من العملاء إلى بيئة المهاجم ويمكن أن تكون سوداء اللون، مما يؤدي إلى منع خدمة العملاء النهائيين.
يناقش هذا القسم طريقة أخرى يمكن بها رفض الخدمات. إذا تم تكوين ميزة تثبيط مسار BGP من Cisco، يمكن إستخدامها إذا قام المهاجم بتقديم دفعات سريعة في الشبكة مما يؤدي إلى حدوث انفجار دائم.
وستفرض ميزة التثبيط عقوبات على الطريق المشروع وستجعله غير متاح لحركة المرور الفعلية. بالإضافة إلى ذلك، سيؤدي هذا النوع من الوصلات غير المستحثة أخلاقيا إلى الضغط على موارد الموجه مثل وحدة المعالجة المركزية (CPU) والذاكرة وما إلى ذلك.
على النحو الذي تمت مناقشته في القسم السابق، كيف يمكن للمهاجم إنشاء بادئة بشكل غير قانوني والتسبب في تعطيل حركة المرور. ولكن من المؤسف أن التعطيل ليس السبب الوحيد للقلق والانزعاج. وفي مثل هذه الهجمات، يمكن أختراق البيانات الفعلية حيث يمكن للمهاجم مسح البيانات المستلمة ضوئيا لاستخدامها بشكل غير أخلاقي.
وعلى نحو مماثل، من الممكن أن يتم إختطاف أي طريق من خلال الإعلان بشكل غير قانوني عن طريق أكثر دقة. يفضل BGP البادئات التي تكون مطابقة أطول ويمكن إستخدام هذا السلوك بشكل غير صحيح كما هو موضح في الصورة.
تنبع جميع الهجمات التي تتم مناقشتها من حقيقة أن بروتوكول BGP لم يتمكن من تحديد ما إذا كان أصل هذه البادئات التي تم الإعلان عنها بشكل ضار صحيحا أم لا. لحل هذه المشكلة، يلزم وجود مصدر بيانات "صحيح" و"موثوق به" يمكن للموجه الاحتفاظ به في قاعدة البيانات الخاصة به. بعد ذلك، عند كل إيصال إعلان جديد، يصبح الموجه الآن قادرا على التحقق من معلومات البادئة AS الأصلية المستلمة من نظير BGP مع معلومات قاعدة البيانات المحلية الخاصة به من أداة التحقق من الصحة.
وبالتالي، يمكن الموجه تمييز الإعلانات الجيدة عن الإعلانات السيئة (غير القانونية) ويتم إضافة القدرة على تجنب جميع الهجمات التي تمت مناقشتها سابقا بشكل طبيعي على الموجه. يوفر BGP RPKI مصدر المعلومات الموثوق به المطلوب.
يستخدم RPKI المستودع الذي يحتوي على ROAs. تحتوي ROA على معلومات حول البادئة و BGP كرقم. تفويض أصل المسار هو عبارة موقعة مشفرة.
تعد مكاتب التسجيل الإقليمية الخمسة للإنترنت جهات الوديعة في RPKI. تعد "سلطة الأرقام المعينة عبر الإنترنت" (ANA) أعلى الشجرة التي توزع بادئات IP. ووكلاء إعادة الإعمار هم التالون في التسلسل الهرمي. فهم يقومون بتعيين البادئات الفرعية لسجلات الإنترنت المحلية (LIRs) وموفر خدمة الإنترنت الكبير (ISP). يوقعون شهادة لهذه البادئات. يخصص المستوى التالي البادئات الفرعية لتلك كما يستخدم الشهادات الواردة أعلاه لتوقيع شهاداتها الخاصة لاعتماد تخصيصات الخاصة بها. وعادة ما تستخدم هذه الشركات نقاطها المنشورة الخاصة بها لاستضافة الشهادات وتقارير ما بعد التصرف. تسرد كل شهادة نقاط النشر الخاصة بالشهادات التابعة التي توقعها. وبالتالي، يشكل RPKI شجرة الشهادات التي تعكس شجرة عمليات تخصيص عنوان IP. تقوم أجهزة التحقق من صحة RPKI المملوكة لأطراف الاعتماد باستطلاع جميع نقاط النشر للعثور على شهادات وبيانات محدثة عن حقوق الملكية (و CRLs والبيانات). يبدأون من مراكز الإئتمان ويتبعون الروابط لنقاط نشر شهادات الأطفال.
وتدخل التزامات الاستثمار الجماعي في المستودع عن طريق إتفاقات إعادة الاستثمار غير أن ذلك يمكن أن يتم عن طريق سجلات أخرى (وطنية أو محلية). ويمكن أيضا تفويض هذه المسؤولية إلى مقدمي خدمات الإنترنت مع الإشراف والتحقق الملائمين من جانب وكالات إعادة الإعمار.
وفي هذه اللحظة، توجد خمسة مستودعات لرواسب الروزا تحتفظ بها شركة Ripe NCE، و ARINE، و APNIC، و LACNIC، و Afrinic.
يقوم المدقق الموجود في الشبكة بالاتصال بهذه المستودعات وتنزيل قاعدة بيانات ROA موثوقة لإنشاء ذاكرة التخزين المؤقت الخاصة بها. هذه نسخة مدمجة من RPKI، والتي يتم استقدامها/تحديثها بشكل دوري بشكل مباشر أو غير مباشر من RPKI العالمية. وبعد ذلك يقوم برنامج التحقق من الصحة بتغذية هذه المعلومات بالموجهات لتمكينها من مقارنة إعلانات BGP الواردة بجدول RPKI من أجل إتخاذ قرار آمن.
يستخدم هذا العرض التوضيحي أداة التحقق من صحة RIPE. سيتواصل المدقق مع الموجه من خلال إنشاء جلسة عمل TCP. في هذا العرض التوضيحي، يستمع المتحقق إلى IP 192.168.122.120 و المنفذ 3323.
routinator server --rtr 192.168.122.120:3323 --refresh=900
حددت ANA المنفذ 3323 لهذا الاتصال. يحدد مؤقت التحديث الفاصل الزمني الذي ستتم بعده مزامنة المستودع المحلي وتحديثه للحفاظ على التحديث.
ملاحظة: يستخدم هذا العرض التوضيحي عشوائي عام كرقم وبادئات لمجرد توضيح ميكانيكا BGP RPKI. ويتم إستخدام بروتوكولات الإنترنت (IP) العامة بسبب RPKI في المقام الأول بهدف حماية البادئات العامة، كما أن جميع وحدات المعالجة المركزية (ROAs) التي يتم إنشاؤها على وحدات المعالجة المركزية (RIRs) هي بادئات عامة. أخيرا، لا يؤثر أي من الإجراءات والتكوينات، إلخ، الموضحة في هذا المستند على عناوين IP و AS العامة بأي طريقة.
router bgp 100
bgp router-id 10.1.1.1
rpki server 192.168.122.120
transport tcp port 3323
refresh-time 900
address-family ipv4 unicast
!
neighbor 10.0.12.2
remote-as 8100
address-family ipv4 unicast
route-policy Pass in
route-policy Pass out
!
!
neighbor 10.0.13.3
remote-as 100
address-family ipv4 unicast
!
!
// ‘Pass’ is a permit all route-policy.
يقوم الموجه بإنشاء جلسة TCP باستخدام أداة التحقق من الصحة (IP: 192.168.122.120، المنفذ 3323) لتنزيل ذاكرة ROA المؤقتة إلى ذاكرة الموجه.
RP/0/RP0/CPU0:Cisco8000#show bgp rpki server 192.168.122.120
Wed Jan 20 22:54:15.763 UTC
RPKI Cache-Server 192.168.122.120
Transport: TCP port 3323
Bind source: (not configured)
Connect state: ESTAB
Conn attempts: 1
Total byte RX: 4428792
Total byte TX: 1400
Last reset
Timest: Jan 20 05:59:58 (16:54:17 ago)
Reason: protocol error
يقوم برنامج التحقق من الصحة بتغذية معلومات ROA للموجه. يتم تحديث ذاكرة التخزين المؤقت هذه على فواصل زمنية دورية لتقليل إمكانية قيام الموجه بالاحتفاظ بمعلومات ضئيلة. في هذا العرض التوضيحي، تم تكوين وقت منعش مدته 900 ثانية. كما هو موضح هنا، قام الموجه Cisco 8000 بتنزيل عناوين IPv4 و 28350 IPv6 ROAs من أداة التحقق من الصحة.
RP/0/RP0/CPU0:Cisco8000#show bgp rpki server summary
Wed Jan 20 23:01:59.432 UTC
Hostname/Address Transport State Time ROAs (IPv4/IPv6)
192.168.122.120 TCP:3323 ESTAB 17:00:21 172632/28350
RP/0/RP0/CPU0:Cisco8000#show bgp rpki table ipv4
Wed Jan 20 23:09:26.899 UTC
>>>Snipped output<<<
Network Maxlen Origin-AS Server
10.0.0.0/24 24 13335 192.168.122.120
10.0.4.0/22 22 38803 192.168.122.120
10.0.4.0/24 24 38803 192.168.122.120
10.0.5.0/24 24 38803 192.168.122.120
10.0.6.0/24 24 38803 192.168.122.120
10.0.7.0/24 24 38803 192.168.122.120
10.1.1.0/24 24 13335 192.168.122.120
10.1.4.0/22 22 4134 192.168.122.120
10.1.16.0/20 20 4134 192.168.122.120
10.2.9.0/24 24 4134 192.168.122.120
10.2.10.0/24 24 4134 192.168.122.120
10.2.11.0/24 24 4134 192.168.122.120
10.2.12.0/22 22 4134 192.168.122.120
10.3.0.0/16 16 4134 192.168.122.120
10.6.0.0/22 24 9583 192.168.122.120
يوضح هذا القسم كيفية تشغيل BGP RPKI وكيف يمنع الموجه من الإعلانات غير الصحيحة/غير القانونية.
بشكل افتراضي، يحصل الموجه على ROAs من أداة التحقق من الصحة ولكنه لا يبدأ باستخدامها حتى يتم تكوينه للقيام بذلك. ونتيجة لذلك، يتم تمييز هذه البادئات على أنها "D" أو معطلة.
RP/0/RP0/CPU0:Cisco8000#show bgp origin-as validity
Wed Jan 20 23:27:37.268 UTC
BGP router identifier 10.1.1.1, local AS number 100
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000 RD version: 30
BGP main routing table version 30
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Origin-AS validation codes: V valid, I invalid, N not-found, D disabled
Network Next Hop Metric LocPrf Weight Path
D*> 203.0.113.0/24 10.0.12.2 0 0 8100 ?
D*> 203.0.113.1/24 10.0.12.2 0 0 8100 ?
D*> 192.168.122.1/32 10.0.12.2 0 0 8100 ?
لتمكين الموجه لفحص صحة الأصل، قم بتنشيط هذا الأمر لعائلة العناوين المعنية.
router bgp 100
address-family ipv4 unicast
bgp origin-as validation enable
!
عندما تقوم بتنشيط هذا الأمر، فإنه يتسبب في أن يقوم الموجه بمسح البادئات الموجودة في جدول BGP الخاص به مقابل معلومات ROA التي يتم استقبالها من أداة التحقق من الصحة ويتم تعيين إحدى الحالات الثلاث للبادئات .
RP/0/RP0/CPU0:Cisco8000#show bgp origin-as validity
Thu Jan 21 00:04:58.136 UTC
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Origin-AS validation codes: V valid, I invalid, N not-found, D disabled
Network Next Hop Metric LocPrf Weight Path
V*> 203.0.113.0/24 10.0.12.2 0 0 8100 ?
I* 203.0.113.1/24 10.0.12.2 0 0 8100 ?
N*> 192.168.122.1/32 10.0.12.2 0 0 8100 ?
لتمكين الموجه من إستخدام معلومات حالة التحقق من صحة البادئة أثناء إجراء أفضل حساب للمسار، يلزم هذا الأمر. لا يتم تمكين هذا بشكل افتراضي لأنه يمنحك خيار عدم إستخدام معلومات الصلاحية لحساب أفضل مسار ولكنه مع ذلك يسمح لك باستخدامها في سياسات المسار التي تتم مناقشتها لاحقا في هذا المستند.
router bgp 100
address-family ipv4 unicast
bgp bestpath origin-as use validity
!
هناك ثلاث حالات يمكن العثور على البادئة a فيها.
RP/0/RP0/CPU0:Cisco8000#show bgp origin-as validity
Thu Jan 21 00:04:58.136 UTC
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Origin-AS validation codes: V valid, I invalid, N not-found, D disabled
Network Next Hop Metric LocPrf Weight Path
V*> 203.0.113.0/24 10.0.12.2 0 0 8100 ?
I* 203.0.113.1/24 10.0.12.2 0 0 8100 ?
N*> 192.168.122.1/32 10.0.12.2 0 0 8100 ?
صالح - يشير إلى العثور على البادئة وزوج AS في جدول ذاكرة التخزين المؤقت ل RPKI.
غير موجود - يشير إلى أن البادئة ليست من بين البادئات الصالحة أو غير الصالحة.
يناقش هذا القسم كل بادئة وحالتها بالتفصيل.
قام نظير eBGP في AS 8100 بإنشاء هذا الموجه والإعلان عنه لعقدة Cisco8000. بما أن أصل AS (8100) يطابق أصل AS في ROA (تم إستلامه من أداة التحقق من الصحة)، يتم تمييز هذه البادئة بأنها صحيحة ويتم تثبيتها في جدول توجيه الموجه.
RP/0/RP0/CPU0:Cisco8000#show bgp rpki table | in "203.0.113.0|Max"
Thu Jan 21 00:21:26.026 UTC
Network Maxlen Origin-AS Server
203.0.113.0/24 24 8100 192.168.122.120
يتم تثبيت المسار في جدول BGP.
RP/0/RP0/CPU0:Cisco8000#show bgp 203.0.113.0/24
Thu Jan 21 05:30:13.858 UTC
BGP routing table entry for 203.0.113.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 31 31
Last Modified: Jan 21 00:03:33.344 for 05:26:40
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
8100
10.0.12.2 from 10.0.12.2 (192.168.122.105)
Origin incomplete, metric 0, localpref 100, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 31
Origin-AS validity: valid
ونظرا لأن هذه هي أفضل بادئة BGP وصالحة أيضا لكل RPKI، يتم تثبيتها بنجاح في جدول التوجيه.
RP/0/RP0/CPU0:Cisco8000#show route 203.0.113.0/24
Thu Jan 21 00:29:43.667 UTC
Routing entry for 203.0.113.0/24
Known via "bgp 100", distance 20, metric 0
Tag 8100, type external
Installed Jan 21 00:03:33.731 for 00:26:10
Routing Descriptor Blocks
10.0.12.2, from 10.0.12.2, BGP external
Route metric is 0
No advertising protos.
RP/0/RP0/CPU0:Cisco8000#show bgp origin-as validity invalid
Thu Jan 21 00:34:38.171 UTC
BGP router identifier 10.1.1.1, local AS number 100
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000 RD version: 33
BGP main routing table version 33
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 203.0.113.1/24 10.0.12.2 0 0 8100 ?
ومع ذلك، توضح عوائد الاستثمار (ROA) التي تم تلقيها من أداة التحقق من الصحة أن هذه البادئة تنتمي إلى AS 10021.
RP/0/RP0/CPU0:Cisco8000#show bgp rpki table 203.0.113.1/24 max 24
Thu Jan 21 00:37:05.615 UTC
RPKI ROA entry for 203.0.113.1/24-24
Origin-AS: 10021 from 192.168.122.120
Version: 124211
بما أن معلومات أصل AS في إعلان BGP المستلم (AS 8100) لم تتطابق مع أصل AS الفعلي المستلم في ROA (AS 10021)، فقد تم تمييز البادئة غير صحيحة ولم يتم تثبيتها في جدول التوجيه.
RP/0/RP0/CPU0:Cisco8000#show bgp 203.0.113.1/24
Thu Jan 21 05:37:26.714 UTC
BGP routing table entry for 203.0.113.1/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 32 32
Last Modified: Jan 21 00:03:33.344 for 05:33:53
Paths: (1 available, no best path)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
8100
10.0.12.2 from 10.0.12.2 (192.168.122.105)
Origin incomplete, metric 0, localpref 100, valid, external
Received Path ID 0, Local Path ID 0, version 0
Origin-AS validity: invalid
هذه بادئة خاصة وليست موجودة في ذاكرة التخزين المؤقت ل ROA. أعلن BGP عن هذه البادئة على أنها "غير موجودة".
RP/0/RP0/CPU0:Cisco8000#show bgp 192.168.122.1/32
Thu Jan 21 05:44:39.861 UTC
BGP routing table entry for 192.168.122.1/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 33 33
Last Modified: Jan 21 00:03:33.344 for 05:41:06
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
8100
10.0.12.2 from 10.0.12.2 (192.168.122.105)
Origin incomplete, metric 0, localpref 100, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 33
Origin-AS validity: not-found
ونظرا لأن RPKI لا يزال يتم اعتماده، يتم تثبيت البادئات "التي لم يتم العثور عليها" في جدول التوجيه. وإلا فسيتسبب ذلك في تجاهل BGP لهذه البادئات الشرعية التي لم يتم تسجيلها في قاعدة بيانات RPKI.
وعلى الرغم من أنه لا يوصى بذلك، إلا أن البرنامج يوفر مقبض للسماح للبادئات غير الصالحة بالمشاركة في خوارزمية حساب المسار الأفضل.
router bgp 100
address-family ipv4 unicast
bgp bestpath origin-as allow invalid
!
مع هذا التكوين، يعتبر الموجه بادئات غير صالحة لحساب المسار الأفضل بينما تم وضع علامة "غير صالح" عليها. يظهر هذا الإخراج "203.0.113.1/24" مميز كأفضل مسار.
RP/0/RP0/CPU0:Cisco8000#show bgp
Thu Jan 21 06:21:34.294 UTC
BGP router identifier 10.1.1.1, local AS number 100
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000 RD version: 34
BGP main routing table version 34
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 203.0.113.0/24 10.0.12.2 0 0 8100 ?
*> 203.0.113.1/24 10.0.12.2 0 0 8100 ?
*> 192.168.122.1/32 10.0.12.2 0 0 8100 ?
كما هو موضح في هذا الإخراج، يتم وضع علامة على البادئة كالأفضل بالرغم من إبقائها غير صحيحة.
RP/0/RP0/CPU0:Cisco8000#show bgp 203.0.113.1/24
Thu Jan 21 06:23:26.994 UTC
BGP routing table entry for 203.0.113.1/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 34 34
Last Modified: Jan 21 06:05:31.344 for 00:17:55
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
8100
10.0.12.2 from 10.0.12.2 (192.168.122.105)
Origin incomplete, metric 0, localpref 100, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 34
Origin-AS validity: invalid
تجدر الإشارة إلى أن الموجه ما يزال يتعامل مع البادئة غير الصالحة كخيار أخير ويفضل دائما البادئة الصالحة على البادئة غير الصالحة إذا كانت متوفرة.
إذا لم يتم بعد، لسبب ما، إنشاء عوائد الاستثمار (ROA) لبادئة معينة أو استقبالها أو تأخيرها، يمكن تكوين عوائد الاستثمار (ROA) اليدوية على الموجه. على سبيل المثال، تم وضع علامة "غير موجود" على البادئة "192.168.122.1/32" كما هو موضح هنا.
RP/0/RP0/CPU0:Cisco8000#show bgp origin-as validity
Thu Jan 21 06:36:31.041 UTC
BGP router identifier 10.1.1.1, local AS number 100
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000 RD version: 34
BGP main routing table version 34
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Origin-AS validation codes: V valid, I invalid, N not-found, D disabled
Network Next Hop Metric LocPrf Weight Path
V*> 203.0.113.0/24 10.0.12.2 0 0 8100 ?
I*> 203.0.113.1/24 10.0.12.2 0 0 8100 ?
N*> 192.168.122.1/32 10.0.12.2 0 0 8100 ?
يمكن تكوين ROA يدوي كما هو موضح هنا. يربط هذا الأمر البادئة' 192.168.122.1/32' ب AS 8100.
router bgp 100
rpki route 192.168.122.1/32 max 32 origin 8100
مع هذا التكوين، تتغير حالة البادئة من "N" إلى "V".
RP/0/RP0/CPU0:Cisco8000#show bgp origin-as validity
Thu Jan 21 06:36:34.151 UTC
BGP router identifier 10.1.1.1, local AS number 100
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000 RD version: 35
BGP main routing table version 35
BGP NSR Initial initsync version 2 (Reached)
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Origin-AS validation codes: V valid, I invalid, N not-found, D disabled
Network Next Hop Metric LocPrf Weight Path
V*> 203.0.113.0/24 10.0.12.2 0 0 8100 ?
I*> 203.0.113.1/24 10.0.12.2 0 0 8100 ?
V*> 192.168.122.1/32 10.0.12.2 0 0 8100 ?
يمكن إستخدام نتيجة حالة البادئة لإنشاء سياسات المسار. يمكن إستخدام هذه الحالات في بيان تطابق ويمكن إتخاذ الإجراءات المطلوبة من قبل المسؤول. يطابق هذا المثال جميع البادئات بحالة غير صحيحة ويعين قيمة وزن 12345 لها.
route-policy Invalid
if validation-state is invalid then
set weight 12345
endif
end-policy
!
router bgp 100
remote-as 8100
address-family ipv4 unicast
route-policy Invalid in
!
!
!
يظهر هذا الإخراج وزن تطبيق بادئة غير صالح من 12345.
RP/0/RP0/CPU0:Cisco8000#show bgp 203.0.113.1/24
Thu Jan 21 06:57:33.816 UTC
BGP routing table entry for 203.0.113.1/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 38 38
Last Modified: Jan 21 06:54:04.344 for 00:03:29
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
8100
10.0.12.2 from 10.0.12.2 (192.168.122.105)
Origin incomplete, metric 0, localpref 100, weight 12345, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 38
Origin-AS validity: invalid
بما أن موجه BGP يستطيع أيضا مشاركة حالة التحقق من صحة البادئة مع الموجهات الأخرى (مع عدم وجود ذاكرة تخزين مؤقت محلية من المدقق) عبر مجتمع BGP الموسع. يؤدي ذلك إلى حفظ النفقات العامة لكل موجه وكل موجه في الشبكة باستخدام جلسة عمل مع أداة التحقق من الصحة وتنزيل جميع عناوين ROA.
وهذا ممكن بواسطة مجتمع BGP الموسع.
يتيح هذا الأمر للموجه مشاركة معلومات "التحقق من صحة البادئة" مع نظائر iBGP.
router bgp 100
address-family ipv4 unicast
bgp origin-as validation signal ibgp
بمجرد تكوين موجه Cisco 8000 كما هو موضح، تتضمن تحديثات BGP إلى الأقران معلومات التحقق من صحة البادئة. في هذه الحالة، يكون موجه iBGP المجاور هو موجه IOS-XE.
csr2#show ip bgp 203.0.113.1/24
BGP routing table entry for 203.0.113.1/24, version 14
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
8100
10.0.12.2 from 10.0.13.1 (10.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: 0x4300:0:2
rx pathid: 0, tx pathid: 0x0
Updated on Jan 21 2021 18:16:56 UTC
يمكن فهم تخطيط المجتمع الموسع هذا باستخدام 0x4300 0x000 (4 بايت تشير إلى الحالة).
يتم التعامل مع وحدات البايت الأربع التي تشير إلى الحالة كعدد صحيح غير موقع 32 بت يحتوي على إحدى القيم:
مجتمع البادئة 203.0.113.1/24 هو 0x4300:0:2 الذي يترجم إلى البادئة "غير الصالحة". بهذه الطريقة، لا يزال الموجه CSR2 قادرا على إتخاذ القرارات استنادا إلى حالة التحقق من صحة البادئة، وذلك على الرغم من عدم وجود ذاكرة تخزين مؤقت محلية خاصة به.
يمكن إستخدام حالة التحقق من صحة البادئة الآن للمطابقة في خريطة المسار أو في خوارزمية أفضل مسار BGP.
هذه بعض التوصيات قائمة على الشبكات التي يتعذر الوصول إليها والتي تمت ملاحظتها في RPKI-Observatory. ويحلل مرصد RPKI جوانب متعددة من بيئة RPKI المنشورة.
إذا تم إنشاء ROA لأي بادئة، فيوصى بالإعلان عن هذه البادئة في BGP. وفي غياب هذه الميزة، يمكن لشخص آخر الإعلان عنها من خلال التظاهر ببساطة بأنه ASN موجود في عوائد الاستثمار هذه واستخدام البادئة.
إذا تم إنشاء ROA باستخدام قيمة أساسية أكبر من طول البادئة، فهذا يعادل إنشاء عناوين ROA لجميع البادئات المحتملة تحت البادئة الأصلية حتى الحد الأقصى. ويوصى بشدة بإعلان جميع هذه البادئات في BGP.
إذا تم إنشاء ROA لبادئة وأعلن مالك البادئة عن بادئة فرعية للبادئة الأصلية، فسيقوم ROA بإبطال هذه البادئة الفرعية. يجب توسيع ROA للبادئة الفرعية أيضا أو الحد الأقصى ل ROA الأصلية لتغطية البادئة الفرعية.
إذا كانت مؤسسة تمتلك بادئة، ولكنها تخطط لعدم الإعلان عنها في BGP، فيجب إنشاء قيمة ROA للبادئة AS0. سيؤدي هذا إلى إبطال أي إعلان عن البادئة لأنه لا يمكن أن يظهر AS0 في أي مسار AS.
إذا كانت هناك عدة ASN تقوم بإنشاء نفس البادئة، فيجب إنشاء ROAs لتلك البادئة لكل ASN. وبالتالي، إذا كان الموجه يحتوي على العديد من عناوين ROA للبادئة نفسها، فسيكون إعلان BGP الذي يطابق أي منها صحيحا. لا تتعارض عوائد الاستثمار المتعددة للبادئة نفسها مع بعضها البعض.
إذا كان 'A' منشئا لبادئة لعميله 'B' ومكونا ROA لتلك البادئة نيابة عن 'B'، فيجب أن يكون 'A' مسبقا 'B' حتى الإعلان أو أن يكون 'B' قد أنشأ البادئة نفسها.
عندما يتم تحديث عناوين ROA وإذا كان الموجه يحتوي على سياسة مسار دخول محلية لجيران يحتوي على "حالة التحقق من الصحة"، يصبح من المهم إعادة التحقق من حالة البادئات استنادا إلى عناوين ROA المحدثة الجديدة. ويتحقق ذلك من خلال قيام الموجه بإرسال طلب تحديث BGP إلى النظير الخاص به.
عندما تستلم جيران BGP هذه الرسالة كما هو موضح، يرسل الجيران البادئات مرة أخرى ويمكن لسياسة المسار الواردة إعادة التحقق من صحة البادئات الواردة .
Jan 22 18:28:41.360: BGP: 10.0.12.1 rcv message type 5, length (excl. header) 4
Jan 22 18:28:41.360: BGP: 10.0.12.1 rcvd REFRESH_REQ for afi/safi: 1/1, refresh code is 0
تزداد المشكلة عندما يتم تحديث العديد من الجيران في نفس الوقت عند تحديث وحدات الأولوية (ROA). إذا كانت سياسة المسار الوارد المجاورة معقدة وتتطلب الكثير من المعالجة، فعندئذ تكون النتائج عالية لوحدة المعالجة المركزية لبضع دقائق بعد تحديث ROA. لا تحدث رسائل التحديث هذه إذا لم يحتوي نهج المسار الوارد المجاور على الأمر "validation-state is".
إذا تم تكوين "إعادة التكوين التلقائي الوارد دائما" لأحد الجيران، فلن يتم إرسال رسائل تحديث BGP، ولكن سيتم تنفيذ نفس سياسات المسار بنفس المعدل ويمكن توقع إستخدام وحدة المعالجة المركزية نفسه.
يوصى بتفضيل نهج 'BGP BESTPATH origin-as use validity' على تكوين سياسة المسار للأسباب الموضحة في 6.2.2 أدناه.
أفضل طريقة لتجنب المشكلة الموضحة هنا هي إستخدام أصل أفضل مسار لأن صلاحية الاستخدام بدون حالة التحقق من الصحة موجودة في السياسة.
router bgp 100
address-family ipv4 unicast
bgp bestpath origin-as use validity
!
يحافظ هذا الأمر على مسار غير صالح تم إستلامه على الموجه ولكنه يمنعه من أن يصبح أفضل مسار. لن يتم تثبيته أو الإعلان عنه أكثر من ذلك. إنه جيد كإسقاطها. إذا أصبح التحديث التالي ل ROA صالحا، فلن يكون هناك حاجة إلى التحديث، وسيصبح تلقائيا مؤهلا للمسار الأفضل دون الحاجة إلى تنفيذ النهج.
إذا كان المستخدم يفضل السماح بالبادئات "غير الصالحة" وعدم إستخدامها، فبالإضافة إلى أصل مسار أفضل كإستخدام لصلاحية، أستخدم أفضل مسار للتكوين كالسماح بعدم الصلاحية.
في هذه الحالة، عند تغيير أحد إجراءات الوصول عن بعد (ROA)، يتم تحديث المسار الأفضل تلقائيا دون الحاجة إلى رسالة تحديث. من أجل إلغاء التفضيل، يعني المسار أنه خلال تحديد مسار BGP، يعتبر مسار RPKI غير الصالح أقل تفضيلا من أي مسار آخر إلى الوجهة نفسها. ويكون مماثلا لوضع وزنه أو تفضيله المحلي اقل من 0.
وعدد المتعثرين في مرفق إعادة البناء وإعادة البناء صغير نسبيا ولا يؤدي إلى تأثير كبير على الموارد.
ملاحظة: من أجل إستخدام "أصلي أفضل مسار كصحة إستخدام"، يجب أن يكون لجميع مسارات المسار، بما في ذلك مسارات IBGP، صلاحية RPKI الصحيحة. وإذا لم يكن الأمر كذلك، فلا يزال من الممكن إستخدام إختبار حالة التحقق من الصحة في سياسة المسار.
لم يتم التحقق من صحة مسارات IBGP بواسطة الموجه مقابل قاعدة بيانات ROA. تكسب طرق IBGP صلاحية RPKI من مجتمع RPKI الممتد. إذا تم تلقي مسار IBGP دون هذا المجتمع الموسع، فسيتم تعيين حالة التحقق من الصحة الخاصة به على عدم العثور عليها.
وتستهلك كل عملية من عمليات عائد الاستثمار (ROA) الذاكرة اللازمة للفهرس والبيانات. إذا كان هناك نوعان من عائد الاستثمار (ROA) لنفس بادئة IP، ولكنهما يملكان max_len مختلف أو يتم استقبالهما من خوادم RPKI مختلفة، فيتشاركان نفس الفهرس ولكن لديهما بيانات منفصلة. قد تختلف متطلبات الذاكرة لأن مصروفات الذاكرة ليست ثابتة. ويوصى بميزانية زائدة تبلغ 10٪. تتطلب الأنظمة الأساسية 64 بت ذاكرة أكثر لكل كائن ذاكرة من الأنظمة الأساسية 32 بت. إستخدام ذاكرة IOS-XR بالبايت لكائن فهرس وكائن بيانات موجود في الجدول. وبعض النفقات العامة الثابتة في معظمها مدرجة في الأرقام.
النظام الأساسي 32 بت (بايت) |
نظام أساسي 64 بت (بايت) |
|
فهرس IPv4 |
74 |
111 |
فهرس IPv6 |
86 | 125 |
البيانات |
34 | 53 |
يحتاج هذا القسم إلى سيناريوهين لشرح كيفية إستهلاك ROAs للذاكرة.
خذ بعين الاعتبار الموجه الذي يستخدم 3 خوادم RPKI، حيث يوفر كل منها 2000000 IPv4 ROAs و 20000 IPv6 ROAs على معالج توجيه من فئة 64 بت سيتطلب هذه الذاكرة:
2000 * (125 + 3*53) + 20000 * (111 + 3*53) بايت = 59.68 مليون بايت
أثناء حساب الذاكرة، تمت مشاركة ROA لنفس البادئة من ثلاثة مدققات مختلفة في نفس قيمة الفهرس.
ذاكرة عملية BGP بدون ROAs:
RP/0/RP0/CPU0:Cisco8000#show processes memory detail location 0/RP0/CPU0 | in $
Fri Jan 22 17:19:57.945 UTC
JID Text Data Stack Dynamic Dyn-Limit Shm-Tot Phy-Tot Process
1069 2M 71M 132K 25M 7447M 50M 74M bgp
RP/0/RP0/CPU0:Cisco8000#show bgp rpki server summary
Fri Jan 22 17:12:09.073 UTC
Hostname/Address Transport State Time ROAs (IPv4/IPv6)
192.168.122.120 TCP:3323 NONE 00:00:25 N/A
تعتبر عملية BGP تستهلك ذاكرة سعة 25 ميجابايت دون أي عمليات ROAs.
ذاكرة عملية BGP مع ROA:
RP/0/RP0/CPU0:Cisco8000#show bgp rpki server summary
Fri Jan 22 17:23:46.769 UTC
Hostname/Address Transport State Time ROAs (IPv4/IPv6)
192.168.122.120 TCP:3323 ESTAB 00:02:42 172796/28411
RP/0/RP0/CPU0:Cisco8000#show processes memory detail location 0/RP0/CPU0 | in $
Fri Jan 22 17:24:14.659 UTC
JID Text Data Stack Dynamic Dyn-Limit Shm-Tot Phy-Tot Process
1069 2M 99M 132K 53M 7447M 50M 102M bgp
تعتبر عملية BGP تستهلك ذاكرة سعة 25 ميجابايت دون أي عمليات ROAs.
ذاكرة عملية BGP مع ROA:
RP/0/RP0/CPU0:Cisco8000#show bgp rpki server summary
Fri Jan 22 17:23:46.769 UTC
Hostname/Address Transport State Time ROAs (IPv4/IPv6)
192.168.122.120 TCP:3323 ESTAB 00:02:42 172796/28411
RP/0/RP0/CPU0:Cisco8000#show processes memory detail location 0/RP0/CPU0 | in $
Fri Jan 22 17:24:14.659 UTC
JID Text Data Stack Dynamic Dyn-Limit Shm-Tot Phy-Tot Process
1069 2M 99M 132K 53M 7447M 50M 102M bgp
يعمل الموجه Cisco 8000 بنظام التشغيل 64 بت. وقد حصل على 172796 IPv4 ROA و 28411 ROA.
الذاكرة (بالبايت) = 172796 × [111 (الفهرس) + 53 (البيانات)] + 28411 × [125 (الفهرس) + 53 (البيانات)].
هذه الحسابات تعطي حوالي 27 ميغابايت وهو تقريبا الزيادة التي تلاحظ على ذاكرة الموجه أعلاه.
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
2.0 |
18-Oct-2022 |
تمت إزالة جميع مشاكل واهتمامات PII. |
1.0 |
07-Apr-2021 |
الإصدار الأولي |