Cisco 300-415: Cisco SD-WAN Doku Mimarisi ve Düzlemleri — Ç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; yönetim, orkestrasyon, kontrol ve veri işlevlerini ayıran farklı bileşenlerden ve düzlemlerden oluşturulmuş, amaç tabanlı bir yapıdır. Bu mimari, altyapı taşıyıcısından (underlay transport) bağımsız olarak birkaç şubeden binlercesine ölçeklenebilirken, deterministik kontrolü ve güvenliği de sürdürür. Bu bölümde vManage, vSmart, vBond ve WAN Edge’in rolleri; bunları birbirine bağlayan düzlemler ve protokoller; platform seçenekleri; adresleme ve segmentasyon; overlay topoloji desenleri; çoklu kiracılık (multitenancy) ve gruplama kavramları; ve göz önünde bulundurmanız gereken temel tasarım ödünleşimleri ile hata modları açıklanmaktadır.

Yapı Bileşenleri ve Düzlemleri

• WAN Edge: Şube, kampüs, ortak yerleşim (colocation) veya bulut ucundaki veri düzlemi (data-plane) yönlendiricisidir. Güvenli veri tünelleri oluşturur, politikaları uygular, yolun canlılığı için BFD çalıştırır, kontrolcülerle OMP rotalarını değiş tokuş eder ve kullanıcı trafiğini iletir.
• vSmart Controller: Kontrol düzleminin (control-plane) beynidir. Overlay topolojisini oluşturur ve sürdürür, OMP aracılığıyla rota ve politika bilgilerini dağıtır ve uçlar (edge) arasında güvenli IPsec eşleşmesini (peering) sağlamak için WAN Edge bağlantısını ve kripto anahtar dağıtımını yönetir.
• vBond Orchestrator: Yeni cihazlar için ilk temas noktasıdır. Cihaz kimliğini doğrular, NAT geçişine (NAT traversal) yardımcı olur ve her WAN Edge’in vSmart’a bağlantısını koordine eder. vSmart kontrolcüleriyle kalıcı bağlantıları sürdürür ve evrensel katılım (onboarding) için genellikle erişilebilir genel IP alanında bulunur.
• vManage: Yönetim ve orkestrasyon düzlemidir (NMS). Amaç girdisi, yapılandırma şablonları, imaj yönetimi, telemetri, Cloud OnRamp otomasyonu ve API’ler sağlar. vManage, iletim kontrol düzleminde (forwarding control plane) yer almaz.

Düzlemler ve protokoller:

• Yönetim düzlemi: vManage, cihazları ve kontrolcüleri izlemek ve yapılandırmak için güvenli kanallar (TLS üzerinden NETCONF/gRPC) kullanır.
• Orkestrasyon düzlemi: vBond, cihazları doğrulamak, kontrolcü erişilebilirliğini paylaşmak ve NAT’ı delip geçmek (punch through) için DTLS/TLS kullanır. Kontrolcü sertifikalarıyla ve alternatif bir port yapılandırılmadığında, vBond UDP/TCP 12346 portunu dinler.
• Kontrol düzlemi: vSmart, WAN Edge cihazlarıyla prefix’leri, TLOC’ları ve politikaları değiş tokuş etmek için OMP kullanır. Kontrol bağlantıları varsayılan olarak DTLS’tir; TLS de desteklenir ve genellikle sıkı güvenlik duvarları veya uyumluluk rejimleri nedeniyle gereklidir.
• Veri düzlemi: WAN Edge cihazları, şifreli taşıma için TLOC’lar arasında IPsec (veya uygun yerlerde GRE) tünelleri oluşturur. Saniyenin altında hata tespiti ve uygulamaya duyarlı yönlendirme (application-aware routing) için her tünelde BFD denetimi (probing) yapılır.

Katılım yaşam döngüsü:

1. WAN Edge, vBond ile temas kurar, kimliğini doğrular ve kontrolcü listelerini alır.
2. WAN Edge, vSmart’a (ve yönetim için vManage’e) DTLS/TLS kontrol oturumları kurar.
3. vSmart, kripto anahtar bilgilerini dağıtır; ardından WAN Edge, politika ve topolojinin gerektirdiği şekilde diğer WAN Edge’lerle IPsec tünelleri oluşturur.

Dayanıklılıkla ilgili çıkarımlar:

