كشف تحليل نشرته مدونة ipSpace.net أن جدول SR Linux BGP RIB يتضمن تلقائياً جميع مسارات النظام بدلاً من إبقائها منفصلة حتى إعادة توزيعها. ورغم أن الكاتب لم يتمكن من الجزم بما إذا كان نظام SR Linux يستخدم قاعدة معلومات توجيه BGP (أي BGP RIB) مباشرةً كجدول توجيه للنظام (RIB)، فإن الاختبارات على ipSpace.net أظهرت أن بادئات OSPF والمضيف تظهر في جدول BGP دون أي عبارات لإعادة التوزيع.
معالجة المسارات في أنظمة الشبكات التقليدية مقابل FRRouting
بحسب توضيح مدونة ipSpace.net، تتعامل أنظمة تشغيل الشبكات التقليدية مع جدول BGP RIB وجدول توجيه النظام (RIB) وجدول التوجيه النهائي (FIB) عبر ست خطوات متسلسلة:
- تخزين المسارات المستلمة من جيران BGP داخل جدول BGP RIB.
- إعادة إنشاء المسارات المعاد توزيعها إلى BGP من بروتوكولات أخرى داخل جدول BGP RIB.
- اختيار أفضل المسارات في BGP RIB باستخدام مجموعة قواعد BGP المعقدة.
- الإعلان عن أفضل المسارات من جدول BGP RIB إلى جيران BGP.
- منافسة أفضل مسارات BGP RIB (بناءً على المسافة الإدارية) ضد المسارات الواردة من بروتوكولات التوجيه الأخرى للدخول إلى جدول توجيه IP (أي RIB الخاص بالنظام).
- نسخ المسارات من جدول RIB الخاص بالنظام إلى جدول FIB بعد تقييم القفزات التالية (Next Hops) بالكامل، وهي عملية قد تتطلب عمليات بحث متكررة متعددة.
عدّلت حزمة FRRouting هذه العملية قليلاً؛ إذ تستخدم جدول RIB الخاص بالنظام كمستودع لجميع المسارات، لتصبح الخطوات النهائية كالتالي:
- نسخ أفضل المسارات من جدول BGP RIB إلى جدول RIB الخاص بالنظام.
- اختيار أفضل المسارات من جدول RIB الخاص بالنظام بواسطة مدير جدول التوجيه (zebra) بناءً على مسافتها الإدارية.
- نسخ أفضل مسارات RIB إلى جدول FIB (بعد حسم القفزة التالية).
اختبار نظام SR Linux في بيئة netlab
أثناء محاولة إصلاح بعض قوالب إعدادات أداة netlab الخاصة بنظام SR Linux، لاحظ كاتب ipSpace.net سلوك جداول التوجيه عبر شبكة اختبار بسيطة تضم موجّه SR Linux (المسمى SRL) وموجّهين مجاورين: الموجه R1 (يعمل ببروتوكول OSPF) والموجه X2 (يعمل ببروتوكول EBGP).
┌────────┐ ┌─────────┐ ┌────────┐
│ R1 │ │ SRL │ │ X2 │
│10.0.0.1├────┤10.0.0.42├────┤10.0.0.2│
└────────┘ └─────────┘ └────────┘
◄─────────────► ◄────────────►
OSPF EBGPاستخدم الكاتب ملف بنية netlab التالي لإنشاء المختبر، معتمداً على روابط IPv4 غير مرقمة في السطر 3 لإبقاء جدول التوجيه نظيفاً قدر الإمكان، مع تعطيل الإعلان عن عنوان Loopback في السطر 11 بحيث لا يستقبل الموجه X2 أي مسارات BGP من SRL:
defaults.device: frr
provider: clab
addressing.p2p.ipv4: True
nodes:
srl:
module: [ ospf, bgp ]
bgp.as: 65000
device: srlinux
id: 42
bgp.advertise_loopback: false
r1:
module: [ ospf ]
x2:
module: [ bgp ]
bgp.as: 65001
links: [ srl-r1, srl-x2 ]يُظهر فحص جدول توجيه IPv4 على نظام SR Linux وجود البادئات الثلاث المتوقعة موزعة بين أنواع مسارات ospfv2 و bgp و host:
A:srl# show route-table ipv4-unicast summary | as text
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
IPv4 unicast route table of network instance default
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
+--------------------+------+-----------+---------------------+---------+---------+--------+-----------+------------+------------+------------+---------------+
| Prefix | ID | Route | Route Owner | Active | Origin | Metric | Pref | Next-hop | Next-hop | Backup | Backup Next- |
| | | Type | | | Network | | | (Type) | Interface | Next-hop | hop Interface |
| | | | | | Instanc | | | | | (Type) | |
| | | | | | e | | | | | | |
+====================+======+===========+=====================+=========+=========+========+===========+============+============+============+===============+
| 10.0.0.1/32 | 0 | ospfv2 | ospf_mgr | True | default | 16 | 10 | 169.254.0. | ethernet- | | |
| | | | | | | | | 1 (direct) | 1/1.0 | | |
| 10.0.0.2/32 | 0 | bgp | bgp_mgr | True | default | 0 | 170 | fe80::a8c1 | ethernet- | | |
| | | | | | | | | :abff:fe4e | 1/2.0 | | |
| | | | | | | | | :f30b | | | |
| | | | | | | | | (direct) | | | |
| 10.0.0.42/32 | 4 | host | net_inst_mgr | True | default | 0 | 0 | None | None | | |
| | | | | | | | | (extract) | | | |
+--------------------+------+-----------+---------------------+---------+---------+--------+-----------+------------+------------+------------+---------------+
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
IPv4 routes total : 3
IPv4 prefixes with active routes : 3
IPv4 prefixes with active ECMP routes: 0مع ذلك، يكشف فحص جدول مسارات BGP على نظام SR Linux أن جميع هذه البادئات الثلاث تظهر أيضاً داخل جدول BGP:
A:srl# show protocols bgp routes ipv4 summary
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Show report for the BGP route table of network-instance "default"
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Status codes: u=used, *=valid, >=best, x=stale
Origin codes: i=IGP, e=EGP, ?=incomplete
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
+------+------------------+--------------------------+------+------+---------------------------------------------------+
| Stat | Network | Next Hop | MED | LocP | Path Val |
| us | | | | ref | |
+======+==================+==========================+======+======+===================================================+
| u*> | 10.0.0.1/32 | 169.254.0.1 | 16 | | i |
| u*> | 10.0.0.2/32 | fe80::a8c1:abff:fecf:209 | - | | [65001] i |
| | | a%ethernet-1/2.0 | | | |
| u*> | 10.0.0.42/32 | 0.0.0.0 | - | | i |
+------+------------------+--------------------------+------+------+---------------------------------------------------+
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
3 received BGP routes: 3 used, 3 valid, 0 stale
3 available destinations: 0 with ECMP multipathsللتحقق من سبب ذلك، استعرض الكاتب إعدادات BGP على نظام SR Linux التي أنشأتها أداة netlab بعد إزالة جميع عبارات سياسة التصدير (export-policy). وكما يظهر في الإعدادات، لا توجد أي عبارة شبكة (network) أو إعادة توزيع للمسارات:
A:srl# info protocols bgp
protocols {
bgp {
admin-state enable
autonomous-system 65000
router-id 10.0.0.42
dynamic-neighbors {
interface ethernet-1/2.0 {
peer-group intf-ethernet-1/2
allowed-peer-as [
65001..65001
]
}
}
ebgp-default-policy {
import-reject-all false
export-reject-all false
}
afi-safi ipv4-unicast {
admin-state enable
}
group intf-ethernet-1/2 {
admin-state enable
afi-safi ipv4-unicast {
admin-state enable
ipv4-unicast {
advertise-ipv6-next-hops true
receive-ipv6-next-hops true
}
}
afi-safi ipv6-unicast {
admin-state disable
}
send-community {
standard true
large true
}
timers {
connect-retry 10 !!! Reduce default 120s to 10s
minimum-advertisement-interval 1
}
}
}
}فحص مسارات OSPF وسياسات التصدير الافتراضية
يُظهر الفحص التفصيلي لبادئة OSPF رقم 10.0.0.1/32 داخل جدول BGP RIB كيف يتعامل نظام SR Linux مع هذا المسار المستورد:
A:srl# show protocols bgp routes ipv4 prefix 10.0.0.1/32
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.0.0.1/32" network-instance "default"
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Network: 10.0.0.1/32
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 0.0.0.0
Route Preference: MED is 16, No LocalPref
BGP next-hop : 169.254.0.1
Path : i
Communities : None
Path 1 was advertised to:
[ ]بحسب مدونة ipSpace.net، تبرز ثلاث نقاط مهمة في هذه المخرجات: مصدر المسار هو الموجه المحلي نفسه (الجار 0.0.0.0، ما يعني أنه أُعيد توزيعه إلى BGP)، وقيمة MED ضُبطت على تكلفة OSPF البالغة 16، ولم يُعلن عن المسار لأي طرف آخر، وهو ما يفسر عدم استلام الموجه X2 لأي مسارات BGP من SRL.
ينفذ نظام SR Linux ذلك عبر استخدام سياسة تصدير (export-policy) افتراضية في BGP تطابق فقط المسارات المتعلمة عبر بروتوكول BGP. ونتيجةً لذلك، لا يُعلن عن المسارات المستوردة إلى جدول BGP RIB من مصادر أخرى إلى جيران BGP بشكل افتراضي.
سياسات إنشاء البادئات وإعادة توزيع المسارات
يشير كاتب ipSpace.net إلى أن هذا النهج يجعل إنشاء بادئات BGP وإعادة توزيع المسارات مختلفاً عما هو معتاد في الأنظمة الأخرى. فبدلاً من استخدام عبارة الشبكة (network)، يجب مطابقة البادئات في سياسة التصدير الصادرة (export-policy)، وبدلاً من إعداد إعادة توزيع المسارات، يجب مطابقة البروتوكول (protocol) في سياسة التصدير الصادرة.
لإنشاء بادئة محلية داخل BGP (وهو ما يعادل عبارة network)، يستعرض الكاتب سياسة التوجيه التالية:
A:srl# info routing-policy
routing-policy {
prefix-set default_bgp_advertise {
prefix 10.0.0.42/32 mask-length-range exact {
}
}
policy default_bgp_export {
default-action {
policy-result reject
}
statement prefixes {
match {
prefix-set default_bgp_advertise
}
action {
policy-result accept
}
}
statement bgp {
match {
protocol bgp
}
action {
policy-result accept
}
}
}وبالمثل، لإعادة توزيع الشبكات الفرعية المتصلة ومسارات OSPF إلى داخل BGP، يجب أيضاً مطابقة مسارات BGP صراحةً داخل السياسة، وإلا فلن يستلمها الجيران:
A:srl# info routing-policy
policy default_bgp_export {
default-action {
policy-result reject
}
statement bgp {
match {
protocol bgp
}
action {
policy-result accept
}
}
statement export_local {
match {
protocol local
}
action {
policy-result accept
}
}
statement export_ospfv2 {
match {
protocol ospfv2
}
action {
policy-result accept
}
}
statement export_ospfv3 {
match {
protocol ospfv3
}
action {
policy-result accept
}
}
}تسرب المسارات غير المقصود والإصدار SR Linux 24.7.1
يرى الكاتب أن نهج SR Linux يؤدي الغرض المطلوب منه، لكنه قد يخالف «مبدأ أقل قدر من المفاجأة» (Principle of Least Astonishment). فعلى سبيل المثال، إذا أراد مدير الشبكة ضبط قيمة MED على 42 لمسارات BGP التي يعلن عنها SRL إلى X2، فقد يكتب سياسة توجيه بسيطة كالتالي:
A:srl# info routing-policy policy set-med
routing-policy {
policy set-med {
statement med-is-42 {
action {
policy-result accept
bgp {
med {
set 42
}
}
}
}
}
}يؤدي تطبيق سياسة التوجيه هذه على جار BGP إلى ظهور النتائج التالية في جدول BGP على الموجه X2:
$ netlab connect x2 --show ip bgp
Connecting to container clab-X-x2, executing vtysh -c "show ip bgp"
BGP table version is 3, local router ID is 10.0.0.2, vrf id 0
Default local pref 100, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.0.0.1/32 eth1 42 0 65000 i
*> 10.0.0.2/32 0.0.0.0(x2) 0 32768 i
*> 10.0.0.42/32 eth1 42 0 65000 iنظراً لأن سياسة التصدير المُعدّة قبلت جميع المسارات الموجودة في جدول BGP RIB دون تصفية حسب البروتوكول، فقد ضبطت قيمة MED على 42 لكل مسار وأعلنت عنها جميعاً إلى جار EBGP المسمى X2، بما في ذلك مسارات OSPF والمسارات المحلية.
يتمثل الحل السريع في هذه الحالة بإضافة عبارة match protocol bgp إلى سياسة التوجيه. ولكن عند الرغبة في الجمع بين إنشاء البادئات وإعادة توزيع المسارات والسياسات الخاصة بكل جار، كان المستخدمون يواجهون تعقيدات كبيرة في دمج السياسات حتى جاء الإصدار SR Linux 24.7.1 الذي قدّم سلسلة من سياسات تصدير BGP، وهي ميزة يخطط الكاتب لتناولها في تدوينة لاحقة بعد طرح الإصدار netlab 1.9.1.
كُتب هذا المقال بالذكاء الاصطناعي اعتماداً على ما نشره: blog.ipspace.net.
