MP-BGP address families: RR laboratoriyası

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

Laboratoriya işi: VPN xidmətləri üçün Multiprotocol BGP (MP-BGP, RFC 4760) və Route Reflector klasterinin qurulması. Standart BGP-4 yalnız IPv4 Unicast dəstəkləyir. Müxtəlif xidmətləri (L3VPN, EVPN) ötürmək üçün MP-BGP Address Family konsepsiyasını gətirir: AFI (Address Family Identifier) və SAFI (Subsequent AFI). L3VPN üçün AFI=1 / SAFI=128 (VPNv4), EVPN üçün isə AFI=25 / SAFI=70 tətbiq edilir. Laboratoriyada PE və Route Reflector-lar arasında standart IPv4 ayrılır və xüsusi vpnv4 və l2vpn evpn ailələri aktivləşdirilir. RR klasteri VPNv4 NLRI marşrutlarını (RD, prefiks və etiket; Route Target isə extended community atributu kimi) öz FIB cədvəlinə yazmadan sırf Control Plane səviyyəsində əks etdirir.

MP-BGP nə əlavə edir (RFC 4760)

Klassik BGP-4 UPDATE mesajının NLRI sahəsində yalnız IPv4 unicast daşıyır. Multiprotocol Extensions iki atribut təqdim edir: MP_REACH_NLRI (tip 14: AFI, SAFI, next hop və NLRI siyahısı) və MP_UNREACH_NLRI (tip 15: marşrutların geri çağırılması). Dəstək OPEN-də capability kod 1 kimi bildirilir: qonşular AFI/SAFI cütlərini mübadilə edir və yalnız ümumi olanlardan istifadə edir. Eksploatasiya üçün nəticələr: ünvan ailəsi hər iki tərəfdə qoşulmalıdır (Cisco-da activate, Huawei-də enable, Junos qrupunda family), canlı sessiyaya ailə əlavə etmək isə adətən onu yenidən başladır, çünki capability dəsti yalnız yeni OPEN-də dəyişir. Belə dəyişiklikləri iş pəncərəsində planlaşdırın.

Operator şəbəkəsində rast gəlinən ünvan ailələri

VPNv4 NLRI-nin daxilində nə var

VPN-IPv4 prefiksi 12 bayt tutur: 8 bayt Route Distinguisher və 4 bayt IPv4. NLRI əlavə olaraq 3 baytlıq etiket sahəsini (20 bit etiket, 3 bit EXP, S biti) və bitlərlə uzunluğu ehtiva edir, uzunluq 24 + 64 + IPv4 prefiksinin uzunluğuna bərabərdir. VPNv4 üçün MP_REACH-də next hop 12 baytdır (RD 0:0 və PE-nin IPv4 ünvanı), VPNv6 üçün 24 bayt. RT extended community kimi ötürülür, buna görə Cisco-da vpnv4 və vpnv6 üçün send-community extended məcburidir; onsuz marşrut RT olmadan gəlir və heç bir VRF-ə idxal olunmur. VPN etiketini PE marşrutu VRF-dən ixrac edərkən təyin edir (per-prefix, per-VRF və ya per-next-hop); next hop 10.255.0.1-ə nəqliyyat etiketini sonradan LDP əlavə edir.

VPN ailələri üçün RR

VPNv4 üçün Route Reflector VRF tələb etmir: bütün client-lərin marşrutlarını olduğu kimi saxlayır. Burada laboratoriya işlərinin ən çox "qalxır, lakin boşdur" halına düşməsinə səbəb olan tələ var:

• Cisco IOS-XE: susmaya görə bgp default route-target filter qoşulub və VRF-i olmayan RR RT-si heç bir lokal import RT-yə uyğun gəlməyən VPNv4 marşrutlarını atır. RR-də no bgp default route-target filter verilir.
• Huawei VRP: RR-də vpnv4 rejimində yoxlama undo policy vpn-target əmri ilə söndürülür.
• Junos: RR (cluster olan qrup) RT-dən asılı olmayaraq bgp.l3vpn.0-dakı bütün marşrutları saxlayır; cluster-i və VRF-i olmayan marşrutlaşdırıcıda uyğun RT-si olmayan marşrutlar atılır.

