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

İlgili yazılar

Cisco QoS Troubleshooting: Policy Var Ama Trafik Neden Önceliklenmiyor?

2 gün önce

Cisco VLAN Trunk Troubleshooting: VLAN Var Ama Trafik Neden Geçmiyor?

1 hafta önce

Cisco 802.1X + ISE: Access Layer’da Kimlik Tabanlı Erişim Kontrolü

2 hafta önce

Bir router aynı prefix için iki, üç hatta çok daha fazla BGP rotası öğrenebilir.

Ancak kritik soru şudur:

BGP neden bir path’i diğerlerinden daha iyi olarak seçti?

Troubleshooting sırasında yalnızca AS_PATH’e bakmak çoğu zaman yeterli değildir. Çünkü Cisco BGP best-path algoritması rotaları belirli bir öncelik sırasına göre karşılaştırır.

Örneğin daha kısa AS_PATH’e sahip bir rota bulunmasına rağmen diğer rota seçilmişse sebep daha önce değerlendirilen Weight veya Local Preference olabilir.

Bu nedenle BGP troubleshooting sırasında yapılması gereken ilk iş policy değiştirmek değil, aynı prefix için mevcut bütün path’leri karşılaştırmaktır.

BGP Best Path Selection nedir?

BGP, aynı destination prefix için birden fazla geçerli route öğrenebilen bir path-vector routing protokolüdür.

Cisco implementasyonunda BGP geçerli path’leri sırayla karşılaştırarak bir best path belirler. Seçilen yol BGP routing table içerisinde best olarak işaretlenir ve gerekli koşullar sağlandığında routing table’a kurulabilir.

Ancak burada önemli bir ayrım vardır:

BGP best path ile router’ın nihai forwarding kararı tamamen aynı kavram değildir.

Route’un routing table’a kurulabilmesi için next-hop erişilebilirliği gibi koşulların sağlanması gerekir. Ayrıca başka routing protokolleri ve administrative distance da nihai RIB kararını etkileyebilir. BGP multipath yapılandırılmışsa birden fazla eşdeğer BGP path’i de routing/forwarding tablolarına kurulabilir. Cisco’nun güncel dokümantasyonu best-path seçimini ayrı, multipath değerlendirmesini ise sonraki aşama olarak ele alıyor. Cisco

Cisco BGP Best Path Selection sıralaması

Standart bir Cisco BGP troubleshooting yaklaşımında temel sıra şu şekilde düşünülebilir:

Öncelik	Kriter	Tercih
1	Weight	En yüksek
2	Local Preference	En yüksek
3	Locally Originated	Yerel route
4	AS_PATH	En kısa
5	Origin	IGP → EGP → Incomplete
6	MED	En düşük
7	eBGP / iBGP	eBGP
8	IGP metric to next-hop	En düşük
9	eBGP path age	Daha eski path
10	Router ID	En düşük
11	Cluster List	En kısa
12	Neighbor Address	En düşük

Bu sıra bir ezberden çok troubleshooting metodolojisi olarak görülmelidir. Özellikle AIGP, cost community, confederation, multipath ve bazı platform/konfigürasyon seçenekleri algoritmanın davranışını değiştirebilir. Cisco’nun güncel IOS XR dokümantasyonu da gelişmiş kriterlerin devreye girebildiğini açıkça belirtiyor. Cisco

---

1. Weight: Cisco’nun yerel BGP tercihi

Cisco BGP best-path algoritmasında ilk önemli kriter Weight değeridir.

Yüksek Weight kazanır.

Örneğin:

router bgp 65000
 neighbor 10.10.10.2 weight 500

Aynı prefix iki farklı BGP peer’dan öğreniliyorsa ve bir path’in Weight değeri daha yüksekse, sonraki kriterlere bakılmadan bu path tercih edilebilir.

Weight’in en önemli özelliği Cisco’ya özgü olması ve yalnızca üzerinde yapılandırıldığı router için anlam taşımasıdır. Neighbor’lara BGP attribute olarak aktarılmaz. Cisco’nun best-path dokümantasyonu da Weight’i ilk karşılaştırılan kriter olarak tanımlar. Cisco

