Nəzəri əsaslar və memarlıq
Nüvədə ani IP FRR olsa belə, BGP konvergensiyası xidmətin ən yavaş hissəsi olaraq qalır: egress PE-nin və ya onun CE ilə xəttinin nasazlığı yüz minlərlə VPN prefiksini etibarsız edir və optimallaşdırma olmadan hər biri ayrıca yenidən proqramlaşdırılır, buna görə itki müddəti prefiks sayı ilə artır və saniyələrə, onlarla saniyəyə çatır. Prefix Independent Convergence (PIC) bu asılılığı aradan qaldırır: FIB iyerarxikdir, minlərlə prefiks ümumi BGP next-hop obyektinə, o isə IGP yoluna işarə edir, buna görə yolun dəyişməsi prefiks sayından asılı olmayaraq bir göstəricini yeniləyir. PIC Core nüvədəki nasazlığa reaksiya verir, PIC Edge əvvəlcədən quraşdırılmış ehtiyat BGP yoluna keçir. Ehtiyat yolun ümumiyyətlə mövcud olması üçün RR onu göndərməlidir: unikal RD-lər, BGP Add-Path (RFC 7911), best-external və multipath istifadə edin. Dərs iyerarxik FIB-i, əlavə yolları, VPNv4-də ECMP-ni və MRAI, next-hop tracking və scan interval taymerlərini izah edir. Əvvəlki modullardan iBGP, RR və L3VPN biliyi nəzərdə tutulur.
BGP niyə yavaş konvergensiya edir
Klassik sxemdə hər VPN prefiksinin FIB-də öz next hop-u var, egress PE nasazlığı isə yüz minlərlə qeyd üçün eyni next hop deməkdir. Marşrutlaşdırıcı hər prefiks üçün withdraw və ya next hop itkisini emal etməli, best yolu yenidən seçməli və FIB-i yenidən proqramlaşdırmalıdır. Qeyd 10-50 mikrosaniyədə yenilənirsə, 500 min prefiks bir neçə saniyədən onlarla saniyəyə qədər itki, proqram platformalarda isə daha çox verir. Vaxt prefiks sayı ilə xətti artır və PIC məhz bu asılılığı aradan qaldırır.
İyerarxik FIB və PIC Core
PIC ilə FIB iki səviyyəli olur (praktikada chain və ya indirect next hop): prefiks ümumi BGP next-hop obyektinə (PE2 ünvanı), bu obyekt isə PE2-yə IGP yoluna (transport etiketi, interfeys) işarə edir. Nüvə daxilində yol qırılarsa, yalnız aşağı obyekt dəyişir, məsələn 10.255.0.2-yə ECMP dəsti: on minlərlə prefiksə toxunulmur. Bu qoruma PIC Core adlanır: keçid müddəti prefiks sayından asılı deyil və IGP/IP FRR sürəti ilə müəyyən olunur. O, əlavə BGP yolları tələb etmir və adətən müasir platformalarda defolt aktivdir, lakin platformadan və proqram versiyasından asılıdır.
PIC Edge və ehtiyat yol
PIC Edge egress PE-nin və ya onun CE ilə xəttinin nasazlığına cavab verir. Bunun üçün FIB-də quraşdırılmış ehtiyat yol lazımdır: BGP next-hop obyekti əsas və ehtiyat next hop-u (PE2 və PE3) saxlayır, PE2 itdikdə bütün prefikslər göstərici ilə PE3-ə keçir. Ehtiyat yol BGP cədvəlində mövcud olmalı, onun next hop-u əlçatan olmalı və əsas yolla eyni taleyi bölüşməməlidir (ideal halda başqa PE). Trigger IGP-də next hop /32-nin yox olmasıdır: buna görə PE loopback-ləri sahə sərhədlərində summarize edilməməlidir, əks halda PE1 nasazlığı görməz və BGP hold taymerini gözləyər (Cisco-da defolt 180 s, Junos-da 90 s); növbəti dərs bunu BGP-LU və summarize olunmayan /32-lərlə həll edir.
İkinci yol haradan gəlir
RR hər prefiks üçün bir best yol seçir və başqa qaydada qurulmayıbsa yalnız onu əks etdirir, buna görə klient ehtiyat yolu görmür. Variantlar. Birinci: hər VRF və PE üçün unikal RD (65000:2 və 65000:3): NLRI fərqlənir, hər iki marşrut müxtəlif VPNv4 kimi əks olunur, RT import isə onları VRF-ə yerləşdirir. Bu ən sadə və ən geniş dəstəklənən üsuldur, lakin RR-də VPNv4 cədvəlini böyüdür (hər prefiks PE sayına vurulur). İkinci: BGP Add-Path (RFC 7911): capability 69 AFI/SAFI üzrə send/receive razılaşdırır, NLRI-yə 4 baytlıq Path Identifier əlavə olunur və hər yol ayrıca açar olur (prefiks + path ID); implicit withdraw prefiks üzrə yox, cüt üzrə işləyir. RR N ən yaxşı və ya bütün yolları (məsələn best 2) və ya diverse yolu (RFC 6774) seçir ki, ikinci yol eyni nasaz qovşaqdan keçməsin. Üçüncü: best-external - best yolu daxili olan (RR-dən) PE yenə də xarici yolu (CE-dən) elan edir. Add-Path RR-də və klientlərdə dəstək tələb edir, yaddaşı və yeniləmə yükünü artırır, buna görə yolların sayını şüurlu seçin.
VPNv4-də multipath və ECMP
Local preference, AS path uzunluğu, origin, MED və next hop-a IGP metrikası bərabər olduqda iBGP multipath (maximum-paths ibgp, multipath) VRF-də bir neçə yol quraşdırır və trafiki onlar arasında bölür (axın üzrə balanslaşdırma, paket üzrə yox). Müxtəlif RD olduqda yollar VRF-ə müstəqil import olunmuş marşrutlar kimi düşür və multipath VRF səviyyəsində işləyir. PE2 və PE3 üçün IGP metrikaları adətən bərabər olmur, buna görə ECMP bərabər metrika və ya unequal-cost dəstəyi tələb edir (Junos: vpn-unequal-cost, Huawei: load-balancing və başqaları). Multipath və PIC bir-birini tamamlayır: ECMP olduqda bir yolun nasazlığı yalnız onun axın payını götürür.
BGP taymerləri
MRAI (Minimum Route Advertisement Interval) bir qonşuya elanların tezliyini məhdudlaşdırır: eBGP üçün defolt 30 s, Cisco-da iBGP üçün adətən 0 (digər platformalarda dəyərlər fərqlidir). Böyük MRAI fon konvergensiyasını yavaşladır, lakin PIC keçidinə təsir etmir. Next-hop tracking (NHT) BGP-nin RIB dəyişikliklərinə hadisə əsaslı reaksiyasıdır: bgp nexthop trigger delay defolt 5 s-dir (Cisco), sürətli konvergensiya üçün PE-lərdə 0-a (və ya 1-2 s) endirilir. Scan interval (bgp scan-time, klassik implementasiyalarda 60 s) next hop əlçatanlığını dövri yoxlayır; bu gün bu işi NHT görür, buna görə skanerə güvənmək olmaz. BGP hold taymeri (məsələn Cisco-da 180 s) yalnız son müdafiə xəttidir. BFD (xətlərdə single-hop) və IGP nüvəyə, BGP isə next hop əlçatanlığına nəzarət edir. Nəzərə alın ki, kiçik taymerlərlə sürətləndirmə flap zamanı CPU yükünü artırır: dampening və ya flap qorumasından istifadə edin.
