Cisco 300-415: Operasyonlar, İzleme ve Sorun Giderme — Ç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’de operasyonlar, izleme ve sorun giderme; Cisco SD-WAN Manager (eski adıyla vManage), denetleyici katmanı (vBond orchestrator ve vSmart denetleyicileri), WAN Edge yönlendiricileri (ör. IOS XE SD-WAN çalıştıran ISR 4000 ve ASR 1000 serisi) ve bunların oluşturduğu veri ve kontrol katmanları etrafında şekillenir. vSmart tarafından yönetilen kontrol düzlemi, OMP aracılığıyla topolojiyi ve politikayı oluşturup sürdürür ve uç noktalar arasında kripto anahtarlarını dağıtır. WAN Edge cihazları, varsayılan olarak DTLS (veya zorunluysa TLS) kontrol bağlantıları kurar, vBond aracılığıyla ilk bağlantıyı koordine eder (NAT geçişi için genel IP alanından erişilebilir olmalıdır) ve IPsec veri düzlemi tünelleri oluşturur. Güçlü operasyonel hijyen, SLA güvencesini sürdürmek ve ortalama onarım süresini azaltmak için zengin telemetri, sabit runbook’lar, değişiklik kontrolü ve otomatikleştirilmiş API’ler kullanır.

İzleme, Gösterge Panelleri ve Sağlık Durumu

• Gösterge Panelleri: Cisco SD-WAN Manager; site sağlığı, cihaz durumu, kontrol bağlantıları, tünel SLA’sı, uygulama deneyimi ve politika uyumluluğu hakkında gerçek zamanlı ve geçmişe dönük görünümler sunar. Varsayılan widget’lar; kontrol bağlantılarını (vBond/vSmart/vManage erişilebilirliği), uygulamaya duyarlı yönlendirme (app-aware routing) SLA uyumunu ve arayüz kullanımını vurgular. Detaylı incelemeler (drill-down), cihaz veya site başına alarmları, olayları ve istatistikleri ilişkilendirir.
• Alarmlar ve olaylar: Platform; denetleyici erişilebilirlik değişiklikleri, OMP oturum durumu, sertifika hataları, cihaz yeniden başlatmaları, politika uyuşmazlıkları ve performans düşüşü (SLA’yı aşan kayıp/gecikme/jitter) durumlarında alarmlar üretir. Olaylar, kontrol bağlantısı hataları için DCONFAIL gibi ayrıntılı kodları ve katılım (onboarding) sırasında açık organizasyon adı uyuşmazlıklarını içerir. Alarmlar, merkezi operasyon sistemlerine onaylama (acknowledgment), temizleme (clearance) ve iletmeyi (e-posta/SNMP/syslog) destekler.
• Cihaz sağlığı: Sağlık puanları, kontrol ve veri düzlemi göstergelerini CPU, bellek, çökme günlükleri (crash logs) ve arayüz hatalarıyla birleştirir. WAN Edge sağlığı için bir taban çizgisi (baseline) oluşturulmalı ve alarm yorgunluğunu önlemek için eşik değerleri ayarlanmalıdır. Zaman senkronizasyonu (NTP) kritiktir; saat kayması (clock skew), sertifika doğrulama hatalarının ve yanıltıcı eğilim verilerinin yaygın bir kök nedenidir.
• vAnalytics ve kapasite planlaması: vAnalytics; derinlemesine uygulama görünürlüğü (cflowd’dan NBAR2 tabanlı sınıflandırma), yol kalitesi taban çizgileri ve kapasite tahminleri ekler. En çok konuşanları (top talkers), uygulama yanıt süresi bileşenlerini (ağ ve sunucu karşılaştırması) ve öngörülen arayüz doygunluk pencerelerini vurgular. Kapasite planlaması için, 30 günlük periyotlar üzerinden 95. yüzdelik dilimdeki verim (throughput) değerini kullanın ve bunu tünel SLA ihlalleriyle ilişkilendirin; ek bant genişliğinin veya politika ayarlamalarının (QoS/AAR) nerede en iyi SLA getirisini sağladığını değerlendirin.
• Uygulama deneyimi: Uygulama gösterge panelleri, akışları (flows) tünel performansına ve QoS uygulamasına bağlar. Kritik bir uygulama, artan jitter’a sahip bir yolda düşük performans gösteriyorsa, uygulamaya duyarlı yönlendirmenin (app-aware routing) SLA’ya uyup uymadığını ve kuyruklama politikalarının uçtan uca DSCP işaretlemeleriyle uyumlu olduğunu doğrulayın.

