Siyasətlər, communities və best path

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

BGP Communities marşrut siyasətlərini avtomatlaşdırmaq üçün prefikslərə qoşulan rəqəmsal teqlərdir (atributlar). Üç növü var: Standard Communities (32 bit, format AA:NN, RFC 1997), Extended Communities (64 bit, L3VPN-də Route Target üçün, RFC 4360) və Large Communities (96 bit, 4-baytlıq AS üçün, RFC 8092). Operator şəbəkəsində bu teqlər Local Preference-i idarə etmək (çıxış trafikini yönləndirmək), AS_PATH Prepending etmək, anons sahəsini məhdudlaşdırmaq (NO_EXPORT) və DDoS zamanı Blackhole (65535:666) aktivləşdirmək üçün istifadə olunur. Sərhəddə müştəri komyunitiləri mütləq təmizlənməlidir ki, daxili şəbəkə idarəetməsinə kənar müdaxilə olmasın.

Üç community formatı

Community könüllü tranzit atributdur, yol seçiminə özü təsir etmir, siyasətlər üçün etiket rolunu oynayır. Üç format mövcuddur:

4 baytlıq AS standard community-nin 16 bitlik sahəsinə sığmır, buna görə 4 baytlıq ASN üçün Large istifadə olunur. Extended community tip, alt tip və qiymətdən ibarətdir: Route Target target:65000:100 kimi 2 baytlıq AS və 4 baytlıq nömrə formatında ötürülür, 4 baytlıq ASN-li şəbəkədə isə başqa kodlaşdırma tipi tətbiq olunur. Extended və large community ayrıca atributlar kimi ötürülür və set community extcommunity-yə toxunmur.

Well-known community-lər

Qiymətlər IANA tərəfindən ayrılıb və qonşularda konfiqurasiya olmadan işləyir:

• NO_EXPORT (65535:65281, 0xFFFFFF01): marşrut AS-dən kənara eBGP qonşularına göndərilmir (confederation-da confederation-dan kənara).
• NO_ADVERTISE (65535:65282): marşrut heç bir BGP qonşusuna göndərilmir.
• NO_EXPORT_SUBCONFED / LOCAL_AS (65535:65283): marşrut sub-AS-dən kənara çıxmır.
• BLACKHOLE (65535:666, RFC 7999): prefiksə gedən trafikin atılması sorğusu (RTBH).
• GRACEFUL_SHUTDOWN (65535:0, RFC 8326): qonşu xidmətdən əvvəl trafikin başqa yola keçirilməsini xahiş edir.

İnformasiya və idarəedici etiketlər

Operator sxemi iki sinif etiketdən qurur:

• İnformasiya (qəbul zamanı nişanlama): region, qonşu tipi, giriş nöqtəsi, məsələn A müştərisi üçün 65000:100. Onlar export siyasətlərində istifadə olunur: müştəri marşrutları hamıya, provayder marşrutları yalnız müştərilərə gedir.
• İdarəedici (action): müştəri etiketlə davranışı özü sorğulayır, məsələn 65000:80 LOCAL_PREF 80 təyin edir (ehtiyat giriş), 65000:666 blackhole-u qoşur, 65000:1001 upstream 1 üçün prepend xahiş edir.

Etiketlər təsvir olunmalı və müştərilərə dərc edilməlidir; sənədsiz hər sxem idarəolunmaz rəqəmlər toplusuna çevrilir.

Giriş siyasəti: etibar yox, filtrasiya

Müştəri community-lərini yoxlamadan daxilə buraxmaq olmaz. Qaydalar: (1) yalnız müştərinin öz prefikslərini qəbul etmək (prefix-list), (2) yad community-ləri silmək və ya əvəz etmək (Cisco/Huawei-də additive olmadan set community 65000:100 siyahını üzərinə yazır; Junos-da community set eyni davranır), (3) action etiketlərini yalnız prefiks və etiket uyğun gələndə emal etmək. (2) səhvi Junos-da xüsusilə təhlükəlidir: Junos-da community və Route Target eyni siyahıda saxlanılır və vrf-export siyasətində community set CUST RT-ni siləcək, bundan sonra VPN marşrutu heç bir VRF-ə idxal olunmayacaq.

Community-lərin şəbəkə üzrə ötürülməsi

Susmaya görə Cisco qonşulara community göndərmir: send-community (standard), send-community extended və ya both lazımdır. Huawei-də bu peer ... advertise-community-dir (extended üçün advertise-ext-community), Junos-da community-lər susmaya görə göndərilir, RouterOS-da BGP bağlantılarında susmaya görə göndərilir, lakin filtrlər onları dəyişə bilər. RR-də və ya PE-də göndərmə qoşulmayıbsa, etiket ən yaxın düyündə yoxa çıxır və uzaq PE-lərdə siyasətlər işləməyi dayandırır, halbuki PE1-də hər şey düzgün görünür.

RTBH: blackhole community addım-addım

1. DDoS altında olan A müştərisi qurbanın /32 prefiksini, 203.0.113.77/32-ni, 65000:666 etiketi ilə elan edir.
2. PE1 prefix-list ilə /32-nin müştəri blokunun (203.0.113.0/24 le 32) daxilində olduğunu yoxlayır, əks halda istənilən müştəri başqasının şəbəkəsini söndürə bilərdi.
3. Siyasət next hop-u 192.0.2.1 edir (TEST-NET-1-dən ünvan, Null0/discard-a statik marşrutla), yüksək LOCAL_PREF və NO_EXPORT təyin edir.
4. Marşrut iBGP ilə yayılır və onu alan hər edge-PE next hop-u discard marşrutuna həll edir: qurbana gedən trafik müştəriyə çatmır, şəbəkəyə girişdə atılır.

/32-nin qəbuluna məhz bu etiket üçün icazə vermək lazımdır: adi filtr prefiks uzunluğunu /24 ilə məhdudlaşdırır.

Ən yaxşı yolun seçilməsi alqoritmi

Cisco IOS-XE və oxşar platformalar atributları bu ardıcıllıqla müqayisə edir:

1. Weight (yalnız Cisco; Huawei-də analoqu preferred-value) - böyük daha yaxşıdır.
2. LOCAL_PREF - böyük daha yaxşıdır (susmaya görə 100; Junos preference 170 başqa şeydir).
3. Lokal yaradılmış marşrut (network, redistribute, aggregate).
4. Ən qısa AS_PATH.
5. Ən kiçik Origin (IGP < EGP < incomplete).
6. Ən kiçik MED, yalnız eyni qonşu AS-dən gələn yollar arasında müqayisə olunur (always-compare-med yoxdursa).
7. eBGP iBGP-dən yaxşıdır.
8. Next hop-a qədər ən kiçik IGP metrikası.
9. Ən köhnə eBGP yolu, sonra ən kiçik router-id (ORIGINATOR_ID), ən qısa CLUSTER_LIST, ən kiçik qonşu ünvanı.

Community-lər LOCAL_PREF, AS_PATH (prepend) və ya MED-i dəyişən siyasətlər vasitəsilə seçimə təsir edir; özləri müqayisə olunmur.

Tipik səhvlər

Unudulmuş send-community; yekun term-i olmayan siyasət (qeyri-aşkar deny bütün digər marşrutları atır); additive əvəzinə community-lərin üzərinə yazılması; prefiksin sahibini yoxlamadan blackhole-un qəbulu; LOCAL_PREF bir PE-də təyin olunub, digərində RR siyasəti ilə pozulur; müxtəlif AS-lər arasında MED müqayisəsi; AS sərhədini anlamadan VPN daxilində no-export-un yayılması.

Memarlıq sxemi və topologiya

+-------------+      BGP Community: 65000:100 (Local-Pref 200)      +-------------+
|    PE-1     | ==================================================> |    PE-2     |
| (Community  |                                                     | (Match &    |
| Attachment) | <================================================== | Action)     |
+-------------+      BGP Community: 65000:666 (Blackhole Next-Hop)  +-------------+