Cisco 300-415: Veri Düzlemi Tünelleri, BFD ve Uygulama Farkındalıklı Yönlendirme — Çalışma kılavuzu

By Laurynas Brazys · 13 August 2026 · #cisco #300-415 #certification #exam-prep #study-guide

Şunun bir parçası: Cisco SD-WAN 300-415 ENSDWI — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Cisco sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Genel Bakış

Cisco SD-WAN, kontrol düzlemini veri düzleminden ayırır ve farklı taşıma ortamları üzerinde şifreli, ilke tabanlı bir overlay (yer paylaşımı) oluşturur. vSmart denetleyicisi, overlay kontrol düzlemini ve WAN Edge bağlantısını yönetir; OMP aracılığıyla rotaları, güvenlik anahtarlarını ve amaçları (intent) dağıtır. WAN Edge yönlendiricileri, diğer WAN Edge’lere güvenli IPsec veri düzlemi tünelleri oluştururken vSmart, vBond ve vManage’e olan kontrol bağlantıları varsayılan olarak DTLS (veya TLS) kullanır. Yolun (path) canlılığı ve kalitesi BFD ile sürekli olarak ölçülür; bu ölçümler, uygulamaları kayıp, gecikme, jitter veya MOS’a dayalı SLA sınıflarına göre en iyi performans gösteren tünellere yönlendirmek için Application-Aware Routing (AAR) ilkelerini besler.

Overlay ve Veri Düzlemi Temelleri

• Kontrol düzlemi ve veri düzlemi karşılaştırması

  • Kontrol düzlemi: WAN Edge’ler, vBond (NAT geçişi ve orkestrasyon için), vSmart (OMP aracılığıyla ilke ve rota değişimi için) ve vManage’e (yönetim, cihaz yapılandırması ve sertifika depolama için) güvenli DTLS/TLS kontrol bağlantıları kurar. Staging (hazırlık) durumunda, cihazlar kontrol bağlantıları kurar ancak veri tünelleri oluşturmaz.
  • Veri düzlemi: WAN Edge’ler, kullanıcı trafiği için doğrudan diğer WAN Edge’lere IPsec tünelleri oluşturur. Veri düzlemi, iletimden sorumludur ve kontrol düzlemi ilkesi aracılığıyla iletilen trafik mühendisliği kararlarını uygular.

• IPsec veri düzlemi tünelleri ve TLOC’lar

  • Bir Transport Locator (TLOC), bir WAN taşıma bağlantısını benzersiz bir şekilde tanımlar ve {sistem-IP’si, renk, kapsülleme} üçlüsüyle tanımlanır. Kapsülleme IPsec veya GRE’dir; çoğu dağıtımda ve IOS XE SD-WAN (cEdge) üzerinde IPsec kullanılır.
  • Renkler (color), underlay (altyapı) türleri ve NAT özellikleri için anlamsal etiketlerdir (örneğin, mpls, biz-internet, public-internet, lte, private1–private6). Public (genel) renkler genellikle vBond yardımıyla NAT geçişi anlamına gelir.
  • Tüneller, kısıtlanmadığı sürece her erişilebilir TLOC çifti arasında oluşturulur. Her birinde bir WAN Edge ve iki public TLOC bulunan iki site ve hiçbir restrict (kısıtlama) niteliği olmadığında, dört IPsec tüneli oluşur (renk çiftleri arasında tam ağ - full mesh).
  • TLOC uzantısı (extension), bir sitedeki iki yedekli WAN Edge’in bir çapraz bağlantı (cross-link) aracılığıyla taşıma ortamlarını paylaşmasına olanak tanır ve bu da şasi başına fiziksel devreleri çoğaltmadan taşıma yedekliliği sağlar.

• Taşıma ve hizmet etiketleri

  • vSmart, rotaları ve TLOC’ları duyurmak ve overlay başlığında taşınan etiketleri tahsis etmek için OMP’yi kullanır. Taşıma etiketleri, overlay üzerindeki trafiği ayırmak (demultiplexing) için uzak TLOC’ları tanımlar. Hizmet etiketleri, hedef hizmet VPN’ini veya zincirlenmiş hizmeti (chained service) tanımlar. Bu etiketler SD-WAN overlay’ine özeldir ve MPLS underlay etiketleri değildir.

