Kurumsal edge’de BGP konuşmaya başladığınız gün, sadece “internet çıkışı” açmış olmazsınız; trafik akışını yönettiğiniz bir kontrol düzlemi de kurarsınız. Sorun şu: BGP Traffic Engineering (TE) çoğu ekipte “birkaç knob çevirmek” olarak kalır. Sonuç da tahmin edilebilir:
- İstenmeyen inbound/outbound kaymaları
- POP/ISP dengesizliği, kapasite sürprizleri
- Incident anında panikle yapılan değişiklikler
- Geri dönüş (rollback) planı olmayan “kalıcı geçici çözümler”
Bu yazı, kurumsal edge’de en çok iş gören TE araçlarını (localpref, community, prepend, MED) “hangi durumda hangisi?” mantığıyla bir runbook formatında anlatır.
1) İlk ayrım: Outbound mı, inbound mı?
TE’yi doğru yönetmek için iki soruyu net ayırın:
- Outbound (egress): Kurumdan çıkan trafik hangi ISP/POP üzerinden gitsin?
- Inbound (ingress): İnternetten size gelen trafik hangi ISP/POP üzerinden gelsin?
Bu ayrım kritik çünkü çoğu knob sadece bir yöne etki eder:
- LocalPref: çoğunlukla outbound seçim (kurum içi politika)
- AS-path prepend: çoğunlukla inbound etki (uzaktan görünen yol)
- MED: inbound etkileyebilir ama yalnızca belirli koşullarda (aynı upstream/AS)
- Community: upstream’e “benim için bunu yap” sinyali (inbound/outbound olabilir)
2) Minimum gözlem seti (değişiklik yapmadan önce)
TE’de en pahalı hata: değişiklik yaptınız ama neyi değiştirdiğinizi ölçmediniz.
Değişiklik öncesi minimum sinyaller:
- BGP oturum sağlığı: session up/down, flap sayısı
- Prefix/route sayıları: kabul/ilan edilen prefix, “expected vs observed”
- Trafik dağılımı: ISP/POP bazında bps/pps/flow
- Servis etkisi: kritik servis latency/timeout (internet egress etkiler)
- DNS/Anycast varsa: POP bazında query/rcode dağılımı
Operasyonel pratik: “TE değişikliği” için 15–30 dakikalık bir gözlem penceresi tanımlayın ve değişiklik sonrası aynı pencereyi tekrar okuyun.
3) Araç seçimi: Hangi knob ne zaman?
3.1 Outbound için: LocalPref (birincil araç)
Outbound seçimde en deterministik yöntem localpref’tir (kurum içi).
Ne zaman kullanılır?
- “Trafik ISP-A’dan çıksın, ISP-B yedek olsun”
- “POP-1 çıkışı doysun ama POP-2 devreye girsin”
- “Belirli hedef AS’lere farklı egress”
Runbook adımı:
- Hedefi yaz: “Outbound %70 ISP-A, %30 ISP-B” gibi net ölçü
- Sadece tek sınıf rota için uygula: ör. “default route” veya “transit learned”
- 1 POP’ta başla (ring rollout)
- Rollback: eski localpref değerini hazır tut
3.2 Inbound için: Community (varsa en temiz araç)
Upstream’ler genelde community’lerle şu tip kontroller sunar:
- 특정 POP/region’e prepend
- Blackhole / RTBH
- Localpref manipülasyonu (upstream içinde)
- “No-export” gibi yayılım kısıtları
Ne zaman kullanılır?
- “ISP’in kendi ağında kontrol istiyorum”
- “Bir POP’u inbound’da geçici de-prefer et”
Risk: Community sözleşmesi dokümansızsa veya farklı ekipler farklı yorumluyorsa, “tek satır config” büyük etki yaratır.
3.3 Inbound için: AS-path prepend (en yaygın ama en belirsiz)
Prepend, uzaktaki seçimi dolaylı etkiler. Bu yüzden “ince ayar” değil, daha çok kaba yönlendirme aracı gibi düşünün.
Ne zaman kullanılır?
- Upstream community seçenekleri sınırlıysa
- İki ISP arasında “öncelik” yaratmak istiyorsanız
Operasyonel kurallar:
- Tek seferde agresif prepend yapmayın; kademeli gidin (ör. +1, sonra +2)
- POP/ISP bazında farklı prepend ile kapasiteyi dengeleyin
- Etkisini ölçmeden “kalıcı” yapmayın; 24 saat içinde tekrar gözden geçirin
3.4 MED: Sadece doğru bağlamda işe yarar
MED, genelde aynı upstream AS içinde farklı giriş noktaları arasında seçimde anlamlıdır. Çoklu ISP senaryosunda çoğu zaman beklediğiniz etkiyi vermez.
Kural: MED’i “hayat kurtaran knob” gibi değil, sınırlı bir sinyal gibi kullanın.
4) Değişiklik akışı (operasyonel model)
Benim sahada en çok işe yarayan akış:
- Hedef cümlesi: “Inbound trafiğin %20’si POP-2’ye kayacak”
- Kapsam: hangi prefix’ler? tüm internet mi, belirli servis mi?
- Gözlem: hangi paneller/metric’ler karar kriteri?
- Rollback: tek komutla geri dönüş mümkün mü?
- Zaman kutusu: 30 dk gözlem, sonra karar
- Kayıt: değişiklik günlüğü (ne, neden, ne oldu)
5) Incident triage: Trafik “yanlış” yere kaydıysa
5.1 İlk kontrol listesi (5 dakika)
- BGP session’lar stabil mi? Flap var mı?
- İlan ettiğiniz prefix seti değişti mi? (eksik/ fazla anons)
- Route-map/policy sırası değişti mi?
- Anycast/ECMP/IGP tarafında POP içi yönlendirme bozuldu mu?
- Upstream tarafında maintenance / policy değişikliği var mı?
5.2 Hızlı aksiyon (en az riskli)
En az riskli geri dönüş genelde şudur:
- Outbound sorunda: localpref’i eski değerine al
- Inbound sorunda: eklediğin community/prepend’i geri al
“Yeni bir ayar ekleyerek düzeltme” refleksi, krizi uzatır. Önce sistemi eski stabil haline döndürün, sonra kök neden.
6) Minimum viable TE kontrol listesi
- Inbound/outbound hedefi ayrı yazıldı
- TE değişikliği bir POP’ta denendi (ring rollout)
- 30 dk önce/sonra gözlem penceresi kaydedildi
- Rollback komutu hazır
- Upstream community sözleşmesi dokümante
- Incident anında kullanılacak “TE triage” runbook’u var
Kurumsal edge’de BGP TE, “ağı daha güzel yapmak” değil; operasyonel riski yönetmek için yapılan bir iştir. Knob’lar aynı kalsa da yaklaşım değiştiğinde sonuç değişir: hedef cümlesi, ölçüm ve rollback ile TE, sürpriz üreten bir alan olmaktan çıkar.