Telemetri, Syslog, SNMP ve cflowd Dışa Aktarımı

• Akış telemetrisi (Streaming telemetry): Cisco SD-WAN Manager, kontrol, arayüz ve platform metrikleri için denetleyicilerden ve uç noktalardan model tabanlı telemetri (model-driven telemetry) verilerini alır. Akış, eski tip SNMP sorgulamasına (polling) kıyasla sorgulama yükünü azaltır ve ayrıntı düzeyini (granularity) artırır. Harici analitik için IOS XE SD-WAN, gRPC toplayıcılarına doğru dışa arama (dial-out) model tabanlı telemetriyi destekler; şubelerde ek yükten kaçınmak için toplayıcıları ve örnekleme oranlarını dikkatlice boyutlandırın.
• Syslog: Uç noktalar ve denetleyiciler, merkezi toplayıcılara syslog aktarabilir. Önemli olayları (ör. kontrol yeniden yakınsaması, OMP politika güncellemeleri, IPsec anahtar yenilemeleri, çökmeler) iletin. Daha iyi ayrıştırma (parsing) için yapılandırılmış syslog kullanın. Toplayıcıların performansını korumak için hız sınırlaması (rate-limit) ve filtreleme yapın.
• SNMP: Arayüzlerin, CPU’nun, belleğin ve ortam sensörlerinin güvenli bir şekilde sorgulanması için SNMPv3 kullanın. Önemli alarmlar (kontrol bağlantısı kesintisi, BFD kesintisi, yüksek CPU) için SNMP trap’leri etkinleştirilebilir. SNMP tek başına modern uygulama telemetrisi için yetersizdir ancak mevcut NMS araçlarıyla entegrasyon için değerini korur.
• cflowd (uygulamaya duyarlı akış dışa aktarımı): Cisco SD-WAN, uygulama kimliği (NBAR2), DSCP, bayt/paket sayısı, TCP bayrakları ve gidiş-dönüş süresi, kayıp ve jitter gibi performans meta verilerini içeren akış başına kayıtları dışa aktarmak için cflowd (NetFlow/IPFIX benzeri) kullanır. Dışa aktarım, Cisco SD-WAN Manager/vAnalytics’e ve harici toplayıcılara yönlendirilebilir. Örnekleme, aktif/inaktif zaman aşımları ve dışa aktarım hedeflerini ayarlayarak görünürlük ve ek yük arasında bir denge kurun. Düşük donanımlı platformlarda aşırı dışa aktarım CPU’yu etkileyebilir; mümkün olduğunda denetleyici tarafındaki analitiği tercih edin.

Kontrol, OMP, BFD ve Tünel Sorun Giderme

Tutarlı bir iş akışı, hata etki alanını hızla daraltır:

1. Kapsamı ve katmanı belirleyin

• Sorun yalnızca kontrol düzleminde mi, veri düzleminde mi, yoksa uygulama katmanında mı?
• Birden fazla cihazın, lokasyonun veya yalnızca tek bir yolun/rengin etkilenip etkilenmediğini görmek için SD-WAN Manager lokasyon ve cihaz panolarını kullanın.

2. Kontrol bağlantılarını doğrulayın

• vBond’a genel IP’si üzerinden erişilebilmelidir; denetleyiciler varsayılan olarak DTLS/TLS için 12346 numaralı bağlantı noktasını kullanır.
• Varsayılan kontrol aktarımı DTLS’dir; birçok veri merkezi politikası, denetleyicilere TLS bağlantısı gerektirir. Aradaki cihazların (middlebox) seçilen protokole izin verdiğinden emin olun.
• Zaman senkronizasyonunu ve sertifikaları (kök zinciri, geçerlilik, CRL/OCSP erişilebilirliği) kontrol edin.
• Yaygın hatalar:
  • DCONFAIL: Genel kontrol bağlantısı hatası; temel nedenler arasında engellenen 12346 numaralı bağlantı noktası, NAT geçiş hatası, sertifika reddi veya denetleyicilere yönlendirme sorunları bulunur.
  • Kuruluş uyuşmazlığı: Cihaz kimlik bilgilerine/yapılandırmasına gömülü olan org-name, denetleyicilerle eşleşmelidir; aksi takdirde OMP oturumları kurulmaz.