• vManage kaybı yalnızca yapılandırmayı ve görünürlüğü etkiler; veri iletimi devam eder.
• vBond kaybı yeni cihazların katılımını (onboarding) etkiler; mevcut cihazlar etkilenmez.
• Tüm vSmart kontrolcülerinin kaybı kontrol düzlemini izole eder; veri tünelleri devam eder ancak rota/politika değişiklikleri durur ve zamanla eskiyen kontrol durumu (stale control state) operasyonları bozabilir.
• BFD güdümlü yol yük devretme (path failover) ve çoklu TLOC’lar, altyapı (underlay) veya taşıma kesintileri sırasında veri düzlemi sürekliliğini sağlar.

Kimlik, Adresleme ve Segmentasyon

Kimlik ve adresleme, overlay merkezlidir:

• Organization name: Tüm cihazlarda ve kontrolcülerde eşleşmesi gereken, yapı genelinde (fabric-wide) bir dizedir; bir uyuşmazlık kontrol düzlemi komşuluğunu (adjacency) engeller.
• System IP: TLOC demetlerinde (tuple) ve kontrol düzlemi adreslemesinde kullanılan, cihaz başına benzersiz, loopback benzeri 32 bitlik bir tanımlayıcıdır. Herhangi bir fiziksel arayüze bağlı değildir.
• Site ID: Bir lokasyondaki cihazları gruplayan sayısal bir tanımlayıcıdır. Varsayılan olarak, aynı site ID’sini paylaşan cihazlar, bir site içindeki geri dönüşleri (hairpin) ve döngüleri (loop) önlemek için doğrudan veri tünelleri oluşturmaz.
• Sertifikalar: Cihazlar ve kontrolcüler X.509 kimliği kullanır. Donanım WAN Edge’ler, sıfır dokunuşla provizyon (zero-touch provisioning) için güvenli cihaz kimliğinden (SUDI) yararlanır; tüm cihazların yapıya (fabric) katılmadan önce vManage’e kaydolması ve yetkilendirilmesi gerekir.

Anahtar VPN’ler:

• VPN 0 (Transport): Altyapı taşıyıcı bağlantısını ve TLOC arayüzlerini MPLS, DIA, geniş bant veya LTE’ye doğru taşır. NAT, DHCP, PPPoE ve statik/varsayılan rotalar burada sonlanır. TLOC = {system IP, color, encapsulation}; burada color taşıyıcıyı (örneğin, mpls, biz-internet, public-internet) karakterize eder ve encapsulation IPsec veya GRE’dir.
• VPN 512 (Management): Bant dışı (out-of-band) cihaz yönetimi ve kontrolcü erişilebilirliği. IOS XE SD-WAN’de bu, bir yönetim VRF’ine eşlenir; vEdge’de ise açıkça VPN 512’dir. Kontrolcüler ve WAN Edge’ler, TLS ile güvenli hale getirilmiş protokolleri kullanarak yönetim oturumları kurar.
• Servis VPN’leri (512 hariç 1–511): Kullanıcı servislerini taşır ve OSPF, EIGRP, BGP, statik yönlendirme veya köprüleme (bridging) çalıştırabilir. Politikalar (merkezi ve yerel), VPN’ler arası (inter-VPN) ve VPN içi (intra-VPN) akışları, QoS’i ve güvenliği yönlendirir.

Kullanışlı temel yapılandırma öğeleri:

sdwan
 system-ip 10.255.0.11
 site-id 101
 organization-name ACME-Global

Dikkat edilmesi gereken hata modları:

• Yinelenen system IP’ler veya site ID’ler, kontrol anomalilerine veya istenmeyen tünel bastırılmasına neden olur.
• Organization-name uyuşmazlığı, OMP komşuluklarını engeller.
• Sertifika süresinin dolması veya iptali, kontrolcü veya cihaz güvenini koparır.
• VPN 512’deki yanlış yerleştirilmiş bir yönetim varsayılan rotası (default route), bir cihazı kontrolcülerden koparır; VPN 0’daki yanlış yerleştirilmiş bir taşıma varsayılan rotası ise TLOC’ları izole eder.

Platformlar, Dağıtım Modelleri ve Denetleyici Tasarımı

WAN Edge platformları:

• Cisco IOS XE SD-WAN: ISR 4000 Serisi ve ASR 1000 Serisi platformlarda (ve Catalyst 8000 ailesinde) desteklenir. Uzun vadeli özellik hızı ve birleşik şube hizmetleri için IOS XE SD-WAN’ı tercih edin.
• vEdge: Önceki Viptela tabanlı donanım/sanal platformlar birçok dağıtımda hala desteklenmektedir; geçiş planlamasında özellik eksiklikleri ve yaşam döngüsü zaman çizelgeleri dikkate alınmalıdır.
• Sanal WAN Edge: Cisco UCS ve Cisco ENCS 5000 Serisi dahil olmak üzere hipervizörlerde ve sunucularda ve genel bulutlarda (AWS, Azure, GCP) çalışır. IaaS dağıtımlarını otomatikleştirmek için Cloud OnRamp’ı kullanın; ön koşullar arasında bulut pazar yeri imajına (örneğin, AWS AMI) abone olmak ve vManage’de bir cihaz şablonu hazırlamak yer alır.

