IST-01 lokasyonunda hizmet kesintisi yaşanıyor. Detaylar

Rehber eBGP · max-prefix

BGP oturumu kurarken dikkat edilmesi gereken 7 nokta

Prefix filtrelerinden max-prefix'e, TCP-AO'dan graceful shutdown'a kadar yeni bir eBGP oturumunu canlıya almadan önce gözden geçirilmesi gereken yedi başlık ve örnek bir BIRD yapılandırması.

Netlojik NOC Ekibi 4 dk okuma

İçindekiler
  1. 1. Prefix filtreleri: iki yönde de açıkça tanımlayın
  2. 2. max-prefix: sızıntıya karşı sigorta
  3. 3. Oturum kimlik doğrulama: MD5 ve TCP-AO
  4. 4. BGP community: politikayı etiketle yönetin
  5. 5. RPKI: geçersiz rotaları düşürün
  6. 6. Graceful shutdown: bakımda trafiği önceden taşıyın
  7. 7. İzleme: oturumu kurduktan sonra işiniz bitmedi
  8. Örnek: BIRD 2 ile bir eBGP oturumu
  9. Toparlarken

Bir eBGP oturumunu "Established" durumuna getirmek birkaç satırlık iştir. Oturumun yıllarca sorunsuz çalışması, komşunuzun hatasının sizin ağınızı ya da sizin hatanızın interneti etkilememesi ise kurulum sırasında verilen kararlara bağlıdır. Aşağıdaki yedi nokta, yeni bir upstream, peer ya da müşteri oturumu açarken kullandığımız kontrol listesinin özetidir.

1. Prefix filtreleri: iki yönde de açıkça tanımlayın

Varsayılan kural şu olmalı: filtresi olmayan oturum hiçbir şey almaz ve hiçbir şey göndermez. Güncel BIRD ve FRR sürümleri de bu davranışa yakındır, ama buna güvenmek yerine filtreyi açıkça yazın.

Dışa duyuruda sadece kendi prefix'lerinize ve varsa müşteri prefix'lerinize izin verin. İçe alırken ise şunları reddedin:

  • Bogon ve martian adresler (RFC 1918, 0.0.0.0/8, 127.0.0.0/8, 224.0.0.0/3 vb.)
  • IPv4'te /24'ten, IPv6'da /48'den daha spesifik prefix'ler
  • Kendi adres alanınız
  • AS_PATH'inde bogon ASN bulunan rotalar

Müşteri ve peer oturumlarında izin listesini elle değil, IRR verisinden üretin. bgpq4 bu iş için standarttır:

bgpq4 -4 -A -b -l CUSTOMER_V4 AS64500
bgpq4 -6 -A -b -l CUSTOMER_V6 AS64500

AS-SET kullanan bir müşteri için AS64500 yerine AS-SET adını verirsiniz; Netlojik'in kendi AS-SET'i örneğin AS202294:AS-NETLOJIK'tir. Bu listeleri günlük bir cron ile yenilemek, müşteri yeni prefix eklediğinde elle müdahale ihtiyacını ortadan kaldırır.

2. max-prefix: sızıntıya karşı sigorta

Komşunuz yanlışlıkla tam tabloyu size duyurursa ne olur? max-prefix limiti bunu yakalar. Limit, komşunun PeeringDB'de beyan ettiği değerin biraz üzerinde tutulmalı: çok düşük olursa normal büyüme oturumu düşürür, çok yüksek olursa koruma anlamsızlaşır.

Limit aşıldığında oturumu hemen kalıcı olarak kapatmak yerine bir süre sonra otomatik yeniden denemek pratik bir ortadır. Transit oturumlarında tam tablo beklendiği için limiti mevcut tablo boyutuna göre ayarlayın ve tablo büyüdükçe güncellemeyi unutmayın.

3. Oturum kimlik doğrulama: MD5 ve TCP-AO

TCP MD5 imzası (RFC 2385) hâlâ en yaygın yöntemdir ve çoğu IX ile upstream bunu destekler. Zayıflığı bilinir: MD5 eski bir algoritmadır ve anahtar değişimi oturumu kesmeden yapılamaz. Halefi TCP-AO (RFC 5925) daha güçlü algoritmalar ve kesintisiz anahtar rotasyonu sunar; ancak her iki tarafın da desteklemesi gerekir.

Buna ek olarak GTSM (RFC 5082, ttl-security) açın. Doğrudan bağlı bir eBGP komşusundan gelen paketlerin TTL'i 255 olmalıdır; uzaktan sahte paket gönderen biri bu değeri tutturamaz. Kontrol düzlemine yönelik basit ama etkili bir korumadır.

4. BGP community: politikayı etiketle yönetin

