BGP Max-Prefix Limit ile Edge Kesinti Önleme

Edge’de BGP konuşan her kurumun sessiz bir riski vardır: yanlış prefix dalgası. Bu dalga bazen upstream’ten gelen route leak, bazen de bir konfigürasyon hatası yüzünden oluşur. Sonuç çoğu zaman aynıdır:

• RIB/FIB şişer, CPU artar
• Control plane gecikir
• BGP session’lar flap olur
• “Asıl problem” bir anda “internet gitti” incident’ına dönüşür

Bu yazıda, bu sınıf incident’ları küçültmek için en yüksek değerli guardrail’lerden birini anlatıyorum: max-prefix limit.

Max-prefix neden “operasyonel” bir kontroldür?

Max-prefix limit, bir BGP komutu gibi görünür ama aslında şu soruya cevap verir:

“Bu komşudan (peer/upstream) beklediğim prefix sayısı nedir ve sapma olursa nasıl davranacağım?”

Bu yüzden max-prefix:

• Hata önleme (leak dalgasında otomatik fren)
• Alarm üretimi (warning threshold)
• Runbook tetikleyicisi (kimin kimi arayacağı)

1) İlk adım: normal prefix baz çizgisi

Max-prefix’i rastgele sayıyla açmayın. Önce baz çizgi:

• 7–14 gün boyunca prefix sayısını ölç
• Haftalık değişim (trend) ve “patch day” gibi anomali günlerini not et

İki sayı önemli:

• Normal (median)
• Pik (95th/99th percentile)

Limit bu ikisini taşıyacak ama “leak”i yakalayacak şekilde konumlanır.

2) Tasarım: 3 katmanlı guardrail

Sahada en stabil model:

1. Warning threshold: %80–90’da alarm
2. Hard limit: belirli sayıda “trip”
3. Trip davranışı: session kapansın mı, route’lar mı kesilsin, yoksa sadece log mu?

Trip davranışı kurumun risk iştahına göre değişir:

• Bazı edge’lerde “session’ı kapat” daha iyi (bozuk bilgiyi içeri alma)
• Bazılarında “session açık kalsın ama yeni prefix’i alma” (vendor destekliyorsa)

Önemli olan: bu davranışın incident anında sürpriz olmaması.

3) Pratik konfigürasyon örnekleri (vendor-agnostic)

Aşağıdaki örnekler kavramı anlatır; kendi cihazınıza uyarlayın.

Junos (örnek)

set protocols bgp group TRANSIT neighbor <peer> family inet unicast prefix-limit maximum 140000
set protocols bgp group TRANSIT neighbor <peer> family inet unicast prefix-limit teardown 5
set protocols bgp group TRANSIT neighbor <peer> family inet unicast prefix-limit idle-timeout 60

Cisco IOS-XR (örnek)

neighbor <peer>
 address-family ipv4 unicast
  maximum-prefix 140000 90 restart 1

Buradaki kritik fark: 90 genelde warning threshold gibi çalışır; “limit yaklaştı” alarmı için kullanılır.

4) İzleme: hangi alarm gerçekten işe yarar?

Üç alarmı net koyun:

• Prefix count threshold aşıldı (warning)
• Session flap (stability)
• Control plane CPU / route processing süreleri (kapasite)

Bu alarmlar birleşince “leak mi, normal growth mu?” ayrımı hızlanır.

5) Incident runbook: max-prefix trip olduğunda

1. Hızlı doğrulama: gerçekten max-prefix mi?
   • log’da “prefix limit exceeded” benzeri kayıt
   • NMS/telemetry’de prefix count spike
2. Etki: hangi servisler etkilendi? (internet egress mi, partner mi)
3. Kaynak: hangi peer? (transit/IX/partner)
4. Karar:
   • leak upstream ise: upstream’e eskalasyon + geçici filtre
   • kendi tarafımız ise: son config diff, son maintenance, change id
5. Geçici mitigasyon (risk kabulüyle):
   • limit’i kısa süreli yükselt (sadece kanıt varsa)
   • veya sesssion’ı kontrollü kapat (bozuk rotayı içeri almamak için)
6. Kalıcı önlem:
   • prefix-filter/policy daralt
   • max-prefix değerini baz çizgiye göre güncelle
   • postmortem: “neden alarm daha erken çalmadı?”

Sonuç

Max-prefix limit, edge’deki en düşük maliyetli ama en yüksek etkili guardrail’lerden biridir. Değerini route leak yaşanınca değil, route leak yaşanmadığında fark ettirir: control plane’i korur, incident blast radius’i küçültür ve karar anında belirsizliği azaltır. Sahada fark yaratan şey; komutu yazmak değil, baz çizgiyi kurmak, alarm eşiğini doğru seçmek ve runbook’u gerçekten işletmektir.