Underlay bağımsızlığı ve taşıma çeşitliliği:

• Her TLOC, ilişkili bir renge sahip bir taşımaya bağlanır; politika, uygulama, SLA veya site rolüne göre taşımaları tercih edebilir, dengeleyebilir veya hariç tutabilir.
• IPsec, güvenilmeyen underlay’ler genelinde varsayılandır; şifrelemenin gereksiz veya kısıtlı olduğu özel MPLS üzerinden GRE kullanılabilir.
• BFD, uygulamaya duyarlı yönlendirmeyi (application-aware routing) yönlendirmek için tünel başına canlılık ve SLA metrikleri (kayıp, gecikme, jitter) sağlar.

Denetleyici kümeleme, ölçek, yüksek erişilebilirlik ve yerleşim:

• vManage: Yüksek erişilebilirlik (HA) ve esneklik için üç düğümlü veya daha büyük bir küme olarak dağıtın; telemetri ve imaj deposu için yüksek verimli depolama ile aynı yerde konumlandırın. Sık sık yedekleyin.
• vSmart: Birden çok denetleyiciyi hata etki alanları (fault domains) ve coğrafyalar arasında dağıtın; tüm WAN Edge’ler birden fazla vSmart ile kontrol oturumları oluşturur. vSmart örnekleri yatay olarak ölçeklenir; bir denetleyici kaybını sürdürmek için N+1 kapasitesi planlayın.
• vBond: Genel adres alanında (veya statik NAT ve tutarlı port eşlemesi ile) en az iki orchestrator dağıtın. vBond, vSmart’a kalıcı oturumları ve katılım (onboarding) sırasında WAN Edge’lere geçici oturumları sürdürür.
• Yerleşim: Denetleyiciler, veri merkezlerinizde veya genel bulutta barındırılabilir. vBond için internetten deterministik gelen erişilebilirliği ve WAN Edge’ler için yeterli egress’i sağlayın. Eğer middlebox’lar TLS denetimi istisnalarını zorunlu kılıyorsa, DTLS yerine TLS kontrol oturumlarını tercih edin.

Operasyonel notlar:

• Varsayılan kontrol düzlemi (control-plane) taşıması DTLS’dir; yalnızca TCP tabanlı şifreli kontrole izin veren katı güvenlik duvarlarını veya uyumluluk alanlarını (compliance domains) geçerken TLS’e geçin. Uygun portlara uçtan uca izin verildiğinden emin olun.
• Bir WAN Edge katıldığında, OMP erişilebilirliğine ve politikaya dayanarak vSmart’a DTLS/TLS ve eş (peer) edge’lere IPsec tünelleri kurar. Sessiz tünel düşmelerini önlemek için geniş bant devrelerinde NAT keepalive’larını ve UDP pinhole’larını sağlayın.

Yer Paylaşımlı Topolojiler, Çoklu Kiracılık ve Tasarım Ödünleşimleri

Topoloji desenleri, merkezi kontrol politikaları (rota ve TLOC reklamları) ve yerelleştirilmiş veri politikaları aracılığıyla gerçekleştirilir:

• Full mesh: Tüm sahalar arasında en düşük gecikme; mükemmel esneklik; çok sayıda IPsec/BFD oturumu nedeniyle en yüksek kontrol ve veri düzlemi ölçek yükü.
• Hub-and-spoke: Daha az tünel ile basit ölçeklendirme; hub, çift hub’lı bir tasarım olmadan bir bant genişliği ve esneklik darboğazı haline gelir; spoke’tan spoke’a daha yüksek yol gecikmesi.
• Bölgesel hub: Full mesh’leri bölgesel olarak kapsamlandırarak ve bölgeler arası trafiği hub’lar üzerinden taşıyarak gecikme ve ölçeği dengeler; tromboning’i (gereksiz yönlendirme) önlemek için dikkatli politika gerektirir.
• Çift hub (aktif/aktif veya aktif/yedek): Esnekliği artırır ve yükü dağıtabilir; kontrol karmaşıklığını (ECMP, eşitlik bozma, döngü önleme) artırır ve daha fazla hub kaynağı tüketir.

Çoklu kiracılık ve gruplama:

