Edge tarafında BGP incident’ları genelde aynı şekilde yaşanır: “bazı lokasyonlar gidiyor”, “bazı prefix’ler kayboldu”, “trafik blackhole’a düştü”. En büyük problem ise görünürlüktür. Router üzerindeki show çıktıları değerlidir ama geçmişi yakalamaz: olay bittikten sonra “ne oldu?” sorusu havada kalır.
BMP (BGP Monitoring Protocol), bu boşluğu doldurur: router’ların BGP update/withdraw akışını merkezi bir collector’a akıtarak zaman çizgisi üretir. Route analytics dediğim şey de bu zaman çizgisinden alarm ve triage pratiği çıkarmaktır.
BMP ne sağlar?
BMP ile hedeflediğiniz çıktı şudur:
- Hangi router, hangi komşudan, hangi prefix için ne zaman update aldı?
- AS‑PATH / next‑hop / community değişimi neydi?
- Withdraw dalgası mı var, route flap mi var, leak mi var?
Bu, NOC/NetOps için iki kritik kazanım üretir:
- Alarmı “link down” seviyesinden “routing davranışı bozuldu” seviyesine taşır
- Incident sonrası postmortem’de “kanıt” üretir
Mimari: Collector, saklama ve dashboard
Minimum bileşenler:
- Router’lardan BMP feed alan collector katmanı
- Olayları saklayan bir storage (zaman serisi + olay tabanı gibi düşün)
- Dashboard: prefix/peer/AS‑path odaklı görünüm
- Alarm motoru: eşikler ve anomali yakalama
Hangi sinyaller işe yarar?
BMP’den türetilen en faydalı sinyaller:
- Update rate spike: saniyede update sayısı bir anda patladı mı?
- Withdraw dalgası: belirli peer/prefix setinde toplu withdraw var mı?
- AS‑PATH değişimi: beklenmeyen AS eklendi mi? (leak / hijack şüphesi)
- Next‑hop değişimi: blackhole veya yanlış yönlendirme işareti
- Community değişimi: politika değişti mi? (örn. localpref/RTBH işaretleri)
İşin püf noktası: alarmı “her update” diye değil, bağlamla kurmak.
Incident triage: Üç tip olay, üç soru seti
1) Route leak şüphesi
Sorular:
- Leak hangi peer’dan başladı?
- Sadece bir edge mi, yoksa çoklu edge mi?
- AS‑PATH’te beklenmeyen geçiş var mı?
İlk müdahale yaklaşımı:
- Leak kaynağı peer ise: import policy’yi daralt, gerekirse geçici filtre uygula
- İç kaynak ise: yanlış redistribution / yanlış prefix‑list / yanlış community zincirini bul
2) Route flap
Sorular:
- Flap tek prefix mi, yoksa “çok prefix” mi?
- Flap tek peer mı, yoksa birden fazla peer mı?
- Flap bir bakım penceresiyle çakışıyor mu?
BMP zaman çizgisi, flap’in “başlangıç anını” verdiği için root-cause aralığını dramatik daraltır.
3) Blackhole / asimetrik erişim
Sorular:
- Next‑hop değişti mi?
- Sadece belirli lokasyonlar mı etkileniyor?
- Aynı prefix farklı upstream’lerden farklı mı duyuruluyor?
Operasyonel sınırlar ve riskler
- Router CPU/memory etkisi: doğru konfigürasyon şart (özellikle büyük update hacminde)
- Veri hassasiyeti: prefix ve komşuluk bilgisi kurum için kritik olabilir; erişim kontrolü şart
- Saklama maliyeti: “sonsuz log” değil, ihtiyaç kadar süre
Sonuç
Route analytics, pahalı bir NMS projesi değil; routing davranışını ölçülebilir kılma pratiğidir. BMP’yi doğru yerde açıp doğru sinyallerle alarm bağladığınızda, BGP incident’ları “gizemli edge sorunu” olmaktan çıkar; kanıta dayalı triage ve postmortem disiplinine dönüşür.