BGP Full Routing Table mı, Default Route mu? RAM/CPU Etkisi

BGP oturumunda full routing table almak, tek upstream ile çalışan ve sadece kendi prefix'ini anons eden çoğu kullanıcı için gerekli değildir. Bu durumda default route veya sağlayıcının kendi rotaları artı bir default yeterlidir. Full table ise birden fazla upstream'in arasında yol seçimi yapmak, kendi çıkış politikanı yönetmek veya rota verisini analiz etmek istediğinde anlam kazanır.

Bu yazıda üç seçeneği (full table, default route, sadece sağlayıcı rotaları) RAM/CPU etkisi, kullanım senaryosu ve BIRD 2 filtre örnekleriyle karşılaştırıyoruz. Örneklerde dokümantasyon ASN'leri ve prefix'leri kullanılmıştır: AS64496 (sen), AS64497 (upstream), 198.51.100.0/24 (senin bloğun), 192.0.2.0/24 (bağlantı ağı).

Üç seçenek ne anlama geliyor?

Rota sayıları zamanla artar; güncel sayıyı kendi oturumundan birdc show route count ile okuman en doğrusudur.

Full table'ın RAM ve CPU maliyeti

Full table'ı bir BGP daemon'ında tutmanın maliyeti üç yerden gelir:

1. BGP daemon'ın RIB'i (BIRD, FRR bgpd): Her prefix için path attribute'ları, next-hop, community'ler saklanır. Tek bir full table için kabaca yüzlerce MB seviyesini beklemek makul olur; IPv4 + IPv6 birlikte ve birden fazla upstream varsa bu katlanır.
2. Linux kernel FIB: Rotaları kernel'e aktarırsan her prefix kernel belleğinde de yer tutar. Çok sayıda rota için ek yüzlerce MB gerekebilir.
3. CPU: Oturum ilk kurulduğunda ve her session reset'inde tüm tablo yeniden işlenir. Bu anlık bir CPU patlamasıdır. Kararlı durumda ise güncellemeler (churn) düşük ama sürekli yük üretir.

Bu rakamlar BIRD/FRR sürümüne, tek veya çok upstream'e ve eklediğin filtrelere göre değişir. Kesin rakam için kendi ortamında ölç:

# BIRD 2
birdc show route count
birdc show memory
birdc show protocols all upstream1

# FRR
vtysh -c "show bgp summary"
vtysh -c "show bgp memory"
vtysh -c "show ip route summary"

# Sistem geneli
free -m
ps -o pid,rss,cmd -C bird

Pratik kural: 1-2 GB RAM'li küçük bir VDS'te full table + kernel'e aktarım risklidir. OOM killer BIRD'i öldürürse oturum düşer ve anonsun çekilir. Full table düşünüyorsan bellek payını bol tut ve ölçmeden üretime alma.

Default route: çoğu VDS kullanıcısı için yeterli

Amacın yalnızca kendi IP bloğunu internete duyurmak ve çıkış trafiğini upstream'e göndermekse, tüm internet tablosunu bilmene gerek yoktur. Upstream sana default route verir, sen de prefix'ini anons edersin.

Tek upstream varsa full table'ın sağlayacağı ek fayda neredeyse sıfırdır; çünkü zaten tüm trafik aynı yere gider. Bellek ve CPU yükü ise minimumdur.

Örnek BIRD 2 konfigürasyonu:

define MY_AS     = 64496;
define UP_AS     = 64497;
define MY_PREFIX = 198.51.100.0/24;

router id 192.0.2.2;

protocol device { }

protocol static announce4 {
    ipv4;
    route 198.51.100.0/24 blackhole;
}

filter import_default_only {
    if net = 0.0.0.0/0 then accept;
    reject;
}

filter export_mine {
    if net = MY_PREFIX then accept;
    reject;
}

protocol kernel {
    ipv4 {
        import none;
        export all;
    };
}

protocol bgp upstream1 {
    local 192.0.2.2 as MY_AS;
    neighbor 192.0.2.1 as UP_AS;
    ipv4 {
        import filter import_default_only;
        export filter export_mine;
        receive limit 10 action disable;
    };
}

Burada receive limit önemli bir güvenlik ağıdır. Upstream yanlışlıkla full table gönderse bile oturum devre dışı kalır ve küçük VDS'in belleği şişmez.

Uygulamadan sonra kontrol et:

birdc configure
birdc show protocols upstream1
birdc show route protocol upstream1
ip route show default

Sadece sağlayıcı rotaları: orta yol

Bu modelde sağlayıcı yalnızca kendi ağının ve müşterilerinin rotalarını gönderir. Dünyanın geri kalanına ulaşmak için ayrıca default route kullanırsın. Rota sayısı full table'a göre çok küçüktür; kaynak tüketimi düşük kalır.