Rotaları nereden öğrendiğinize göre etiketleyin. Örneğin:

64500:1000  müşteriden öğrenildi
64500:2000  peer'den öğrenildi
64500:3000  transit'ten öğrenildi

Dışa duyuru filtresi böylece "sadece 64500:1000 etiketli ve kendi prefix'lerimiz" kadar basit bir kurala iner. Upstream'lerinizin sunduğu community'leri (prepend, belirli bölgelere duyurmama, blackhole) da öğrenin; trafik mühendisliği ve DDoS müdahalesinde bunlar en hızlı araçlarınızdır. Büyük (large) community'ler (RFC 8092) 32 bit ASN'lerle çalışırken zorunlu hale gelir.

5. RPKI: geçersiz rotaları düşürün

Kendi prefix'leriniz için ROA oluşturun ve içe aldığınız rotalara Route Origin Validation (ROV) uygulayın. Önerilen politika RPKI invalid olanları reddetmek, valid ve not-found olanları kabul etmektir. Bunun için bir validator (Routinator, rpki-client, FORT) çalıştırıp router'a RTR protokolüyle bağlamanız gerekir. Tek bir validator'a bağımlı kalmamak için en az iki tane kurun.

6. Graceful shutdown: bakımda trafiği önceden taşıyın

Bir oturumu bakım için kapatacaksanız doğrudan disable demek, komşunun rotaları kaybetmesine ve kısa süreli paket kaybına yol açar. RFC 8326, iyi bilinen GRACEFUL_SHUTDOWN community'sini (65535:0) tanımlar: bu community ile işaretlenen rotaların local-pref'i karşı tarafta 0'a düşürülür ve trafik alternatif yollara kayar. Birkaç dakika bekleyip trafiğin sıfırlandığını gördükten sonra oturumu kapatırsınız.

Bunun çalışması için hem sizin hem komşunuzun bu community'yi tanıması gerekir; kendi içe alma filtrenize de 65535:0 gördüğünüzde local-pref'i 0 yapan kuralı ekleyin.

7. İzleme: oturumu kurduktan sonra işiniz bitmedi

En azından şunları izleyin:

  • Oturum durumu ve flap sayısı
  • Alınan ve gönderilen prefix sayısı (ani değişim uyarısı ile)
  • max-prefix eşiğine yakınlık (örneğin yüzde 80)
  • Kendi prefix'lerinizin dışarıdan nasıl göründüğü: RIPE RIS, bgp.tools veya bir looking glass üzerinden origin ASN ve path kontrolü

Dışarıdan görünürlük için kendi looking glass'ınız da işe yarar; Netlojik'in https://lg.netlojik.com adresindeki looking glass'ı örneğin rota ve path sorgusu için kullanılabilir. Prefix hijack uyarıları için BGPalerter gibi açık kaynak araçlar kurulumu kolay seçeneklerdir.

Örnek: BIRD 2 ile bir eBGP oturumu

Yukarıdaki maddelerin bir kısmını bir araya getiren kısa bir örnek:

roa4 table rpki4;

protocol rpki validator1 {
    roa4 { table rpki4; };
    remote 192.0.2.10 port 3323;
    retry keep 90;
    refresh keep 900;
}

filter import_upstream {
    if net.len > 24 then reject;
    if net ~ [ 203.0.113.0/24+ ] then reject;      # kendi alanımız
    if roa_check(rpki4, net, bgp_path.last) = ROA_INVALID then reject;
    if (65535, 0) ~ bgp_community then bgp_local_pref = 0;
    bgp_large_community.add((64500, 3000, 0));
    accept;
}

filter export_upstream {
    if net ~ [ 203.0.113.0/24 ] then accept;
    reject;
}

protocol bgp upstream1 {
    local 198.51.100.2 as 64500;
    neighbor 198.51.100.1 as 64501;
    password "degistirin";
    ttl security on;
    ipv4 {
        import filter import_upstream;
        export filter export_upstream;
        import limit 1100000 action restart;
    };
}

Bu örnek başlangıç için yeterlidir; gerçek ortamda bogon listeleri, IPv6 karşılığı ve müşteri oturumları için IRR'den üretilen listeler eklenir. Daha kapsamlı teknik notlar için dokümanlar sayfasına bakabilirsiniz.

Toparlarken

Yedi maddenin ortak noktası, komşunuza varsayılan olarak güvenmemek ve her kararı açıkça yazılı hale getirmektir. Filtreler ve max-prefix hatalı duyurulardan, TCP-AO ve GTSM sahte paketlerden, RPKI yanlış origin'den, graceful shutdown bakım kesintisinden korur. İzleme ise bunların hâlâ çalıştığını size haber verir.

Diğer yazılar

Tüm yazılar