Cem Kemal Erbaş Network, Siber Güvenlik ve Teknik Rehberler
Uygulama performansı çoğu zaman network path kalitesine bağlıdır. Tek bir default-route’a güvenmek; packet loss / latency / jitter anlarında uygulamayı doğrudan degradasyona iter. IP SLA (veya BFD) ile path sağlığını ölçüp, PBR (Policy-Based Routing) ile sadece kritik uygulama trafiğini izole ederek hızlı ve deterministik failover kurgulayabilirsiniz.
Aşağıdaki örnek; “sadece 443 uygulaması” için, primary path bozulduğunda trafiği otomatik backup’a aktaran saha pratiklerine uygun bir taslaktır.
1) Senaryo
- Uygulama Sunucusu:
10.100.10.10(TCP/443) - Primary next-hop:
192.0.2.1(internet1) - Backup next-hop:
198.51.100.1(internet2) - Hedef: Primary path kalite eşiğini aşınca (örn. RTT > 80ms veya loss > %2) anında sadece bu uygulama trafiğini backup’a taşımak
Not: “RTT/loss eşikleri” vendor/platforma göre farklı uygulanır. En sık kullanılan, reachability (erişilebilirlik) temelli track ile deterministik failover’dır; kalite eşiği gerekiyorsa IP SLA “reaction”/threshold yetenekleri veya SD-WAN yaklaşımı daha temiz olur.
2) Adım Adım Konfigürasyon (Konsept – Cisco IOS örneği)
A) IP SLA oluştur (ICMP veya TCP)
Seçenek 1 — ICMP Echo (basit başlangıç):
ip sla 10
icmp-echo 10.100.10.10 source-interface Loopback0
frequency 10
ip sla schedule 10 life forever start-time now
Seçenek 2 — TCP Connect (kritik uygulamalar için önerilir):
ip sla 10
tcp-connect 10.100.10.10 443 source-interface Loopback0
frequency 10
ip sla schedule 10 life forever start-time now
ICMP bazı ortamlarda rate-limit / policy nedeniyle yanıltıcı olabilir. Gerçek uygulama sağlığı için TCP connect daha gerçekçidir.
B) Track objesi ile SLA sonucunu izle
track 10 ip sla 10 reachability
- track 10 = UP → path OK
- track 10 = DOWN → path problemli → backup’a geç
C) Uygulama trafiğini tanımla (ACL)
ip access-list extended APP_TRAFFIC
permit tcp any host 10.100.10.10 eq 443
İsterseniz kaynak subnet’i daraltın (örn. sadece belirli kullanıcı VLAN’ları) → yanlış yönlendirme riski düşer.
D) PBR route-map: primary “track’e bağlı”, olmazsa backup
route-map PBR_APP permit 10
match ip address APP_TRAFFIC
set ip next-hop verify-availability 192.0.2.1 10 track 10
!
route-map PBR_APP permit 20
match ip address APP_TRAFFIC
set ip next-hop 198.51.100.1
Mantık:
- Track UP ise →
192.0.2.1 - Track DOWN ise → bir sonraki kural devreye girer →
198.51.100.1
E) Route-map’i inbound interface’e uygula
interface GigabitEthernet0/1
ip policy route-map PBR_APP
PBR’nin “inbound” çalıştığını unutmayın: Trafiğin router’a girdiği interface’e uygulanır.
3) Doğrulama Komutları
show ip sla statistics 10
show track 10
show route-map PBR_APP
show ip policy interface GigabitEthernet0/1
show ip cef 10.100.10.10 exact-route
Ek doğrulama:
- SPAN/tcpdump/NetFlow ile 443 trafiğinin hangi next-hop’a gittiğini teyit edin.
- Failover sırasında “session reset” olup olmadığını uygulama loglarından kontrol edin.
4) Operasyonel İpuçları ve Sınırlar
✅ SLA tipi seçimi
- ICMP: hızlı kurulur ama yanıltıcı olabilir
- TCP connect: uygulamaya daha yakın doğrulama sağlar
✅ Frequency / timer ayarı
- 5–10s başlangıç için idealdir
- Çok agresif (1s) ayarlar kontrol trafiğini ve CPU yükünü artırabilir
✅ PBR performansı
- Donanım (hardware forwarding) destekliyse sorunsuz
- Yazılım tabanlı PBR yüksek trafikte CPU’yu yorabilir → datasheet/feature set kontrolü şart
✅ Stateful uygulamalar
- Path değişimi bazı oturumlarda reset yaratabilir
- “Stickiness” gerekiyorsa: LB/ADC tarafında çözüm veya SD-WAN policy daha uygun olabilir
✅ Ölçek konusu
- Çok sayıda uygulama için IP SLA + PBR yönetimi karmaşıklaşır
- Bu noktada SD-WAN / merkezi policy engine daha sürdürülebilir olur
Cem Kemal Erbaş sitesinden daha fazla şey keşfedin
Subscribe to get the latest posts sent to your email.