• Gerçek çoklu kiracılık: Servis sağlayıcılar, aynı denetleyici kümesinde yalıtılmış kontrol düzlemleri, yöneticiler ve politikalara sahip birden çok mantıksal organizasyonu barındırmak için denetleyicilerde çoklu kiracı modunu etkinleştirebilir.
• Kiracı veya iş birimi başına segmentasyon: Trafik ayrımını zorunlu kılmak, gerektiğinde rota sızdırmak ve VPN başına politika/QoS uygulamak için servis VPN’lerini kullanın.
• Cihaz gruplama: Politikaları, yükseltmeleri ve şablonları işleve, bölgeye veya role göre hedeflemek için vManage cihaz gruplarını, saha listelerini, VPN listelerini, prefix/TLOC listelerini kullanın.

Tasarım ödünleşimleri:

• Gecikme ve politika kontrolü: Full mesh gecikmeyi en aza indirir ancak politika uygulamasını ve gözlemlenmesini karmaşıklaştırır; hub-and-spoke kontrolü basitleştirir ancak doğu-batı akışları için gecikme ekler.
• Esneklik ve operasyonel ölçek: Daha fazla TLOC, transport ve hub, kullanılabilirliği ve yol seçimini artırır ancak IPsec/BFD oturumlarını ve kontrol ölçeğini çoğaltır. OMP ve FIB boyutlarını kontrol altında tutmak için bölgeselleştirme ve özetleme kullanın.
• Underlay çeşitliliği ve maliyet: Geniş bant ve LTE eklemek, ulaşılabilirliği ve brownout direncini artırır; maliyet, NAT davranışı ve değişken jitter, SLA’ları karmaşıklaştırabilir. Hassas trafiği kısıtlamak için BFD’den türetilmiş SLA sınıflarını ve uygulamaya duyarlı yönlendirmeyi kullanın.
• Merkezi politika zenginliği ve sorun giderme belirsizliği: Karmaşık eşleştirme/eylem zincirleri granüler kontrol sağlar ancak iletim mantığını belirsizleştirebilir. Politikayı modüler, sürümlenmiş ve iyi belgelenmiş tutun; bir hazırlık (staging) fabric’inde test edin.
• Güvenlik ve performans: Tüm transport’larda zorunlu IPsec gizliliği güçlendirir ancak CPU ek yükü ve MTU/parçalanma hususlarını beraberinde getirir. Donanım kripto hızlandırmayı ve tutarlı MSS/PMTUD ayarlarını tercih edin.

Yaygın hata modları ve azaltma yöntemleri:

• Tünel oluşumunu engelleyen asimetrik politika: TLOC ve kontrol politikalarını simetrik olarak doğrulayın; OMP TLOC rotalarını onaylayın.
• UDP’de NAT pinhole’larının süresinin dolması: TLS kontrolünü tercih edin veya NAT keepalive’larını yapılandırın; denetleyiciler için statik NAT düşünün.
• Saha içi tünelleri çökerten Site ID yanlış kullanımı: Her fiziksel konum için benzersiz site ID’leri sağlayın; saha birleştirmelerini zorlamak yerine kampüs içi niyet için BFD color-restrict politikalarını kullanın.
• Kaynakları tükenen hub’lar (Spoke-starved hubs): Hub CPU/kripto ve BFD oturum sayılarını izleyin; hub’ları yatay olarak ölçeklendirin veya bölgesel hub’lar ekleyin; kontrol trafiğini korumak için QoS ve policer’ları kullanın.

Pratik Problem Senaryosu

Apex Manufacturing, çift transport (MPLS ve DIA) üzerinde 600 küresel şube işletirken AWS’e doğru genişliyor. Bölgesel uygulamalara minimum gecikmeyle SD-WAN’ı AWS’e genişletmeleri, kontrol için TLS kullanarak uyumluluğu sürdürmeleri ve denetleyici HA’sını sağlamaları gerekiyor.

1. İki vBond orchestrator’ı genel IP alanına ve üç vSmart denetleyicisini iki buluta yayın.

• Gerekçe: vBond, NAT geçişine yardımcı olmak için genel olarak erişilebilir olmalıdır; birden çok vSmart örneği, kontrol düzlemi HA’sı ve coğrafi yakınlık sağlar. vBond, vSmart’a kalıcı oturumlar ve WAN Edge’lere geçici oturumlar sürdürerek, yeni cihaz eklemeyi ve yeniden bağlanmayı hızlandırır.

2. Tüm kontrol bağlantılarını TLS’e dönüştürün ve kurumsal güvenlik duvarlarından TCP 12346’ya izin verin.

