Route Reflector və confederation

Nəzəri əsaslar və memarlıq

iBGP Full Mesh problemini həll etmək üçün Route Reflector (RR, RFC 4456) və ya Konfederasiyalar tətbiq edilir. Route Reflector Split Horizon qaydasını yumşaldır: RR kimi konfiqurasiya edilmiş qovşaq bir iBGP müştərisindən (client) aldığı marşrutu digər müştərilərə ötürmək (əks etdirmək) hüququna malikdir. PE-lər yalnız iki ehtiyat RR ilə sessiya qurur və sessiya sayı 2*N-ə enir. Dövrələrdən qorunmaq üçün iki atribut istifadə olunur: ORIGINATOR_ID (marşrutu ilk yayan PE-nin ID-si) və CLUSTER_LIST (marşrutun keçdiyi Cluster-ID siyahısı). Əgər RR CLUSTER_LIST daxilində öz Cluster-ID-sini görərsə, marşrut dövrə səbəbindən dərhal bloklanır.

Əksetdirmə qaydaları (RFC 4456)

Route Reflector iBGP split horizon qaydasını yumşaldır. Client RR-in reflector kimi konfiqurasiya olunduğu iBGP qonşusudur; RR-in digər bütün iBGP qonşuları non-client sayılır. Client öz rolu haqqında heç nə bilmir: route-reflector-client (Cisco), reflect-client (Huawei) və ya qrupda cluster (Junos) yalnız RR-də verilir. Ən yaxşı yolun yayılması qaydaları:

RR yalnız öz cədvəlindən seçdiyi ən yaxşı yolu (best path) əks etdirir. Nəticədə client-lər bütün yolları yox, məhz RR-in seçdiyini görür və RR əks olunan marşrutların next hop-unu dəyişmir (client-lər üçün RR-də next-hop-self adətən lazım deyil və susmaya görə əks olunan marşrutlara tətbiq olunmur).

ORIGINATOR_ID və CLUSTER_LIST

İki könüllü qeyri-tranzit atribut əksetdirmə döngülərindən qoruyur:

• ORIGINATOR_ID (tip 9, 4 bayt): AS daxilində marşrutu iBGP-yə ilk daxil etmiş marşrutlaşdırıcının router-id-si. Onu əks etdirərkən ilk RR təyin edir. PE öz ORIGINATOR_ID-si olan marşrut alarsa, onu atır.
• CLUSTER_LIST (tip 10): 4 baytlıq Cluster-ID ardıcıllığı. Hər RR əks etdirərkən siyahının əvvəlinə öz Cluster-ID-sini əlavə edir; siyahıda öz Cluster-ID-sini görən RR marşrutu atır.

Hər iki atribut yalnız AS daxilində məna daşıyır və eBGP-yə göndərilmir. Yol seçimində (router-id-dən sonra) router-id əvəzinə ORIGINATOR_ID müqayisə olunur, sonra ən qısa CLUSTER_LIST, yalnız bundan sonra qonşu ünvanı. Cluster-ID susmaya görə RR-in router-id-sinə bərabərdir; Cisco-da bgp cluster-id 100 və Junos-da cluster 0.0.0.100 onluq və nöqtəli formada eyni 100 ədədidir.

Cluster-ID: RR cütündə ümumi və ya fərqli

Ehtiyat RR2 iki üsuldan biri ilə qurulur:

• RR1 və RR2-də eyni Cluster-ID (hər ikisi bir klasterə xidmət edir): RR1-in əks etdirdiyi marşrutu RR2 alanda atır, çünki öz Cluster-ID-sini görür. Bu yaddaşa qənaət edir (client-lərdə və RR-lərdə yollar azdır), lakin hər client hər iki RR ilə sessiyaya malik olmalıdır. Client yalnız RR1-ə qoşulubsa və RR1 düşərsə, client təcrid olunur.
• Fərqli Cluster-ID (RR1 və RR2 yuxarı səviyyə mesh daxilində bir-birinin client-i və ya non-client-i): hər client hər iki RR-dən yol alır, bir RR-in nasazlığında konvergensiya daha sürətli və müstəqildir. Qiyməti: iki dəfə çox yol və RR-lərdə və PE-lərdə çox yaddaş.