3. OMP’yi ve politikayı doğrulayın

• OMP, rotaları, TLOC’leri ve hizmet zincirlerini vSmart ile uç noktalar (edge) arasında taşır. Asimetrik kontrol durumunu önlemek için kümedeki tüm vSmart düğümlerine OMP komşuluğunu onaylayın.
• Alınan/ilan edilen rotaları ve politika kabulünü doğrulayın. Politika, istemeden TLOC’leri veya ön ekleri filtreleyerek trafiği karadeliğe yönlendirebilir (blackholing).
• TLOC’ler sistem IP’si, renk ve kapsülleme (GRE veya IPsec) ile tanımlanır. Eşler (peer) arasındaki renk veya kapsülleme uyuşmazlıkları, belirli bir aktarım üzerinde tünel oluşumunu engeller.

4. BFD ve SLA’yı inceleyin

• BFD, tünel başına kayıp, gecikme ve sapmayı (jitter) izler ve uygulamaya duyarlı yönlendirmeyi (app-aware routing) besler. Dalgalanma (flapping) veya yüksek sapma, yönlendirmeyi tetikler. BFD zamanlayıcılarının/SLA sınıflarının tasarım amacına uygun olduğunu onaylayın. Düşük kaliteli devrelerde aşırı agresif zamanlayıcılar gereksiz yük devretmelere yol açar.

5. IPsec/veri düzlemini kontrol edin

• Tünel istatistiklerini, IPsec SA’larını, kapsülleme/kapsül açma (encaps/decaps) işlemlerini, tekrar saldırısı düşürmelerini (replay-drops) ve PMTU’yu inceleyin. NAT-T sorunları ve PMTU karadelikleri, özellikle geniş bant (broadband) bağlantılarda yaygındır.
• QoS şekillendirmenin (shaping) anlaşılan bant genişliğiyle uyumlu olduğunu doğrulayın; aşırı abonelik (oversubscription), kayıp/sapma okumalarını şişirir ve AAR’ı yanıltır.

IOS XE SD-WAN uç noktalarında (edge) kullanışlı show komutları:

show sdwan control connections
show sdwan omp peers | routes | tlocs
show sdwan bfd sessions
show sdwan ipsec inbound-connections outbound-connections
show platform hardware qfp active datapath utilization
show interfaces counters errors
show clock detail

Artıları/Eksileri ve Hata Modları:

• TLS vs DTLS: TLS, güvenlik politikası gereği zorunlu olabilir ve katı proxy’lerden daha iyi geçer; DTLS daha düşük el sıkışma (handshake) yükü sunar. Fabric genelinde tutarlı bir seçim yapın.
• BFD hassasiyeti: Sıkı zamanlayıcılar tepki süresini iyileştirir ancak gürültülü bağlantılarda CPU kullanımını ve yanlış pozitifleri artırır.
• Politika karmaşıklığı: Zengin merkezi politikalar amaçlarından sapabilir; hiyerarşik, iyi yorumlanmış politika nesnelerini tercih edin ve dağıtımdan önce simüle edin.

Yaşam Döngüsü Yönetimi, Uyumluluk ve Otomasyon

• Yazılım yükseltme planlaması:

  • Sıralama: Önce SD-WAN Manager kümesini, ardından vBond’u, sonra vSmart’ı ve son olarak WAN Edge’leri yükseltin. Sürüm notlarına göre sürüm uyumluluğunu koruyun. Edge’lere dokunmadan önce kontrolcülerin sağlıklı ve senkronize olması gerekir.
  • İmaj havuzları: İmajları hazırlamak için SD-WAN Manager’ın yazılım havuzunu kullanın. Kontrolcü imajları genellikle .qcow2 veya .ova formatlarını kullanır; edge’ler platforma özgü IOS XE SD-WAN paketlerini kullanır.
  • Bakım modu: Trafiği nazikçe boşaltmak için WAN Edge’i bakım moduna alın. Cihaz, TLOC’ları/OMP rotalarını geri çeker, böylece oturumlar yeniden yüklenmeden önce alternatif yollara/sitelere taşınır ve kullanıcı etkisi en aza indirilir.
  • Geri alma: Kanıtlanmış bir önceki imajı hazırda tutun. Yükseltme sonrası kontroller başarısız olursa, bilinen son iyi duruma geri dönün. IOS XE SD-WAN, çift banka kurulumlarını ve kontrolcü tarafından yönlendirilen sürüm düşürmeyi destekler.
  • Zamanlama: Değişiklik pencerelerini, ön kontroller (kontrol/OMP/BFD durumu, CPU/bellek) ve son kontroller (uygulama SLA’sı, tünel sayıları, hata oranları) ile birlikte kullanın.