• Operasyonel ödünler ve arıza modları

  • Yanlış renklendirilmiş taşıma ortamları (örneğin, MPLS’i public-internet olarak işaretlemek) suboptimal tünel oluşumuna veya NAT geçişi arızalarına neden olabilir.
  • Restrict niteliği, istenmeyen tam ağ (full-mesh) büyümesini önler; internet renklerinde bu niteliğin atlanması, aşırı tünel ölçeğine ve gereksiz yoklama (probing) ek yüküne yol açabilir.
  • Sertifika veya saat sorunları, kontrol düzlemi bağlantısını (DTLS/TLS) engeller. vSmart ile kontrol düzlemi yakınsaması olmadan, hiçbir veri düzlemi anahtarı değiş tokuş edilmez ve IPsec tünelleri oluşmaz.

BFD Yol Canlılığı ve Kalite Ölçümü

• BFD operasyonu

  • Cisco SD-WAN, neredeyse gerçek zamanlı canlılık tespiti ve kalite ölçümü sağlamak için her veri düzlemi tünelinde BFD çalıştırır. BFD, up/down durumunu (blackout’lar - tam kesintiler) tespit etmek için hafif periyodik hello paketleri ve gecikme, jitter ve kaybı (brownout’lar - kısmi kesintiler) ölçmek için aktif problar kullanır.
  • Temel zamanlayıcılar ve aralıklar
    • Hello aralığı: genellikle 1000 ms (renk başına veya genel olarak yapılandırılabilir).
    • Çarpan (Multiplier): genellikle 6 (yapılandırılabilir), bu da hello-aralığı × çarpan kadar bir tespit süresi sağlar (örneğin, ~6 saniye).
    • AAR performans örneklemesi için uygulama probu (App-probe) aralığı: tipik olarak 1 saniye (yapılandırılabilir), geçici ani yükselmeleri yumuşatmak için kısa bir pencere üzerinde yuvarlanan ortalamalar hesaplanır.
  • BFD ölçümleri
    • Gecikme (Latency): her tüneldeki probların gidiş-dönüş süresi.
    • Jitter: problar arası gecikmedeki değişkenlik.
    • Kayıp (Loss): geri dönmeyen probların yüzdesi.
    • MOS: ses uygunluğu için gecikme, jitter ve kayıptan türetilir.

• Brownout ve blackout yönetimi karşılaştırması

  • Blackout (Tam Kesinti): BFD oturumunun kapanması (bağlantı yok), yolun iletimden derhal kaldırılmasını tetikler. Trafik, AAR değerlendirmesini beklemeden bir sonraki mevcut tünel tercihine göre kaydırılır.
  • Brownout (Kısmi Kesinti): BFD ayakta kalır, ancak ölçülen metrikler SLA eşiklerini ihlal eder. AAR, orijinal tünel diğer trafiği taşımaya devam ederken bile belirli uygulama akışlarını SLA’ları karşılayan alternatif tünellere yönlendirebilir.

• Tasarım rehberi ve ödünler

  • Agresif zamanlayıcılar yük devretmeyi (failover) hızlandırır ancak özellikle büyük ağlarda (mesh) CPU ve bant genişliği ek yükünü artırır. Hello ve prob aralıklarını, ölçek ve taşıma ortamı kararlılığına göre dengeleyin.
  • Asimetrik yol özellikleri (örneğin, uydu veya hücresel), kararsızlığı (flapping) önlemek için daha esnek SLA eşikleri ve potansiyel olarak daha yüksek çarpanlar gerektirir.
  • Ses ve etkileşimli uygulamalar için, geçici tıkanıklık sırasında salınımı (oscillation) azaltmak amacıyla daha hızlı uygulama probu (app-probe) aralıklarını ve histerezis/bekletme (hysteresis/hold-down) mekanizmalarını etkinleştirmeyi tercih edin.

Uygulama Farkındalıklı Yönlendirme (Application-Aware Routing): Politika ve SLA Tasarımı

