İçeriğe Atla
Rehberler · 11 dk okuma · görüntülenme
100%

FRRouting ile BGP Failover Lab Rehberi

Çift uplink kullanan sunucu veya edge ortamlarında BGP failover davranışını laboratuvarda doğrulama adımları.

Çift router, FRRouting düğümü ve BGP yol değişimini gösteren kapak görseli

BGP failover senaryolarını üretimde öğrenmek pahalıdır. Çift uplink kullanan edge sunucular, transit router’lar veya servis gateway’leri için daha güvenli yol, davranışı küçük bir laboratuvarda önceden gözlemlemektir. FRRouting bu iş için hafif ve yeterince esnek bir araç sağlar.

Çift router, FRRouting düğümü ve BGP yol değişimini gösteren teknik şema
Laboratuvar topolojisi küçük olsa da amaç nettir: komşu kaybı ve rota değişiminin sistem davranışını önceden görmek.

Hangi senaryoyu test ediyoruz?

Bu rehberde tek bir FRRouting düğümünün iki ayrı upstream router ile BGP komşuluğu kurduğunu varsayıyoruz. Amaç:

  • Normal durumda birincil yolu tercih etmek
  • Bir upstream düştüğünde trafiğin ikincil yola akmasını görmek
  • Failback anında davranışı ölçmek

Bu düzen, veri merkezi edge katmanı veya kurumsal servis çıkış noktası için iyi bir başlangıç simülasyonudur.

Basit lab topolojisi

Örnek IP planı şöyle olabilir:

  • edge01: 10.10.10.10/24
  • rtr-a: 10.10.10.1/24
  • rtr-b: 10.10.10.2/24
  • Yerel ASN: 65010
  • Upstream ASN’ler: 65100 ve 65200

Laboratuvarı container, sanal makine veya ağ namespace’leri ile kurabilirsiniz. Önemli olan komşulukların gerçekten kurulması ve rota tercihinin gözlenebilmesidir.

FRRouting kurulumu ve temel ayar

Ubuntu tabanlı bir düğümde kurulum mantığı şu şekildedir:

sudo apt-get update
sudo apt-get install -y frr frr-pythontools
sudo sed -i 's/^bgpd=no/bgpd=yes/' /etc/frr/daemons
sudo systemctl restart frr

Ardından temel frr.conf iskeleti:

frr version 10.0
frr defaults traditional
hostname edge01
service integrated-vtysh-config
!
router bgp 65010
 bgp router-id 10.10.10.10
 neighbor 10.10.10.1 remote-as 65100
 neighbor 10.10.10.2 remote-as 65200
 !
 address-family ipv4 unicast
  network 192.0.2.0/24
  neighbor 10.10.10.1 route-map PREFER_A in
  neighbor 10.10.10.2 route-map BACKUP_B in
 exit-address-family
!
route-map PREFER_A permit 10
 set local-preference 200
!
route-map BACKUP_B permit 10
 set local-preference 100

Buradaki mantık basit: rtr-a üzerinden gelen yollar daha yüksek local-preference ile seçiliyor.

Test adımları

İlk doğrulama için şu komutlar yeterlidir:

sudo vtysh -c "show bgp ipv4 unicast summary"
sudo vtysh -c "show bgp ipv4 unicast"
ip route get 203.0.113.10

Sonra birincil komşuyu düşürün. Bunun için lab ortamınıza göre arayüz kapatma, BGP oturum kesme veya iptables ile TCP/179 bloklama gibi yöntemler kullanılabilir. Beklenen sonuç:

  1. rtr-a komşuluğu düşer.
  2. En iyi yol rtr-b üzerinden seçilir.
  3. FIB güncellenir.
  4. Uygulama akışı kısa bir geçiş süresinden sonra devam eder.

Failback sırasında ise en sık gözlenen sorun, rotanın çok hızlı geri dönmesi nedeniyle bağlantı flap’leridir. Bu durumda route dampening değil, daha kontrollü tercih politikaları ve üst katman zamanlaması düşünülmelidir.

Ölçülmesi gereken metrikler

Sadece “rota değişti” demek yeterli değildir. Şunları ölçün:

  • BGP komşuluk düşüş süresi
  • Yeni en iyi yolun seçilme süresi
  • Uygulama seviyesinde başarısız istek sayısı
  • Failback sırasında tekrar seçimin ne kadar sürdüğü

Bu ölçümler, ağ tasarımının uygulama davranışına gerçekten nasıl yansıdığını gösterir.

Üretime geçmeden önce hangi tuzakları kontrol etmeli?

  • İki upstream aynı prefix’i farklı topluluklarla mı duyuruyor?
  • Varsayılan rota mı, belirli prefix’ler mi taşınıyor?
  • ECMP isteniyor mu, yoksa kesin birincil/ikincil akış mı gerekli?
  • Uygulama bağlantıları kısa kesintilere toleranslı mı?

Laboratuvarın amacı teoriyi kanıtlamak değil, üretim varsayımlarını erkenden kırmaktır.

Sonuç

FRRouting ile kurulan küçük bir BGP laboratuvarı, failover davranışını anlamak için yeterince güçlüdür. Özellikle edge servisleri, yönetim ağları ve kurumsal çıkış noktaları için rota seçiminin pratik etkisini önceden görmek ciddi operasyon kazancı sağlar. Ağ dayanıklılığı, yalnızca yedek bağlantı eklemekle değil, o yedeğin gerçekten ne zaman ve nasıl devreye girdiğini ölçmekle oluşur.

Paylaş:

Bu yazı faydalı oldu mu?

Yükleniyor...

Bu yazı nasıldı?

ME

Mustafa Erbay

Sistem Mimarisi · Network Uzmanı · Altyapı, Güvenlik ve Yazılım

2006'dan bu yana sistem mimarisi, network, sunucu altyapıları, büyük yapıların kurulumu, yazılım ve sistem güvenliği ekseninde çalışıyorum. Bu blogda sahada karşılığı olan teknik deneyimlerimi paylaşıyorum.

Kişisel Notlar

Bu notlar sadece sizde saklanır. Tarayıcınızda yerel olarak tutulur.

Hazır 0 karakter

Yorumlar

Sunucu Taraflı AI Moderasyon

Yorumlar sunucuda yapay zeka ile denetlenir ve kalıcı olarak saklanır.

?
0/2000

Sunucu taraflı AI denetim

Yeni yazılardan haberdar olun

Haftada bir yeni içerikler ve kaynaklar doğrudan e-postanıza gelsin.

Spam yok. Yalnızca yeni ve önemli içerikler için e-posta gönderilir.

Okuma İstatistikleriniz

0

Yazı Okundu

0dk

Okuma Süresi

0

Gün Serisi

-

Favori Kategori

İlgili Yazılar