• Yapılandırma uyumluluğu ve sapması:

  • İstenen durum, cihaz şablonları tarafından belirlenir. SD-WAN Manager, çalışan yapılandırma ile şablon arasındaki sapmayı vurgular; haklı gerekçelerle (ör. acil bir CLI düzeltmesi) yeniden ekleme (reattach) veya sapma kabulü iş akışlarıyla düzeltin.
  • Denetim izleri, kimin neyi ne zaman değiştirdiğini kaydeder (RBAC kapsamlı). Değişmez bir geçmiş için harici SIEM ile syslog/webhook’lar aracılığıyla eşleştirin.
  • Uyumluluk kural setleri: Org-name, sistem IP şeması, renk kullanımı, IPsec şifreleri, AAA ve NTP’nin standartlara uygun olduğunu doğrulayın.

• API tabanlı operasyonlar ve raporlama:

  • /dataservice REST API’leri izleme, yapılandırma ve eylem uç noktalarını sunar. Rapor oluşturmayı (SLA eğilimleri, en çok kullanılan uygulamalar), toplu yükseltmeleri, site eklemeyi ve uyumluluk kontrollerini otomatikleştirin.
  • Token’ları ve RBAC kapsamlı hesapları kullanın. Büyük ölçekte değişiklik yapmadan önce tekrarlanabilir (idempotent) iş akışları ve ön kontrol doğrulamaları uygulayın.

• Performans triyajı:

  • Tünel SLA’sı (kayıp, gecikme, jitter) ile başlayın, ardından cihaz CPU/belleği, sonra arayüz düşmeleri/hataları ve kuyruk derinlikleri ile devam edin. cflowd’den gelen uygulama KPI’ları ile ilişkilendirin.
  • Bozulmanın bağlantı kalitesi, tıkanıklık/QoS veya sunucu tarafı kaynaklı olup olmadığını, aynı uygulama ve yol için birden fazla sitenin deneyimini karşılaştırarak belirleyin.
  • Kapasite sinyalleri: Yükselen %95’lik dilim kullanımı, öncelikli sınıflardaki kuyruk düşmeleri ve AAR’nin sık sık yol değiştirmesi, ilke veya bant genişliği değişikliklerine ihtiyaç olduğunu gösterir.

• Olay müdahalesi, değişiklik kontrolü ve kök neden analizi (RCA):

  • Runbook’lar ilk müdahale eylemlerini tanımlar: kontrol/OMP/BFD durumlarının anlık görüntüsünü alın, ilgili logları/teknik destek paketlerini toplayın ve gerekli olmayan değişiklikleri dondurun.
  • Değişiklik kontrolü, ilke güncellemeleri için akran denetimini ve kanarya (canary) dağıtımlarıyla aşamalı sunumları zorunlu kılar.
  • Kök neden analizi, sorunu izole etmek için kontrolcü olaylarını (kim/ne zaman), akış telemetrisini (hangi trafik) ve yol metriklerini (nerede bozuldu) birleştirir. Örnekler: Yeni bir site ekleme değişikliğinden sonra ORG uyuşmazlığı, bir TLOC’u kaldıran istenmeyen bir ilke filtresi, ISP CPE değişikliğinden sonra geniş bant PMTU kara deliği.

Pratik Problem Senaryosu

Contoso Health, ISR 4000 WAN Edge’ler kullanarak çift taşıyıcılı SD-WAN (mpls renkli MPLS ve biz-internet renkli geniş bant) ile bağlanan 150 kliniği işletmektedir. Kontrolcüleri yeni bir veri merkezine taşıyan bir bakım penceresinden sonra, birkaç site zayıf EHR performansı ve aralıklı kesintiler bildirmektedir.

1. SD-WAN Manager’da kontrol düzlemi sağlığını kontrol edin

• Gerekçe: Kontrol düzlemi kararsızsa, tüm alt veri düzlemi ve ilke belirtileri bunu takip eder. Pano, aynı pencere sırasında birden fazla DCONFAIL olayı ve ORG uyuşmazlığı gösteriyor, bu da kontrolcü taşınmasından sonra devreye alma tutarsızlıklarına işaret ediyor.