• Uygulama tanımlama ve sınıflandırma

  • WAN Edge’ler, uygulamaları imzalar, protokol sezgileri ve mevcut olduğunda TLS SNI ve QUIC ALPN gibi üst verilerle sınıflandırmak için DPI (IOS XE SD-WAN üzerinde NBAR2) kullanır. Tanımlanabilir üst verisi olmayan şifreli trafik için motor, akış niteliklerine (5’li demet) ve yapılandırılmış eşlemelere (portlar, DSCP) geri döner.
  • Sınıflandırma genellikle ilk paketler üzerinde gerçekleşir ve oturum tutarlılığı için önbelleğe alınır. Doğruluğu korumak için imzaları güncel tutun.

• SLA sınıfları ve ölçüm politikası

  • Kayıp, gecikme, jitter ve isteğe bağlı olarak MOS için eşik değerleri içeren SLA sınıfları tanımlayın. Her SLA sınıfı, BFD’nin örnekleme aralığını ve yumuşatma davranışını yönlendiren bir performans denetimi profiline (app-probe) referans verir.
  • Tipik SLA örnekleri:
    • Ses: gecikme ≤ 150 ms, jitter ≤ 30 ms, kayıp ≤ %1, MOS ≥ 4.0.
    • İşlemsel: gecikme ≤ 200 ms, kayıp ≤ %1.
    • Toplu: katı bir SLA yoktur; daha yüksek bant genişliğine sahip, daha düşük maliyetli yolları tercih edin.

• Yol tercihi davranışı

  • AAR politikası, uygulama listelerini SLA sınıflarına bağlar ve tercih edilen rengi (preferred-color) ve yedek rengi (backup-color) (veya TLOC listelerini) belirtir. Karar mantığı:
    1. Tercih edilen yol SLA’yı karşılıyorsa, trafiği tercih edilen yola gönderin.
    2. Tercih edilen yol SLA’yı ihlal ediyor ancak yedek yol karşılıyorsa, trafiği yedek yola yönlendirin.
    3. Hiçbir yol SLA’yı karşılamıyorsa, tercihe veya maliyete göre mevcut en iyi yolu kullanın (kademeli olarak performansı düşürün).
  • Kısmi kesinti (brownout) yönlendirmesi akış bazındadır; mevcut akışlar politikaya bağlı olarak taşınabilir (yeni akış yönlendirmesi varsayılandır; oturum esnekliği tasarlanmadıkça TCP için akış ortasında taşıma kısıtlanabilir).

• Politika oluşturma unsurları

  • vManage’de uygulama listeleri (DPI grupları), SLA sınıfları (kayıp/gecikme/jitter/MOS) ve TLOC listeleri (renkler) oluşturun. Ardından, uygulama listesi → SLA sınıfı → tercih edilen/yedek renkler şeklinde bir AAR politika dizisi eşlemesi oluşturun.
  • AAR kararlarından önce DSCP ayarlamanız, bölgeleri zorunlu kılmanız veya hizmet zincirlemesi (service chaining) eklemeniz gerekiyorsa, trafik veri politikalarıyla birleştirin.
  • Rota kabulünü/duyurusunu etkilemek için kontrol politikasını (control-policy) ayrı olarak kullanın; AAR’ı (veri politikası) kontrol politikasıyla karıştırmayın. Site listeleri, AAR’ın nerede uygulanacağının kapsamını belirler.

• Tasarım ödünleşimleri

  • Aşırı katı SLA’lar salınıma (oscillation) neden olabilir. Sık yol değişimlerini önlemek için histerezis veya ceza zamanlayıcıları ekleyin.
  • Maliyeti göz önünde bulundurun: ölçümlü hücresel yolları yalnızca son çare yedekleri olarak konumlandırın; mevcut olan yerlerde veri kotalarını etkinleştirin.
  • QoS ile koordine edin: AAR yolu seçer; yol başına QoS ve kuyruklama, tıkanıklık sırasında kritik sınıfları korumaya devam etmelidir.

Doğrulama ve Sorun Giderme

• Hızlı durum kontrolleri

  • Kontrol düzlemi:
    • cEdge: show sdwan control connections
    • vEdge: show control connections
  • Veri düzlemi tünelleri:
    • cEdge: show sdwan tunnels
    • vEdge: show ipsec outbound-connections / show ipsec inbound-connections
  • BFD oturumları ve kalitesi:
    • cEdge: show sdwan bfd sessions; show sdwan app-route stats
    • vEdge: show bfd sessions; show app-route stats