Bu nedenle tek bir edge router üzerinde belirli ISP’yi tercih ettirmek istiyorsanız Weight etkili olabilir.

Ancak AS genelinde tutarlı bir outbound routing policy oluşturmak istiyorsanız genellikle Local Preference daha uygun bir araçtır.

2. Local Preference: AS genelinde outbound path seçimi

Weight değerleri eşitse bir sonraki önemli kriter LOCAL_PREF değeridir.

Burada da:

Yüksek Local Preference kazanır.

Örneğin ISP-A üzerinden öğrenilen rotaları daha tercih edilir hale getirmek için:

route-map ISP_A permit 10
 set local-preference 200

kullanılabilir.

Cisco’da varsayılan Local Preference değeri normal şartlarda 100 olarak değerlendirilir. LOCAL_PREF aynı AS içerisindeki iBGP peer’lara aktarılır ve bu nedenle AS genelindeki outbound path seçiminde oldukça güçlü bir policy aracıdır. Cisco

Örneğin:

ISP-A → Local Preference 200
ISP-B → Local Preference 100

ise diğer yüksek öncelikli kriterler eşit olduğunda trafik ISP-A üzerinden çıkmayı tercih eder.

BGP troubleshooting sırasında:

“AS_PATH daha kısa ama neden diğer ISP seçiliyor?”

sorusunun cevabı oldukça sık Local Preference’tır.

3. Locally Originated Route

Weight ve Local Preference eşitse Cisco, router üzerinde lokal olarak originate edilen BGP path’lerini değerlendirebilir.

Örneğin:

router bgp 65000
 network 10.20.0.0 mask 255.255.0.0

ile originate edilen bir prefix bu kapsama girebilir.

Cisco’nun best-path algoritmasına göre network, redistribution veya aggregate mekanizmalarıyla lokal oluşturulan BGP yolları peer’lardan öğrenilen yollar karşısında avantaj elde edebilir. Ayrıca Cisco’nun klasik algoritmasında network veya redistribution ile oluşan local path’ler, aggregate-address ile oluşturulan local aggregate’a göre kendi aralarında da tercih edilebilir. Cisco

Burada network komutunun route’u sıfırdan yaratmadığını da unutmamak gerekir. İlgili prefix’in uygun şekilde routing table’da bulunması gerekir.

4. AS_PATH: Daha kısa her zaman önce gelmez

BGP ile en çok ilişkilendirilen attribute muhtemelen AS_PATH‘tir.

Genel kural:

Daha kısa AS_PATH tercih edilir.

Örneğin:

ISP-A → 65010 65020
ISP-B → 65030 65040 65050

önceki best-path kriterleri eşitse ISP-A üzerinden gelen path daha avantajlıdır.

Ancak kritik nokta şudur:

BGP ilk olarak AS_PATH’e bakmaz.

Örneğin:

ISP-A
Local Preference: 200
AS_PATH: 65010 65020 65030

ISP-B
Local Preference: 100
AS_PATH: 65040

durumunda ISP-B’nin AS_PATH’i çok daha kısa olmasına rağmen Local Preference daha önce değerlendirildiğinden ISP-A seçilebilir.

İşte bu nedenle BGP troubleshooting sırasında yalnızca AS_PATH uzunluğuna bakmak yanıltıcıdır. Cisco’nun algoritmasında AS_PATH, Weight, Local Preference ve local origination kontrollerinden sonra değerlendirilir. Cisco

AS_PATH karşılaştırması ayrıca bgp bestpath as-path ignore gibi yapılandırmalarla değiştirilebilir.

5. Origin Attribute: IGP, EGP ve Incomplete

AS_PATH uzunlukları da eşitse Origin attribute değerlendirilir.

Tercih sırası:

IGP (i) → EGP (e) → Incomplete (?)

Buradaki IGP ifadesinin OSPF veya EIGRP ile karıştırılmaması gerekir.