2. Kontrolcü erişilebilirliğini ve portlarını doğrulayın

• Gerekçe: Yeni veri merkezi, kontrolcülere TLS bağlantısını zorunlu kılıyor. Aradaki cihazların varsayılan kontrol portu olan 12346 üzerinden kontrolcülere TLS’e izin verdiğini ve vBond’un NAT geçişi için genel IP’den erişilebilir olduğunu onaylayın. Bölgesel bir güvenlik duvarında engellenen bir port, kümelenmiş site arızalarını açıklıyor.

3. Kuruluş adı (organization-name) uyuşmazlığını düzeltin

• Gerekçe: Org-name uyuşmazlığı nedeniyle kontrolcülerle karşılıklı kimlik doğrulaması yapamayan edge’ler OMP kuramaz. Cihaz şablonundaki org-name’i kontrolcü sertifikalarıyla karşılaştırın; şablonları eşleşecek şekilde güncelleyin ve yeniden ekleyin (reattach). Bu, etkilenen siteler için vSmart ile OMP komşuluğunu geri yükler.

4. Zamanı ve sertifikaları uyumlu hale getirin

• Gerekçe: Veri merkezi taşıması NTP erişilebilirliğini değiştirdi. Kaymış saatler bazı sertifika doğrulamalarının başarısız olmasına neden oldu. Tüm edge’leri ve kontrolcüleri yedekli NTP’ye yönlendirin ve kimlik doğrulama ile kontrol oturumlarını stabilize etmek için saat senkronizasyonunu doğrulayın.

5. OMP rotalarını, TLOC’ları ve ilke kabulünü doğrulayın

• Gerekçe: Kontrolcü taşıması bir ilke yeniden yapılandırması içeriyordu. Kritik ön eklerin ve tüm TLOC’ların öğrenildiğini ve filtrelenmediğini doğrulamak için show sdwan omp routes/tlocs komutunu ve ilke görselleştirmesini kullanın. Yanlış sıralanmış bir veri ilkesi EHR sunucu trafiğini düşürüyordu; yeniden sıralayın ve erişilebilirliği geri yüklemek için uygulayın (commit).

6. BFD/SLA ve AAR davranışını değerlendirin

• Gerekçe: EHR yavaşlığı, yol kalitesini yansıtıyor olabilir. BFD, geniş bant üzerinde artan jitter gösteriyor; AAR yollar arasında sürekli geçiş yapıyor. SLA sınıfındaki histerezisi artırın ve QoS’in DSCP’ye göre EHR akışlarına öncelik verdiğinden emin olun. Bu, gereksiz yol geçişlerini azaltır.

7. Bakım modu ile hedeflenmiş yazılım yükseltmesi yapın

• Gerekçe: Mevcut IOS XE SD-WAN sürümündeki bilinen bir hata, biz-internet üzerinde aralıklı olarak jitter’ı yanlış raporluyor. Önerilen düzeltmeyi yazılım havuzunda hazırlayın. Edge’lerin bir alt kümesini bakım moduna alın, yükseltin, yükseltme sonrası kontrolleri doğrulayın, ardından geniş çapta dağıtın. Geri alma imajını hazırda tutun.

8. API aracılığıyla doğrulamayı ve raporlamayı otomatikleştirin

• Gerekçe: Tüm klinikler genelinde olay sonrası SLA uyumunu, uygulama performansını ve kontrol düzlemi kararlılığı raporlarını dışa aktarmak için /dataservice API’lerini kullanın. Otomasyon, tutarlı doğrulama sağlar ve değişiklik kontrolü için denetlenebilir bir kayıt oluşturur.

9. Kök neden analizini (RCA) belgeleyin ve kontrolleri sıkılaştırın

• Gerekçe: Kök nedenler, kontrol portu 12346’da bir güvenlik duvarı kuralı eksikliği, şablonlarda org-name sapması ve NTP yanlış yapılandırmasıydı ve bu durum bir ilke sıralama sorunuyla daha da kötüleşti. Tekrarı önlemek için devreye alma runbook’larını güncelleyin, değişiklik öncesi API tabanlı doğrulamayı (kontrolcü erişilebilirliği, org-name kontrolleri, NTP durumu) zorunlu kılın ve uygulama (commit) öncesinde ilke simülasyonları talep edin.

← Bulut · Tüm alanlar

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