• Örnek komut parçacıkları

  show sdwan tunnels
  show sdwan bfd sessions
  show sdwan app-route stats sla-class <name>
  show sdwan app-route statistics flows
  show sdwan omp tlocs

  show control connections
  show omp routes | include <prefix>
  show ipsec sa detail

• Nelere dikkat edilmeli

  • Tünel durumu ‘up’ (aktif) ancak BFD kaybı/gecikmesi/jitter’ı SLA’yı aşıyor: brownout (performans düşüşü)—AAR yönlendirmesi beklenir. Yedek yolun SLA’yı karşıladığını ve politikanın doğru uygulama listesini bağladığını doğrulayın.
  • BFD oturumunun flap etmesi (sürekli inip kalkması): agresifliği azaltın veya underlay (altyapı) ağındaki paket kayıplarını/kuyruklanmayı araştırın; prob (sonda) kaybını önlemek için MTU ve fragmantasyonu (DF-bit yönetimi) doğrulayın.
  • Bir color (renk) üzerinden tünel oluşmaması: color’ın NAT/public/private semantiğini, arayüz NAT yapılandırmasını ve vBond’un NAT traversal (NAT geçişi) için erişilebilir olduğunu doğrulayın. Kontrol bağlantıları yoksa zamanı ve sertifikaları onaylayın.
  • Beklenmedik full-mesh ve prob ölçeği: internet color’ları üzerinde ‘restrict’ (kısıtlama) uygulayın veya bağlantı kapsamını belirlemek için TLOC listeleri kullanın.
  • DPI’ın yanlış sınıflandırması: NBAR2 imzalarını güncelleyin ve çakışan L4 port geçersiz kılmalarının olmadığını onaylayın. Şifreli uygulamalar için SNI/ALPN tabanlı sınıflandırmayı veya upstream’de (kaynağa doğru) DSCP işaretlemesini değerlendirin.

• Operasyonel Mantık

  • Her zaman önce kontrol bağlantısını doğrulayın (orkestrasyon/NAT için vBond, OMP/politika için vSmart, yapılandırma/sertifikalar için vManage). vSmart olmadan veri düzlemi anahtarları dağıtılmaz ve IPsec SA (Güvenlik Birliği) oluşmaz.
  • AAR kararlarını BFD ölçümleri ve SLA sınıflarıyla ilişkilendirin. Bir yol beklentinin aksine seçilirse, sadece mevcut ortalamaları değil, karar anındaki SLA uyumluluk durumunu inceleyin.
  • Çift veri merkezi tasarımlarında, bir veri merkezi ara bağlantısı üzerinden OMP↔BGP arasında redistribution yaparken DC WAN Edge’lerindeki overlay AS’lerini uyumlu hale getirerek yinelenen LAN rotalarından kaçının.

Pratik Problem Senaryosu

Contoso Health, her bir lokasyonda çift taşıyıcıya sahip 300 klinik işletmektedir: MPLS (mpls color) ve geniş bant (biz-internet color). Veri uygulamaları sorunsuz çalışırken, kullanıcılar aralıklı olarak kötü ses kalitesi bildiriyor. Amaç, ses trafiği için MPLS’i tercih etmek, brownout’lar (performans düşüşleri) sırasında geniş banda yük devretmek ve salınım olmadan hızlı blackout (tam kesinti) yük devri sağlamaktır.

1. Overlay sağlığını ve veri düzlemi oluşumunu doğrulayın

• Gerekçe: Ön koşulları doğrulayın. vSmart/vBond/vManage’e olan DTLS/TLS bağlantısının stabil olduğundan emin olmak için show sdwan control connections komutunu ve tam MPLS ile geniş bant tünel mesh’ini doğrulamak için show sdwan tunnels komutunu kullanın. Eğer biz-internet üzerinden tüneller eksikse, color atamasını ve NAT’ı kontrol edin; vBond’un NAT geçişine yardımcı olmak için public alanda erişilebilir olması gerekir.

2. BFD ve prob zamanlayıcılarını kalibre edin