Faydası: Sağlayıcı ağı içindeki hedeflere giden yolu açıkça görürsün (örneğin aynı sağlayıcıdaki bir müşteriye giden trafik doğrudan yönlenir), ayrıca prefix bazında politika uygulayabilirsin. Dezavantajı: Sağlayıcı dışındaki hedefler için yol seçimi yine sağlayıcıya aittir.

Sağlayıcı yalnızca kendi rotalarını gönderiyorsa ve default göndermiyorsa, statik default'u gateway'e kendin eklemen gerekir:

protocol static default4 {
    ipv4;
    route 0.0.0.0/0 via 192.0.2.1;
}

Bu yapıda sağlayıcı rotalarını kabul eden filtreye bir üst sınır koymayı unutma (örneğin receive limit 50000 action restart; değeri sağlayıcının verdiği gerçek sayıya göre ayarla).

Hangi senaryoda hangisi?

• Web/hosting, oyun sunucusu, tek upstream: Default route. Kaynak tüketimi düşük, yönetimi basit.
• VDS üzerinde BGP ile kendi bloğunu anons eden küçük ağlar: Default veya sağlayıcı rotaları. Full table'ın RAM'i VDS'e fazla yük bindirir.
• İki veya daha fazla upstream (multihoming): En az partial table, tercihen full table. Hangi upstream'in hangi hedefe daha iyi olduğuna karar vermek için rota görünürlüğü gerekir.
• Kendi router'ı olan, trafik mühendisliği yapan ağlar: Full table. Local-pref, community ve AS-path politikalarıyla çıkış kontrolü sağlanır.
• Analiz, izleme, rota görünürlüğü: Full table, genelde tek bir dedicated/fiziksel makinede.

Yaygın hatalar ve çözümleri

1. Receive limit koymamak. Upstream tarafındaki bir hata ya da yanlış konfigürasyon, beklemediğin kadar rota getirebilir. Çözüm: Her oturumda receive limit kullan.

2. Export filtresini boş bırakmak. Filtresiz export ile upstream'den öğrendiğin rotaları başka bir upstream'e geri verirsin; bu bir route leak'tir. Çözüm: Export filtresinde yalnızca kendi prefix'lerini kabul et (yukarıdaki export_mine).

3. Full table'ı küçük VDS'e almak. Bellek yetmeyince daemon ölür, oturum düşer. Çözüm: free -m ve ps ile ölç; gerekirse default veya partial'a geç.

4. Kernel'e gereksiz rota aktarmak. BGP daemon'da tutup kernel'e yazmamak mümkündür; ama forwarding yapıyorsan kernel'de olması gerekir. VDS'te sadece anons yapıyorsan default yeterlidir, kernel tablosu küçük kalır.

5. IPv4 ve IPv6'yı karıştırmak. IPv6 için ayrı channel ve ayrı filtre gerekir; ::/0 kabulü ve IPv6 export filtresi ayrıca tanımlanmalıdır.

6. Kendi prefix'ini içeri almak. Import filtresinde kendi bloğunu reddetmeyi unutma. Default-only filtrede zaten sorun olmaz, ama partial/full filtrelerde bunu açıkça ekle.

7. Session reset sonrası CPU sıçraması. Full table'da her reset tüm tabloyu yeniden işletir. Çözüm: Gereksiz birdc restart yerine birdc configure ile yumuşak yeniden yükleme kullan; kararlı bir graceful restart ayarı da fark yaratır.

Rota doğrulaması ve görünürlük

Hangi modeli seçersen seç, anonsunun dışarıdan nasıl göründüğünü kontrol et. Nixcon'un herkese açık looking glass aracında İzmir, Frankfurt ve ABD noktalarından BGP rota, ping ve traceroute sorgusu çalıştırarak prefix'inin yayılımını ve yol üzerindeki gecikmeyi görebilirsin. Ayrıca RPKI ROA kaydının doğru olduğundan emin ol; geçersiz ROA'lı bir prefix birçok ağda reddedilir.

Nixcon'da hangi seçenekler var?

Nixcon'un BGP destekli VDS hizmetinde kendi ASN'ini ve IP bloğunu VDS üzerindeki BGP oturumundan anons edebilirsin. Oturumda yalnızca Nixcon rotalarını ya da full routing table'ı seçebilirsin. DDoS korumasız veya korumalı anons seçenekleri de mevcuttur. ASN ve prefix sahipliği RPKI ROA ve RIR/IRR kayıtlarıyla otomatik doğrulanır, ASN'in AS-NIXCON AS-SET'ine eklenir ve kurulum otomatik yapılır.

Kısaca: Tek upstream ve küçük bir VDS için default veya sağlayıcı rotaları ile başla. Çoklu upstream ve ayrı router donanımı gerektiğinde full table'a geç. Hangisini seçersen seç, receive limit ve sıkı bir export filtresi vazgeçilmezdir.