• Gerekçe: Varsayılan DTLS, katı aracı cihazlar (middlebox) tarafından engellenebilir. TLS, şifreleme veya bütünlükten ödün vermeden TCP proxy’leri ve denetim alanları üzerinden kontrol düzlemi erişilebilirliğini sağlar.

3. vManage’i merkezi bir bulut bölgesinde, günlük yedeklemelerle üç düğümlü bir küme olarak dağıtın.

• Gerekçe: Yönetim düzlemi; politika, imaj ve telemetri işlemleri için kullanılabilir kalmalıdır. Kümeleme, durumu korur ve API/GUI erişimini ölçeklendirir; yedeklemeler, operasyonel veri kaybına karşı koruma sağlar.

4. AWS’de, VPC başına bir tane olacak şekilde, transit gateway’e bağlı alt ağlarda sanal WAN Edge yönlendiricileri oluşturmak için Cloud OnRamp for IaaS kullanın.

• Gerekçe: Cloud OnRamp, AMI aboneliğini, dağıtımı ve sertifika kaydını otomatikleştirir. WAN Edge cihazları, SD-WAN TLOC’larını sonlandırır ve OMP aracılığıyla VPC rotalarını reklam ederek, bulut iş yüklerini aynı politika setiyle fabric’e entegre eder.

5. Ayrılmış bir yer paylaşımlı (overlay) bloktan sistem IP’leri ve her bulut bölgesi için benzersiz site ID’leri (ör. 9001–9010) atayın ve fabric genelinde tutarlı bir organizasyon adı belirleyin.

• Gerekçe: Benzersiz sistem IP’leri ve site ID’leri, tünel bastırmayı ve kontrol düzlemi belirsizliğini önler. Organizasyon adının tekdüzeliği, OMP komşulukları ve sertifika güveni için zorunludur.

6. AWS edge’lerinde çift transport (genel internet ve mevcut olduğunda özel bir color aracılığıyla Direct Connect) için VPN 0’ı yapılandırın ve uygulamaya duyarlı yönlendirme için SLA sınıflarıyla BFD’yi etkinleştirin.

• Gerekçe: Transport çeşitliliği, ulaşılabilirliği ve brownout direncini artırır. BFD, uygulama trafiğini SLA başına en iyi performans gösteren TLOC’a yönlendirmek için kayıp/gecikme/jitter metrikleri sağlar.

7. VPN 512’yi yalnızca yönetim alt ağlarına açın ve denetleyicilere yönlendirmeyi açık statik rotalar ve ACL’ler aracılığıyla kısıtlayın.

• Gerekçe: Yönetim düzlemindeki saldırı yüzeyini en aza indirir ve cihazları başıboş bırakabilecek veya denetleyici hizmetlerini aşırı derecede ifşa edebilecek rota sızıntılarını önler.

8. İlgili bölgeleri için hub olarak AWS edge’lerini kullanarak, yük devretme için kıta başına çift şirket içi hub ile bölgesel bir hub topolojisi uygulayın ve gecikmeye duyarlı trafik için spoke’tan spoke’a doğrudan internet yollarını etkinleştirin.

• Gerekçe: Bölgesel hub’lar, gecikmeyi azaltmak ve kontrol ölçeğini sınırlamak için akışları yerelleştirir; çift hub yedeklilik sağlar. Kontrollü spoke’tan spoke’a doğrudan tüneller, hub’ları aşırı yüklemeden gerçek zamanlı uygulamalar için düşük gecikmeyi korur.

9. Bölgesel hub’larda şube rotalarını özetlemek, TLOC reklamlarını hedeflenen bölgelerle kısıtlamak ve üretim, OT ve misafir trafiği için servis VPN’leri ile segmentasyonu zorunlu kılmak için merkezi kontrol politikaları uygulayın.

• Gerekçe: Özetleme, OMP rota değişimini ve bellek kullanımını azaltır. Kapsamı belirlenmiş TLOC reklamları, istenmeyen bölgeler arası tünel oluşumunu önler. VPN tabanlı segmentasyon, yalnızca gerektiğinde açık rota sızdırmaya izin vererek uyumluluk sınırlarını korur.

10. BFD ve kontrol düzlemi sağlığını izleyin; bir vSmart veya vBond kaybı için uyarı ayarlayın ve N+1 kapasitesini önceden tedarik edin.

• Gerekçe: Kontrol bozulmasının erken tespiti, yaygın istikrarsızlığı önler. N+1, fabric’in bir denetleyici arızasını oturum yetersizliği olmadan sürdürmesini sağlayarak hem kontrol düzlemi yakınsamasını hem de veri düzlemi esnekliğini korur.

Tüm alanlar · Denetleyici Kurulumu →

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