المسار الذي لا يصف شيئاً ويستطيع أن يتولى كل ما تبقى: BGP وسلطة الملاذ الأخير

الخلاصة

• لا يثبت 0.0.0.0/0 أو ::/0 أي bit من destination، لكنه يطابق كل عنوان لم يفز له prefix أطول. لذلك يتغير نطاقه الفعلي كلما ظهرت more-specific routes أو اختفت.
• إنشاء default وتصديره واستقباله وقبوله واختياره وكتابته في FIB وتسليم packet حالات منفصلة. Session في وضع Established تثبت control channel إلى neighbor، لا الخدمة الواقعة خلفه.
• لا تُمنح سلطة الملاذ الأخير إلا لعلاقة محددة، وبـpredicate قريب من الوعد، وحق رفض محلي لدى المستقبل، وcanaries تستخدم default فعلاً، وتجربة تقيس withdrawal وfailover وrollback.

تستقبل AS 64580 من provider يحمل الرقم AS 64520 عدداً محدوداً من المسارات الإقليمية وIPv4 default، ولا تحمل full table. عند 09:41 يفقد AS 64520 وسيلة النقل إلى upstream الرئيسي. يبقى رابط customer قائماً، وتظل EBGP session Established، وتبقى بعض more-specifics الإقليمية عبر مسار آخر.

كان default-originate غير مشروط. لذلك يستمر AS 64520 في إرسال 0.0.0.0/0، ويستمر AS 64580 في اختياره، ويبقى next hop نفسه في hardware FIB. تنجح probes إلى loopback لدى provider وresolver إقليمي وخدمتين تغطيهما routes أدق. أما destinations التي تعتمد فعلاً على /0 فتدخل AS 64520 ثم تتوقف أمام egress المفقود.

هذا incident افتراضي، لكن آليته لا تحتاج UPDATE خاطئاً. BGP يحافظ على جلسة بين speakerين، ولا ينشئ جلسة مع كل destination يدعي neighbor القدرة على بلوغه. وجود الإعلان حقيقة control-plane محدودة؛ لا يثبت بقاء شرط data-plane الذي أعطاه المعنى.

لا يحمل prefix صفراً من التفاصيل، لكنه يحكم البقية

تفرض RFC 1812 أن يبدأ forwarding باختيار أطول prefix يطابق العنوان. لذلك يفوز /24 على /0 داخل نطاقه. ولا يصبح default مرشحاً إلا عندما لا توجد إجابة أكثر تحديداً.

بما أن طول prefix يساوي صفراً، فإن 0.0.0.0/0 يطابق كل IPv4 و::/0 يطابق كل IPv6. لكن مجموعة packets التي تستخدمه ليست ثابتة. عندما يظهر 198.51.100.0/24 تخرج تلك العناوين من default. وعندما يُسحب /24 تعود إليه فوراً من دون أن يتغير default نفسه.

هذه هي حدود السلطة الحقيقية. يرسل advertiser object صغيراً جداً، بينما تحدد بقية table لدى receiver حجم التفويض الفعلي. قد يتسع نطاق /0 بعد withdrawal لمسارات أخرى رغم ثبات hash وAS_PATH وNEXT_HOP ومدة الإعلان.

تميز RFC 4098 بين default route وdefault-free routing table وfull default-free table. الاكتفاء بـdefault يقلل state وكلفة policy، لكنه يترك قرارات المجموعة المتبقية لدى provider. أما full table فتعطي customer معلومات واختيارات أكثر مقابل memory وCPU وتشغيل أكبر. وdefault مع selected specifics عقد ثالث، لا نسخة مصغرة من العقدين الآخرين.

يجب أيضاً فصل IPv4 عن IPv6. الإذن بـ0.0.0.0/0 لا يعني الإذن بـ::/0. لكل AFI/SAFI وVRF وnext hop وfilter وprobe حالة مستقلة.

الإعلان بين نظامين مستقلين فعل صريح

تصف RFC 4632 0.0.0.0/0 بأنه degenerate default prefix وتطلب من implementations قبوله. لكنها تمنع تحوله إلى تفويض تلقائي: لا ينبغي إرساله إلى routing domain آخر إلا عند explicit configuration، لا بصفة option تظهر من دون قرار.

تضيف RFC 7454 نطاق العلاقة. خارج ترتيبات customer/provider المحددة، لا يُقصد عادة قبول أو إعلان default في IPv4 أو IPv6، ويوصى بالفلترة. وفي المقابل تعترف بتصميم مشروع يطلب فيه customer default فقط بدلاً من full table.

إذن /0 صالح ومفيد، لكنه bilateral. موافقة customer واحد لا تسمح بإرساله إلى peer أو upstream أو route server أو tenant آخر. ولا ينبغي أن توسع peer-group inheritance قراراً محلياً من دون مراجعة.

يضبط provider export إلى neighbors المصرح لهم. ويقبل customer exact /0 فقط من role مخول وفي family وrouting instance المقصودين. لا يتكرر control عبثاً؛ بل يحتفظ كل autonomous network بقدرته على إيقاف خطأ الطرف الآخر.

تمنع RFC 8212 غياب import/export policy من التحول إلى سماح ضمني في EBGP. غير أن وجود policy لا يثبت صحتها. يمكن كتابة route-map صريحة تشمل neighbor خاطئاً أو health condition لا تمثل service. Explicit syntax ليس دليلاً على correct intent.

عبارة “default موجود” تخفي سبع حالات

ينشئ advertiser أولاً candidate: قد يكون synthetic لكل neighbor، أو static، أو generated، أو BGP route. ثم تقرر outbound policy التصدير. يستقبل الطرف الآخر UPDATE، ويطبق import policy، ويقارن البدائل، ويختار route في RIB، ويبرمج next hop في FIB. وبعد ذلك فقط يحاول packet العبور.

يمكن أن يوجد candidate ويمنعه filter. يصل UPDATE ويُرفض. يقبل route ويخسر أمام default أعلى LOCAL_PREF. تتغير RIB ويتأخر hardware. تشير FIB بدقة إلى link حي، لكن neighbor لا يملك مساراً تالياً.

AS_PATH يصف انتقال إعلان /0، لا paths الفعلية لكل destination داخل المجموعة المتبقية. NEXT_HOP يثبت قرار الخطوة المحلية فقط. Preference تعبر عن اختيار receiver، وليست قياساً مباشراً لصحة provider.

تتيح RFC 4271 سحب /0 داخل session نفسها. إذا فشل وعد الملاذ الأخير فلا حاجة إلى clear لكل neighbor وإزالة routes أخرى. Session reset يوسع blast radius ويمحو evidence مفيدة.

اسم feature واحد لا يعني state machine واحدة

تقدم وثائق Cisco IOS الحالية neighbor ... default-originate كأمر per-neighbor ولا تشترط وجود 0.0.0.0 محلياً. وفي Nexus يمكن إرسال artificial default من دون وجوده في routing table أو إنشاء object له في local BGP RIB. ويمكن لـroute-map اختيار route منصبة كشرط.

تذكر FRRouting أنها لا تعلن 0.0.0.0/0 افتراضياً حتى لو كان في routing table. يجب تفعيل neighbor ... default-originate صراحة، مع route-map اختيارية.

أما Junos فتستخدم active routes وrouting policy. يمكن تصدير static وaggregate وgenerated routes إلى BGP حين تسمح policy. وتربط أمثلة الشرط بين active state وقرار export.

يغير هذا الاختلاف نتيجة failure. حذف static /0 قد لا يلمس synthetic default غير مشروط. وفي تصميم آخر يكون سقوط generated route هو trigger السحب. لا يجوز نسخ runbook بين vendors لمجرد تشابه الكلمات.

يُختبر السلوك على release الجاري: local RIB وBGP RIB وadvertised-routes وreceiver view. يُزال support الحقيقي مع إبقاء customer session، ثم تقاس reevaluation وwithdrawal والاختيار البديل وFIB والpacket. ويعاد الاختبار عند recovery.

الشرط شاهد محدود، لا الخدمة نفسها

لا يصبح conditional advertisement آمناً إلا إذا كان predicate قريباً من المعنى الذي يمثله /0.

وصول provider loopback يثبت loopback واحداً. Interface up يثبت local carrier. بقاء static route قد يثبت configuration أو recursion فقط. Table count يثبت quantity لا egress forwarding. BFD يثبت continuity مع peer بعينه. لا يغطي أي منها وحده كل residual destinations.

يبدأ التصميم بتعريف الوعد. إذا كان default يعني public transit واسعاً، تعبر canaries egress نفسه الذي يستخدمه customer traffic، وتتوزع على networks مستقلة وdependencies متعددة. وإذا كان يعني private WAN exit، يبقى الاختبار داخل ذلك النطاق. لا يوسع اسم تجاري غامض معنى metric ضيقة.

وتحتاج الإشارات المتعددة إلى قرار. اشتراط نجاح الجميع قد يسحب آخر path مفيد بسبب فشل target واحد. الاكتفاء بواحد قد يبقي blackhole كبيراً لأن جزيرة صغيرة ما زالت تعمل. Quorum وhysteresis وhold-down وrecovery threshold توزع كلفة السحب المبكر والمتأخر.

يجب حفظ state history: كل input، والقرار المجمع، ووقت predicate failure، وwithdrawal، وتغير best path، وكتابة FIB، وتعافي packet. Snapshot سليم بعد الحادث لا يعيد بناء التسلسل.

more-specifics تخفي النجاح والفشل في اتجاهين

نجحت probes في المثال لأنها استخدمت more-specific routes الباقية. لم تختبر default المعطوب. إذا تركز monitoring على services محلية أو prefixes شائعة، فقد تظهر جزيرة صغيرة كأنها صحة عامة.

والعكس صحيح. لا ينقذ default سليم destination يغطيه /24 مكسور، لأن longest match يختار الأكثر تحديداً أولاً. Stale specific أو next hop خاطئ أو leak قد يعطل service واحداً بينما تعمل بقية الشبكة عبر /0.

يجب أن تحفظ كل canary winning prefix وRIB entry وFIB next hop وegress. نجاح application من دون attribution لا يثبت أي policy. وعندما يظهر specific أو يختفي تتغير فئة probe حتى لو ظل default كما هو.

ولا تثبت defaultان independence. قد تشترك sessions على routers مختلفين في metro fibre أو upstream أعلى أو controller أو health target. اختبار إغلاق session يثبت session failover، لا حالة upstream loss مع بقاء customer peer حياً.

تسريب /0 ينقل كل ما لا يعرفه المستقبل

قبول default من relationship خاطئة يسلم neighbor كل destination لا توجد له route أدق محلياً. قد تكون المجموعة صغيرة في core يحمل full table، وقد تكون تقريباً كل external traffic لدى stub customer.

يسمح export filter فقط للعملاء المحددين ويمنع peers وproviders وroute servers وtenants الآخرين. ويقبل import filter exact zero-length prefix فقط من neighbor الصحيح وفي AFI/SAFI وVRF الصحيحين. ويُراجع peer-group inheritance وdual-stack automation من خلال readback.

تظهر configuration النية. يبين Adj-RIB-Out ما أرسله speaker فعلاً. وتفصل pre-policy وaccepted view لدى receiver بين الوصول والقبول. قد يكشف public collector هروباً أبعد، لكنه لا يرى كل edge. غياب route لديه لا يثبت غياب leak في كل مكان.

يبدأ evidence ledger بالوعد وينتهي بالpacket

لكل default relationship يُكتب معنى service أولاً: public Internet transit، أو external services محددة، أو private WAN exit، أو fallback مؤقت. ويُسجل advertiser وreceiver وrole وfamily وVRF وapproval owner وwithdrawal owner.

ثم تسجل generation mode وpredicate وinputs وquorum وtimers وhysteresis وfailure action. وفي runtime تحفظ candidate وpost-policy advertisement وpre-policy receipt وaccepted route وselection reason وrecursion وhardware FIB والبدائل مع timestamps.

تنطلق canaries من receiver لأن الثقة تتحول هناك إلى forwarding. تعتمد بعض targets على /0 فقط، وتغطي more-specifics targets أخرى عمداً لإثبات الحد. وتتوزع targets على dependencies فعلية مستقلة مع حفظ egress.

يبقي failure drill customer session ويزيل upstream الذي يسند الوعد. يقيس condition failure وwithdrawal وalternate RIB وFIB وpacket recovery منفصلة. ومن دون بديل، يثبت أن receiver يتوقف عن إرسال packets إلى path ميت.

يشمل rollback generation وcondition وtimers وneighbor scope وattributes وimport preference وmonitoring. ولا ينتهي حتى تعود observed state وpackets إلى العقد السابق.

التنسيق الرقيق يحتاج حق خروج محلياً قوياً

يمكن أن يكون default مثالاً ممتازاً على minimum coordination. لا يشارك provider خريطة كاملة، ويختار customer fallback محلياً. لا توجد حاجة إلى authority مركزية تقرر كل destination.

لكن قلة المعلومات تمنع تفسيراً واسعاً. لقب provider ليس data-plane certificate. UPDATE ليس SLA. قبول الأمس لا يلغي حق الرفض أو خفض preference غداً.

ترتب Running-Code Primacy الأدلة: contract يصف التوقع، configuration تصف النية، UPDATE يثبت الإرسال، RIB/FIB تثبت local action، وpacket يثبت النتيجة الجارية. كل طبقة ضرورية ولا تمثل الطبقة التالية.