Böyük şəbəkələrdə RT-constraint (SAFI 132) istifadə olunur: PE-lər hansı RT-lərin lazım olduğunu elan edir, RR isə yalnız uyğun marşrutları göndərir, bu da yeniləmələrin həcmini kəskin azaldır.

Rezervləşdirmə: iki RR və ayrı müstəvilər

PE-lər eyni Cluster-ID-li iki RR-ə qoşulur (RR1 10.255.0.100 və RR2 10.255.0.101), hər PE-nin hər ikisi ilə sessiyası olur. Hər PE-nin hər VRF-ində unikal RD sayəsində eyni müştəri prefiksinin iki qoşulma nöqtəsindən gələn marşrutları fərqli NLRI-yə malikdir, buna görə RR hər ikisini saxlayır və əks etdirir, PE-də isə add-path olmadan multipath olur. RD bütün PE-lərdə eynidirsə, RR birini seçir və ikincini gizlədir. Müstəviləri ayırmaq tövsiyə olunur: IPv4 unicast, VPN və EVPN ayrı RR-lərdə, ki, bir müstəvinin nasazlığı və ya həddindən artıq yüklənməsi digərlərinə təsir etməsin.

Qaldırma zamanı yoxlama ardıcıllığı

Laboratoriyada yoxlama ardıcıllığı: PE-lər və RR-lər arasında IGP və LDP (loopback /32 və etiketlər), loopback-lər arasında TCP/179, capability mübadiləsi (çıxışda lazım olan ailələr "advertised and received" olur), VRF yaradılması və RT idxalı, VPN etiketinin verilməsi, RR tərəfindən əksetdirmə (PE2-dəki marşrutda Originator və Cluster list görünür), nəhayət, iki etiketli paketin yönləndirilməsi. Tipik nasazlıqlar: AF yalnız bir tərəfdə qoşulub, send-community extended yoxdur, RR-də RT filtri qalıb, RR1 və RR2 fərqli Cluster-ID ilə və aralarında sessiya olmadan, next hop-a LSP-nin olmaması.

Davamlılığın yoxlanması

RR1 söndürüləndən sonra işləyən ping heç nəyi sübut etmir: köhnə marşrutlar sessiya hold timer ilə düşənə qədər PE cədvəlində qalır. Düzgün yoxlama: RR1-i söndürmək, PE1-də yeni prefiks yaratmaq (məsələn, VRF A-da ikinci interfeys) və onun PE2-də RR2 vasitəsilə göründüyünə əmin olmaq. Yalnız bu idarəetmə müstəvisinin rezervləşdirildiyini sübut edir.

Memarlıq sxemi və topologiya

                +--------------------------------+
                |   Route Reflector cluster      |
                |  RR-1: 10.255.0.101            |
                |  RR-2: 10.255.0.102            |
                |  (RR-1 <-> RR-2 peering, both  |
                |   reflect to the PE clients)   |
                +--------------------------------+
                  /                         \
VPNv4 iBGP (PE = RR client)     VPNv4 iBGP (PE = RR client)
                v                             v
        +---------------+             +---------------+
        |     PE-1      |             |     PE-2      |
        | VRF: Cust-A   |             | VRF: Cust-A   |
        +---------------+             +---------------+

Trafik axını və etiket steki sxemi

MP-BGP Address Families & NLRI Signaling:
1. PE-1 encodes IPv4 into 96-bit VPNv4 prefix: [RD: 65000:1] + [Prefix: 192.168.10.0/24]
2. Appends Path Attributes: Next-Hop (10.255.0.1), Extended Community RT (65000:100), Service Label (24001).
3. Transmits to RR via AFI 1 (IPv4) / SAFI 128 (VPNv4).
4. RR reflects update to PE-2 without altering Next-Hop or Service Label.

Vəziyyətlər və parametrlər cədvəli

Memarlıq modeli və iş prinsipləri

Real operator şəbəkələrində MPLS müxtəlif istehsalçıların avadanlıqlarını birləşdirir. Aşağıda dörd platforma üçün praktiki konfiqurasiya və Data Plane / Control Plane yoxlama nümunələri təqdim olunur: Cisco IOS-XE/XR, Huawei VRP, Juniper Junos və MikroTik RouterOS v7. Sintaksis fərqlərinə və etiket paylama mexanizmlərinə diqqət yetirin.

Praktiki konfiqurasiya (Cisco, Huawei, Juniper, MikroTik)

Cisco (IOS-XE/XR)