• Gerekçe: Dengeli canlılık tespeti (~6 sn) ve makul bir ölçek için BFD hello’yu 1000 ms, çarpanı 6 olarak ayarlayın. Zamanında brownout tespiti için app-probe aralığını 1 sn olarak yapılandırın. Aşırı agresif zamanlayıcılar CPU yüküne ve flap’lemeye neden olabilir; çok gevşek olması ise ses trafiği için yanıt verme hızını engeller.

3. SLA sınıflarını tanımlayın

• Gerekçe: Gecikme ≤ 150 ms, jitter ≤ 30 ms, kayıp ≤ %1, MOS ≥ 4.0 olan bir Voice-SLA sınıfı oluşturun. Gecikme ≤ 200 ms, kayıp ≤ %1 olan bir Data-SLA sınıfı oluşturun. Bu eşikler, ses trafiğinin hassasiyetini ve tipik WAN performansını yansıtır; MOS, metrikler genelinde kullanıcı deneyimini birleştirir.

4. Uygulama listeleri oluşturun

• Gerekçe: SIP/RTP/Teams/Zoom medyası için App-List-Voice ve işlemsel uygulamalar için App-List-Data’yı tanımlamak üzere DPI (NBAR2) kullanın. Modern ses/video platformları için TLS SNI/QUIC ALPN desenlerini dahil edin. Sınıflandırmanın belirsiz olduğu durumlarda, LAN ucunda zorunlu kılınan DSCP EF/AF41 işaretlemelerine geri dönün.

5. AAR politikası oluşturun

• Gerekçe: App-List-Voice’u, tercih edilen color olarak mpls ve yedek color olarak biz-internet ile Voice-SLA’ya eşleyin. MPLS bant genişliğini korumak için App-List-Data’yı, tercih edilen color olarak biz-internet ve yedek color olarak mpls ile Data-SLA’ya eşleyin. Bu, ses trafiğinin sağlıklı olduğunda MPLS’i kullanmasını ve yalnızca brownout veya blackout’lar sırasında geniş banda geçmesini sağlarken, verinin maliyet etkin interneti tercih etmesini temin eder.

6. Histerezis ve hold-down ekleyin

• Gerekçe: Ses trafiğinin MPLS’e yalnızca sürekli SLA uyumluluğundan sonra (örneğin 30–60 sn) geri dönmesi için bir geri dönüş zamanlayıcısı yapılandırın. Bu, geçici jitter artışları sırasında salınımı önler. Benzer şekilde, geniş bant kısa bir zaman aralığında tekrar tekrar SLA’yı ihlal ederse bir ceza veya sönümleme uygulayın.

7. QoS ve MTU’yu koordine edin

• Gerekçe: Her iki taşıyıcıda da EF kuyruklama ve şekillendirmenin (shaping) devre hızlarıyla uyumlu olduğundan emin olun. Uyumsuzluk, BFD probları ve ses RTP’si tarafından görülen jitter/kaybı artırabilir. Yol MTU’sunu doğrulayın ve fragmantasyonun kaçınılmaz olduğu yerlerde DF’yi devre dışı bırakarak kayıp gibi görünen prob düşmelerini önleyin.

8. Doğrulayın ve yineleyin

• Gerekçe: Tünel başına SLA geçme/kalma durumunu onaylamak için show sdwan app-route stats sla-class Voice-SLA komutunu kullanın. Ses trafiğinin MPLS’e yönlendirildiğini ve yalnızca MPLS SLA’yı ihlal ettiğinde geniş banda geçtiğini görmek için show sdwan app-route statistics flows ile canlı akışları gözlemleyin. Testler sırasında, brownout davranışını doğrulamak için MPLS’i kasıtlı olarak sıkıştırın, ardından geri dönüş zamanlamasını ölçün.

Bu adımları izleyerek Contoso Health, BFD’nin hızlı blackout tespiti sağladığından, AAR’ın hassas SLA sınıflarını kullanarak brownout’lara tepki verdiğinden ve DPI’ın ses uygulamalarını doğru bir şekilde sınıflandırdığından emin olur. Bu kombinasyon, SD-WAN fabric genelinde öngörülebilir ses kalitesi, taşıyıcıların verimli kullanımı ve kontrol edilebilir yük devretme davranışı sağlar.

← WAN Uç Yapılandırması ve Şablon Yönetimi · Tüm alanlar · Merkezi Politika ve Trafik Mühendisliği →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →