“Redistribute yapacaksanız dikkat: Bir satır yanlış, tüm routing’i bozar.”

Related Articles

Cisco HSRP Troubleshooting: Gateway Yedekliliği Neden Çalışmıyor?

2 gün ago

Cisco NAT Troubleshooting: NAT Çalışmıyorsa Nereden Başlanmalı?

1 hafta ago

Cisco BGP Best Path Selection: BGP En İyi Rotayı Nasıl Seçer?

2 hafta ago

OSPF ↔ BGP arasında güvenli ve öngörülebilir route redistribution için 6 adım 🚨🛣️

OSPF ile BGP arasında route paylaşımı sahada sık görülür; ama yanlış metric, loop, kötü filtreleme veya “default açık kalsın” yaklaşımı; route leak, suboptimal routing, hatta LSA flood gibi zincirleme problemlere yol açabilir. Aşağıdaki rehber, gerçek ortamda uygulanabilir şekilde kural + komut + kontrol odaklıdır.

---

1) Planla: “Neyi gerçekten paylaşacağım?”

Temel kural: Önce permit listesi, sonra redistribute.
permit ip any any (ve benzeri geniş match) redistribution başlangıcı için asla doğru tercih değil.

✅ Önce şu sorulara net cevap verin:

• Hangi prefix’ler OSPF’ten BGP’ye çıkmalı?
• Hangi BGP prefix’leri OSPF’e inmeli?
• Default route taşınacak mı? (Evetse çok kontrollü)
• Hangi VRF/zone/domain kapsamı?

Örnek yaklaşım:

• “Sadece servis VLAN’ları (10.10.0.0/16 → /24’e kadar)”
• “Sadece belirli site prefix’leri”
• “Transit/Internet route’larını asla IGP’ye indirme”

---

2) Sıkı filtre: Prefix-list + Route-map (Redistribute’ın emniyet kemeri)

OSPF → BGP (örnek)

ip prefix-list FROM_OSPF seq 5 permit 10.10.0.0/16 le 24
ip prefix-list FROM_OSPF seq 10 deny 0.0.0.0/0 le 32
!
route-map OSPF-TO-BGP permit 10
 match ip address prefix-list FROM_OSPF
 set local-preference 200
!
router bgp 65000
 neighbor 192.0.2.2 route-map OSPF-TO-BGP out

Neden iyi?

• “Hangi route’lar çıkacak?” sorusunun cevabı net ve denetlenebilir olur.
• Geniş sızıntı riskini azaltırsınız.

Kritik not: “out route-map” komşuya gönderimi filtreler; OSPF’ten BGP’ye “redistribute” yapıyorsanız ayrıca redistribute ospf ... route-map ... tarafını da tasarlamanız gerekir. (Platform/vendor farklarına göre isim ve yaklaşım değişebilir.)

---

3) Metric + Tag/Community: Loop ve “geri dönüş” (feedback loop) engeli

Redistribution’da en sık yıkım nedeni:
Bir rotanın A’dan B’ye, sonra B’den tekrar A’ya dönüp ‘daha iyi’ sanılarak seçilmesi.

BGP → OSPF: Tag ile işaretle ve geri dönüşü engelle

route-map BGP-TO-OSPF permit 10
 match ip address prefix-list FROM_BGP
 set tag 65000
!
router ospf 1
 redistribute bgp 65000 subnets route-map BGP-TO-OSPF

OSPF → BGP: Community/attribute ile işaretle

• OSPF kaynaklı prefix’leri BGP’de özel community ile işaretleyin (örn. 65000:100)
• Sonrasında inbound/outbound policy ile “OSPF-origin” rotaların geri içeri alınmasını engelleyin.

Altın kural:

• “Kaynağı işaretle, geri dönüşü filtrele.”

---

4) Tercih sırası: Administrative Distance & BGP Preference mantığını netleştir

OSPF mi “daha güvenilir” olacak, BGP mi? Bu sorunun cevabı, özellikle dual-homed veya route reflection / multi-domain ortamlarda kritiktir.

✅ Yapmanız gereken:

• Hangi prefix sınıfı için hangi protokol kazansın (IGP vs eBGP/iBGP)?
• Gerekirse:
  • OSPF cost/metric
  • BGP local-pref / weight
  • (Vendor’a göre) distance ayarı

Uyarı: Distance’ı “her şeye” uygulamak, debug’ı zorlaştırır. Sadece gerekli prefix sınıflarında, route-map/policy ile sınırlandırmak daha güvenlidir.

---

5) Emniyet bariyerleri: Max-prefix, dampening ve sürekli doğrulama

Redistribute sonrası “prefix patlaması” (leak) en riskli senaryodur. Bunu teknik bariyerlerle sınırlandırın:

BGP komşusunda max-prefix (örnek)

neighbor 192.0.2.2 maximum-prefix 5000 90 restart 120

✅ Doğrulama komut seti (minimum):

• show ip route <prefix>
• show ip bgp <prefix> / show bgp …
• show ip ospf database (LSA flood var mı?)
• show ip ospf border-routers (ASBR davranışı)
• show route-map / show prefix-list hit counter (varsa)

Pratik: “prefix count baseline” çıkarın (değişiklik öncesi kaç prefix vardı?) Sonra artışları alarm’layın.

---

6) Test & Canary: Önce küçük scope, sonra yayılım (ve rollback)

Redistribution “big bang” yapılmaz.

✅ Canary stratejisi:

• Önce tek VRF / küçük site / sınırlı prefix ile dene
• Otomasyonla doğrula:
  • pyATS / Ansible ile “beklenen route sayısı”, “beklenen next-hop”, “beklenen AS-path” kontrolleri
• Fail olursa:
  • Rollback (git repo → playbook revert / config rollback)

En iyi pratik:

• Değişiklik penceresinde “önceden hazırlanmış rollback” olmadan redistribute’a girilmez.

---

Sonuç: Güvenli redistribution checklist’i

• Prefix-list “permit list” hazır mı?
• Route-map ile scope daraltıldı mı?
• Tag/community ile origin işaretlendi mi?
• Geri dönüş filtreleri yazıldı mı?
• Max-prefix / alarm / baseline var mı?
• Canary + rollback planı hazır mı?