Bird 2 ile Route Reflector Lab Tasarımı

BGP topolojilerinde route reflector davranışını üretimde öğrenmek pahalıdır. Özellikle spine-leaf, edge veya veri merkezi geçişlerinde küçük bir yansıma hatası geniş bir yönlendirme etkisi doğurabilir. Bird 2 ile route reflector lab tasarımı, bu davranışları düşük maliyetle test etmek ve karar mantığını net görmek için güçlü bir yöntemdir.

Lab hedefi

Bu rehberde üç istemci router ve iki route reflector düğümünden oluşan sade bir BGP laboratuvarı kuracağız. Amaç, production ölçeğini taklit etmek değil; şu davranışları doğrulamaktır:

• Route reflector cluster yapısı
• Client ve non-client oturum farkı
• Route yayılımının doğrulanması
• Failover anında adjacency ve route davranışı

Lab’ı container veya VM üzerinde kurabilirsiniz. Bird 2 hafif olduğu için küçük test ortamlarında rahat çalışır.

Topoloji

Örnek topoloji şu mantıkla ilerler:

1. rr1 ve rr2 route reflector olarak görev yapar.
2. leaf1, leaf2 ve edge1 istemci router rolündedir.
3. Tüm düğümler aynı private lab ağı üzerinde BGP komşuluğu kurar.

Basit bir adresleme örneği:

rr1   10.10.0.11   AS 65000
rr2   10.10.0.12   AS 65000
leaf1 10.10.0.21   AS 65000
leaf2 10.10.0.22   AS 65000
edge1 10.10.0.31   AS 65000

Bu örnekte iBGP kullanıyoruz. Route reflector mantığını görmek için bu yeterli.

Bird 2 kurulumu

Debian veya Ubuntu tabanlı bir sistemde:

sudo apt update
sudo apt install -y bird2

Servis dosyası kurulduktan sonra ana konfigürasyon tipik olarak /etc/bird/bird.conf altında bulunur. İlk aşamada her düğüm için farklı dosya üreterek ilerlemek daha okunabilir olur.

Route reflector düğümü için örnek konfigürasyon

rr1 üzerinde sade bir örnek:

router id 10.10.0.11;

protocol device {}
protocol direct {}

template bgp RR_CLIENT {
  local as 65000;
  rr client;
  ipv4 {
    import all;
    export all;
  };
}

protocol bgp leaf1 from RR_CLIENT {
  neighbor 10.10.0.21 as 65000;
}

protocol bgp leaf2 from RR_CLIENT {
  neighbor 10.10.0.22 as 65000;
}

protocol bgp edge1 from RR_CLIENT {
  neighbor 10.10.0.31 as 65000;
}

İkinci reflector için benzer yapı kurulabilir. İki reflector kullanmak, tek düğüm arızasında rotaların nasıl davrandığını görmek açısından önemlidir.

İstemci router örneği

leaf1 için sade bir istemci konfigürasyonu:

router id 10.10.0.21;

protocol device {}
protocol direct {}
protocol static {
  route 192.168.21.0/24 via "lo";
}

template bgp RR_PEER {
  local as 65000;
  ipv4 {
    import all;
    export where source = RTS_STATIC;
  };
}

protocol bgp rr1 from RR_PEER {
  neighbor 10.10.0.11 as 65000;
}

protocol bgp rr2 from RR_PEER {
  neighbor 10.10.0.12 as 65000;
}

Bu tanım, istemcinin kendi static rotasını reflectorlara duyurmasını sağlar.

Doğrulama adımları

Konfigürasyon sonrası şu kontrolleri yapın:

sudo birdc show protocols
sudo birdc show route
sudo birdc show route all 192.168.21.0/24

Beklenen davranışlar:

• Tüm BGP oturumları Established görünmeli
• leaf2 ve edge1, leaf1 kaynaklı prefix’i reflectorlardan öğrenmeli
• Reflector düğümünde route origin ve next-hop bilgisi okunabilir olmalı

Sonra rr1 servisini durdurup rr2 üzerinden route sürekliliğini test edebilirsiniz.

Lab’ı değerli kılan genişletmeler

Temel akış çalıştıktan sonra lab’a şu denemeleri eklemek faydalıdır:

• Local-pref farkı
• Route-map veya filter kullanımı
• next hop self davranışı
• Reflector dışı peer ile non-client dağıtımı

Bu deneyler, üretim geçişinde dokümantasyon okumaktan çok daha net içgörü sağlar.

Sonuç

Bird 2 ile route reflector lab tasarımı, BGP davranışını küçük ve denetlenebilir bir ortamda görünür kılar. Özellikle kurumsal ağ modernizasyonu, veri merkezi segmentasyonu veya edge yönlendirme kararları öncesinde bu tür bir lab, pahalı sürprizleri azaltır. Önemli olan mükemmel laboratuvar kurmak değil; hangi route kararının neden oluştuğunu güvenli biçimde gözleyebilmektir.