BGP Origin attribute içerisindeki i, prefix’in BGP’ye örneğin network mekanizmasıyla originate edildiğini ifade eder.

? yani Incomplete ise redistribution ile BGP’ye alınan prefix’lerde sıklıkla görülür.

Örneğin BGP çıktısında:

*> 10.20.0.0/16   192.0.2.1   0   65010 65020 i
*  10.20.0.0/16   192.0.2.2   0   65030 65040 ?

gibi bir görünümle karşılaşabilirsiniz.

Önceki kriterler eşitse i origin code’a sahip path tercih edilir. Cisco da sıralamayı IGP, EGP ve Incomplete olarak tanımlar. Cisco

6. MED: En çok yanlış yorumlanan BGP attribute’larından biri

Multi-Exit Discriminator — MED, bir AS’in komşu AS’e kendisine hangi giriş noktasından ulaşılmasını tercih ettiğine ilişkin bir sinyal vermesine yardımcı olur.

Burada kural tersine döner:

Düşük MED kazanır.

Örneğin:

route-map MED_POLICY permit 10
 set metric 50

ile ilgili BGP announcement’lara MED değeri atanabilir.

Ancak önemli bir ayrıntı vardır.

Cisco BGP varsayılan davranışında MED genellikle aynı komşu AS’ten gelen path’ler arasında karşılaştırılır. Farklı neighboring AS’lerden gelen path’lerin MED değerlerinin doğrudan karşılaştırılması varsayılan davranış değildir. bgp always-compare-med bu davranışı değiştirebilir. Cisco

Örneğin:

ISP-A – AS 65010 → MED 50
ISP-B – AS 65020 → MED 100

gördüğünüzde:

“50 daha düşük, dolayısıyla ISP-A kesin kazanır.”

demek doğru değildir.

Çünkü iki path farklı komşu AS’lerden geliyorsa varsayılan MED comparison kuralları devreye girer.

Bu ayrıntı production troubleshooting sırasında son derece önemlidir.

7. eBGP mi iBGP mi?

Önceki kriterler eşitse Cisco:

eBGP path’i iBGP path’e tercih eder.

Örneğin aynı prefix hem doğrudan external BGP neighbor’dan hem de internal BGP peer üzerinden öğreniliyorsa, önceki değerlerin eşit olması durumunda eBGP route avantajlıdır. Cisco

Fakat best-path algoritması burada bitmez.

8. IGP Metric to BGP Next-Hop

Bir sonraki önemli kriter, BGP next-hop’a ulaşmak için kullanılan IGP metric değeridir.

Diğer kriterler eşitse router BGP next-hop’a daha düşük internal cost ile ulaşabildiği path’i tercih eder. Cisco’nun güncel path-selection dokümantasyonu bunu eBGP/iBGP karşılaştırmasından sonraki temel kriterlerden biri olarak gösteriyor. Cisco

Bu nokta BGP ile IGP arasındaki ilişkinin neden kritik olduğunu gösterir.

BGP route görünse bile:

Next Hop: 192.0.2.10

adresine routing table üzerinden erişilemiyorsa route geçerli best-path adayı olmayabilir.

Cisco da BGP FAQ dokümantasyonunda iBGP’nin eBGP’den öğrenilen next-hop’u normalde koruduğunu ve next-hop’un internal routing üzerinden erişilebilir olması gerektiğini özellikle belirtiyor. Cisco

Bu nedenle bazen sorun BGP policy’de değil:

next-hop reachability tarafındadır.

BGP Best Path Selection burada bitiyor mu?

Hayır.

Yukarıdaki değerler de eşitse Cisco ilave tie-break mekanizmalarına devam eder.

Tipik olarak external path’lerde daha eski rota, ardından daha düşük BGP Router ID, route reflector mimarisinde daha kısa Cluster List ve son olarak daha düşük neighbor IP address gibi kriterler devreye girebilir. Cisco

Dolayısıyla pratik kısa özet:

Weight → Local Preference → Local Origin → AS_PATH → Origin → MED → eBGP/iBGP → IGP Cost → Tie-break kriterleri