İki RR və N client olduqda sessiyalar: 2*N üstəgəl RR-lər arasındakı sessiya, full mesh-də isə N*(N-1)/2 (100 PE: 201-ə qarşı 4950).

Dizayn: RR-i hara qoymalı

RR idarəetmə müstəvisində işləyir və trafikin yolunda dayanmalı deyil (out-of-path): ona görə onu yönləndirmə yükü olmayan xüsusi virtual və ya ayrıca marşrutlaşdırıcı etmək olar. Client-lərin next hop-larının həll olunması üçün RR ilə PE-lər arasında IGP və LDP əlçatanlığı kifayətdir. Böyük şəbəkələrdə iyerarxiya qurulur: regional RR-lər mərkəzi RR-lərin client-idir. RR-in məhdudiyyətləri: o, topologiyanı öz IGP-sinin nöqteyi-nəzərindən görür, ona görə ən yaxşı yolu client-dən yox, RR-dən next hop-a qədər metrikaya görə seçir (hot potato problemi), bu da qeyri-optimal çıxışlara səbəb ola bilər. Həllər: hər zonada RR yerləşdirmək, Optimal Route Reflection (RFC 9107), bir neçə yolu ötürmək üçün BGP add-path (RFC 7911) və PE-lərdə best-external. VPN (VPNv4) üçün RR əlavə olaraq VRF-ləri idxal etmir və RT-constrained distribution qoşulmayıbsa, bütün marşrutları RT filtrasiyası olmadan saxlayır.

Confederation (RFC 5065)

RR-in alternativi: AS sub-AS-lərə bölünür (özəl nömrələr 65001, 65002), hər sub-AS daxilində full mesh və ya RR lazımdır, sub-AS-lər arasında isə "demək olar ki, eBGP" işləyir. Xarici aləm tək confederation identifier 65000 görür. Nələr dəyişir:

• AS_PATH-də AS_CONFED_SEQUENCE (tip 3) və AS_CONFED_SET (tip 4) seqmentləri yaranır. Onlar AS_PATH uzunluğu müqayisəsində nəzərə alınmır (Cisco-da bgp bestpath as-path confed hesablamanı qoşur) və confederation-dan çıxanda silinir.
• Sub-AS-lər arasında NEXT_HOP, LOCAL_PREF və MED iBGP-də olduğu kimi saxlanılır, buna görə siyasət bütün AS üçün vahid qalır.
• Döngülər AS_CONFED_SEQUENCE ilə tutulur: öz sub-AS-i yolda artıq varsa, marşrut atılır.
• Sub-AS-lər arasında sessiya TTL 1 ilə eBGP-dir: loopback-lərdə peering üçün ebgp-multihop 2 lazımdır (Huawei ebgp-max-hop, Junos multihop ttl).

bgp confederation peers-də və ya identifier-də səhv sessiyanı confederation-ın daxili hissəsi kimi yox, başqa AS ilə eBGP kimi göstərir.

RR və confederation müqayisəsi

İki mexanizmi birləşdirmək olar: sub-AS daxilində RR qoymaq (dərsin konfiqurasiyasında olduğu kimi).

Tipik nasazlıqlar

Ümumi Cluster-ID olan iki RR-dən yalnız birinə qoşulmuş client; RR və onun client-i müxtəlif klasterlərdə; ümumi klasterdə RR-lər arasında sessiyanın qırılması (client-lər müxtəlif yol dəstləri görür); RR-in ən yaxşı yolu öz IGP metrikasına görə seçməsi; RR-də send-community-nin olmaması (community və RT itir, VPN-də bu marşrutların itkisidir); sub-AS-lər arasında MED-ə diqqətsizlik; next hop başqa IGP zonasında olduqda sub-AS sərhədində next-hop-self olmadığı üçün next hop-un itməsi. Yoxlama meyarı: PE-də əks olunmuş marşrutlarda Originator və Cluster list görünür, hər prefiksin hər iki RR vasitəsilə (ümumi klasterdə isə client-in qoşulduğu RR vasitəsilə) yolları var.

Memarlıq sxemi və topologiya