şeklinde kullanılabilir.

Ama production ortamında bu sırayı körü körüne ezberlemek yerine show çıktısındaki gerçek attribute’ları karşılaştırmak daha güvenlidir.

BGP Troubleshooting: Nereye Bakmalıyım?

Benim yaklaşımımda policy değiştirmeden önce ilgili prefix için mevcut bütün BGP path’lerini görmek gerekir.

Cisco IOS / IOS XE üzerinde temel başlangıç komutları:

show ip bgp 10.20.0.0
show ip bgp neighbors
show ip route 10.20.0.0
show ip cef 10.20.0.0

IOS XE üzerinde prefix ve platforma bağlı olarak şu formatlar da kullanılabilir:

show bgp ipv4 unicast 10.20.0.0/16
show bgp ipv4 unicast neighbors

Cisco IOS XE dokümantasyonunda show ip bgp <network> komutu BGP routing table’daki prefix ve Local Preference gibi attribute’ları incelemek için kullanılan temel doğrulama yöntemlerinden biri olarak gösteriliyor. Cisco

show ip bgp <prefix> çıktısında neye bakmalıyız?

Örneğin:

Router# show ip bgp 10.20.0.0

BGP routing table entry for 10.20.0.0/16
Paths: (2 available, best #1)

  65010 65020
    192.0.2.1 from 192.0.2.1
      Origin IGP, localpref 200, valid, external, best

  65030
    198.51.100.1 from 198.51.100.1
      Origin IGP, localpref 100, valid, external

İkinci path’in AS_PATH’i daha kısa.

Ancak birinci route’un Local Preference değeri 200, diğerinin ise 100.

Dolayısıyla:

65030

daha kısa AS_PATH olmasına rağmen kazanamaz.

Best path:

65010 65020

olur.

İşte BGP troubleshooting’in özü budur:

İlk farklı attribute’u bul.

Çünkü algoritmada daha erken değerlendirilen kriter eşit değilse sonraki kriterlerin sonucu değiştirme şansı kalmaz.

BGP Sorunu Her Zaman BGP Değildir

Bir prefix beklenmeyen yoldan gidiyorsa hemen route-map değiştirmek doğru yaklaşım değildir.

Sorun Local Preference, Weight, AS-PATH prepend, MED veya next-hop reachability kaynaklı olabilir. Aynı şekilde prefix-list, route-map, neighbor policy, redistribution ve routing table içerisinde başka bir protokolün Administrative Distance avantajı da kontrol edilmelidir.

Örneğin:

show ip bgp 10.20.0.0

size BGP’nin hangi yolu best seçtiğini gösterebilir.

Ama:

show ip route 10.20.0.0

BGP route’un gerçekten RIB’e kurulup kurulmadığını anlamak için gereklidir.

Son olarak:

show ip cef 10.20.0.0

forwarding plane’in trafiği gerçekte nereye göndereceğini doğrulamanıza yardımcı olur.

Bu üç katmanı birbirinden ayırmak gerekir:

BGP → RIB → FIB

Troubleshooting açısından yalnızca BGP table’a bakmak bu nedenle yeterli değildir.

AS-PATH Prepend neden bazen işe yaramaz?

Sık karşılaşılan senaryolardan biri de şudur:

AS-PATH prepend yapılmıştır ama trafik hâlâ beklenen ISP üzerinden gitmemektedir.

Örneğin:

ISP-A → 65000 65000 65000
ISP-B → 65000

görünümüne bakarak ISP-B’nin kesin tercih edileceğini düşünmek hatalı olabilir.

Remote AS üzerinde daha yüksek Local Preference uygulanıyorsa AS_PATH karşılaştırmasına hiç gelinmeyebilir.

BGP policy tasarımının önemli prensibi burada ortaya çıkar:

Bir attribute’un etkisini değerlendirirken best-path algoritmasındaki konumunu bilmek gerekir.

Local Preference ile MED arasındaki fark nedir?

Bu iki attribute sıkça karıştırılır.

Local Preference, kendi AS’inizin hangi outbound path’i tercih edeceğini belirlemek için güçlü bir mekanizmadır ve yüksek değer tercih edilir.

MED ise tipik olarak komşu AS’e kendi AS’inize hangi giriş noktasını tercih etmesini istediğiniz konusunda sinyal verir ve düşük değer tercih edilir.

Dolayısıyla basitleştirilmiş olarak:

Local Preference → Ben hangi çıkışı kullanacağım?

MED → Komşum bana hangi girişten gelsin?

şeklinde düşünülebilir.

Ancak gerçek trafik mühendisliğinde karşı tarafın policy’sinin her zaman sizin MED değerinizi dikkate almak zorunda olmadığını unutmamak gerekir.

BGP Best Path troubleshooting için en önemli prensip

Bir route’un neden seçildiğini anlamaya çalışırken doğrudan configuration değiştirmek yerine önce seçim kararını açıklayabilmek gerekir.

Önünüzde iki BGP path varsa şu soruya cevap verebilmelisiniz:

Algoritmadaki ilk farklı değer hangisi?

Eğer cevap Local Preference ise AS_PATH’i değiştirmek problemi çözmeyebilir.

Eğer next-hop erişilemiyorsa MED üzerinde çalışmanın anlamı yoktur.

Eğer route-map beklediğiniz policy’yi uygulamıyorsa BGP algoritması aslında kendisine verilen değerlerle tamamen doğru çalışıyor olabilir.

Bu nedenle production network ortamlarında en güvenli yaklaşım:

Önce gözlemle → attribute’ları karşılaştır → policy’yi doğrula → sonra değişiklik yap.

Kısa Özet

Cisco BGP best-path selection için temel hatırlama sırası:

Weight → Local Preference → Locally Originated → AS_PATH → Origin → MED → eBGP/iBGP → IGP Metric → Tie-break

Fakat üç kritik ayrıntıyı unutmamak gerekir:

Weight yüksek, Local Preference yüksek, MED düşük tercih edilir.

MED varsayılan olarak her farklı AS’ten gelen route arasında karşılaştırılmaz.

Ve BGP table’daki best route’u görmek, tek başına forwarding plane’in beklediğiniz gibi çalıştığını kanıtlamaz.

RFC 4271, BGP karar sürecini route’ların local kullanım ve advertisement için seçildiği kavramsal bir decision process olarak tanımlar; vendor implementasyonları ise bunun üzerine kendi policy ve tie-break mekanizmalarını ekleyebilir. RFC Editor

---

Sık Sorulan Sorular

Cisco BGP’de en önemli best-path kriteri nedir?

Standart Cisco algoritmasında geçerli path’ler arasında en yüksek Weight ilk temel seçim kriteridir. Weight eşitse Local Preference değerlendirilir. Cisco

BGP’de yüksek mi düşük Local Preference mı tercih edilir?

Yüksek Local Preference tercih edilir. Cisco’da normal varsayılan değer 100’dür. Cisco

Daha kısa AS_PATH her zaman kazanır mı?

Hayır. Weight, Local Preference ve locally originated gibi daha yüksek öncelikli kriterler önce değerlendirilir.

BGP’de düşük MED mi tercih edilir?

Evet. Ancak varsayılan Cisco davranışında MED esas olarak aynı neighboring AS’ten gelen path’ler arasında karşılaştırılır. bgp always-compare-med bu davranışı değiştirebilir. Cisco

eBGP mi iBGP mi tercih edilir?

Önceki best-path kriterleri eşitse eBGP üzerinden öğrenilen path iBGP path’e tercih edilir. Cisco Security Cloud

BGP route görünüyor ama routing table’da neden yok?

Next-hop erişilemez olabilir, başka bir route daha avantajlı Administrative Distance’a sahip olabilir veya route RIB/FIB’e kurulmasını engelleyen başka bir durum olabilir. Bu nedenle BGP, RIB ve CEF çıktıları birlikte incelenmelidir.