Cisco 300-415: Hizmet Kalitesi ve Çoklu Yayın Servisleri — Ç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’deki Hizmet Kalitesi (QoS) ve çoklu yayın (multicast) hizmetleri, gerçek zamanlı ve grup trafiğinin ölçeklenebilir, ilke tabanlı dağıtımını sağlarken, çeşitli taşıma ortamlarında uygulama deneyimini korumak için tasarlanmıştır. QoS, her uygulama ve her overlay tüneli başına öncelik, şekillendirme ve bant genişliğinin adil kullanımını sağlar; çoklu yayın, sahalar arasındaki alıcılar için akışların verimli, ilke kontrollü çoğaltılmasına olanak tanır. Bu ikisi birlikte, niyeti (ses/video kayıp ve titreşime karşı korunmalı; iş açısından kritik uygulamalar SLA’ları karşılamalı) SD-WAN kontrol düzlemi (vSmart) tarafından koordine edilen ve WAN Edge cihazlarında zorunlu kılınan tutarlı bir veri düzlemi davranışına dönüştürür.

QoS Mimarisi, Kuyruklar, Zamanlama, Şekillendirme, Denetleme ve Bant Genişliği Tahsisi

Cisco SD-WAN’deki QoS, hiyerarşik ve taşıma ortamına duyarlıdır:

• Sınıflandırma: Akışları alanlara (L3/L4), DSCP’ye, uygulama imzalarına (IOS XE SD-WAN üzerinde NBAR2) veya VPN ve önek bağlamına göre tanımlayın.
• İşaretleme: Hizmet tarafından DSCP’yi ayarlayın veya koruyun, WAN kısıtlamaları için gerektiği gibi yeniden yazın ve QoS haritaları aracılığıyla çıkış kuyruklarına eşleyin.
• Kuyruklama ve zamanlama: Çıkış arayüzleri, gerçek zamanlı trafik için katı öncelikli düşük gecikmeli bir kuyruk (LLQ) ve diğer sınıflar için ağırlıklı zamanlayıcılar (WFQ/WRR/CBWFQ) ile birden çok donanım/yazılım kuyruğu uygular.
• Şekillendirme: Sağlayıcı denetleyicilerinden (policer) kaçınmak ve ani trafik artışlarını sönümlemek için çıkış trafiğini yapılandırılmış bir hıza (arayüz başına, alt arayüz başına veya tünel başına) göre yumuşatın.
• Denetleme (Policing): Giriş veya çıkışta uygun olmayan trafiği hız sınırlamasına tabi tutun ve isteğe bağlı olarak yeniden işaretleyin veya düşürün; uygulama performans düşüşlerini (brownout) önlemek için idareli kullanılır.
• Bant Genişliği tahsisi: Her sınıf için minimum bant genişliği (garantiler) ayırın ve uygun olan yerlerde maksimumları sınırlayın; diğer kuyrukların kaynak yetersizliği yaşamasını önlemek için LLQ’nun sıkı, belirgin bir sınırı olduğundan emin olun.

Tasarım rehberi ve ödünleşimler:

• ISP’nin etkin denetleyicisinin (policer) altında güvenli bir hıza göre şekillendirin. Değişken İnternet devreleri için, nominal bant genişliğinin %90-95’i pratik bir başlangıç noktasıdır; yük altındaki gözlemlenen düşüşleri ve gecikmeyi kullanarak ayarlama yapın.
• Kuyruk derinliği (arabelleğe alma), gecikme ve kayıp arasında denge kurmalıdır. Bant genişliği-gecikme çarpımının kabaca bir kesrine göre boyutlandırın; çok küçük olması kuyruk sonu düşüşüne (tail drop) neden olur; çok büyük olması ise daha düşük sınıflar için gecikmeyi artırır.
• LLQ’yu yalnızca kısa, sabit hızlı ses/video kontrol akışları için kullanın; yüksek bit hızlı video akışlarını LLQ’ya yerleştirmeyin—onları net bir bant genişliği sınırına sahip, yüksek öncelikli, ağırlıklı bir kuyruğa atayın.
• Çıkışta denetleme (policing) yerine şekillendirmeyi (shaping) tercih edin. Belirgin hız sözleşmeleri veya güvenilmeyen giriş trafiği için denetleyicileri (policer) uygulayın.
• Birden fazla overlay taşıyan paylaşılan fiziksel bağlantılarda, her bir BFD tabanlı güvenli tünelin kendi zamanlayıcısını/şekillendiricisini alması için tünel başına QoS’u (PTQ) etkinleştirin, böylece meşgul tek bir overlay’in bağlantıyı tekeline almasını önleyin.
• Taşıma ortamına özgü ilke (renk/TLOC duyarlı), her underlay için farklı QoS haritaları, şekillendiriciler ve sınıf garantileri sağlar (örneğin, İnternet üzerinde daha sıkı şekillendirme ve azaltılmış DSCP seti, MPLS üzerinde ise daha zengin sınıflar).

Tünel başına QoS ve taşıma ortamı özellikleri:

• PTQ, her bir IPsec/DTLS/TLS tüneli için çıkış zamanlamasını sanallaştırır, böylece garantiler ve sınırlar yalnızca arayüz başına değil, yol başına uygulanır. Bu, bir Edge aynı arayüz üzerinden birden fazla tünel oluşturduğunda (örneğin, çift vSmart/vBond bölgesi veya birden çok uzak eş) çok önemlidir.
• Sağlayıcının DSCP beyaz listelerine uymak ve beklenmedik yeniden işaretlemeyi önlemek için her renge (biz-internet, mpls, lte) farklı QoS haritaları atayın (örneğin, geniş bant üzerinde AF sınıflarını varsayılana indirgemek).

DSCP, QoS Haritaları ve Tıkanıklık Yönetimi ile Sınıflandırma ve İşaretleme

Güvenilir sınıflandırma, hizmet VPN’i ucunda başlar:

• Güven sınırları: LAN erişim alanı QoS’ten habersizse, WAN Edge’de L7 uygulama kimliği veya L3/L4 demetleri kullanarak sınıflandırın ve işaretleyin. LAN QoS yetenekliyse, bir WAN QoS haritasına normalleştirirken DSCP’yi denetleyin ve koruyun.
• DSCP stratejisi: Etkileşimli ses için EF, video için AF41/42, kritik veriler için AF31/AF21, sinyalleşme için CS3/AF sınıfları, en iyi çaba (best effort) için CS0/DF ve artık (scavenger) trafik için CS1 (veya LE). Sağlayıcı tarafından kabul edilen değerlerle uyumlu hale getirin.
• QoS haritası: DSCP’yi kuyruğa eşleyin ve isteğe bağlı olarak çıkışta yeniden yazın; underlay sınırlarına saygı duyan bire bir veya çoka bir eşleme sürdürün.

Operasyonel olarak faydalı kontrollere kısa bir örnek:

show sdwan app-route stats sla-class VOICE
show policy qos-queue   (vEdge)
show policy-map interface <wan-intf>  (IOS XE SD-WAN)

Tıkanıklık yönetimi ve kuyruk boyutlandırma:

• EF için küçük, sınırlı bir LLQ ile başlayın (örneğin, şekillendirilmiş hızın %10’u) ve yanlış işaretlenmiş akışların aşımını önlemek için LLQ içinde denetlemeyi (policing) zorunlu kılın.
• Kalan bant genişliğini, iş önceliğiyle uyumlu WRR/CBWFQ ağırlıklarını kullanarak tahsis edin (örneğin, %30 kritik veri, %20 video, %35 en iyi çaba, %5 artık trafik).
• Platform tarafından desteklendiğinde, küresel senkronizasyondan kaçınmak için toplu sınıflar için erken düşürmeyi (WRED) etkinleştirmeyi düşünün; LLQ veya küçük kontrol kuyruklarında erken düşürmeyi etkinleştirmeyin.

Dikkat edilmesi gereken hata modları:

• Taşıyıcının yeniden işaretlemesi DSCP’yi çökertir ve gerçek zamanlı trafiği en iyi çaba (best effort) sınıfına yerleştirir; sonuç, yoğun zamanlarda titreşim ve paket kaybıdır. Paket yakalamaları ve sağlayıcı QoS profilleri ile doğrulayın.
• Yanlış boyutlandırılmış şekillendiriciler kalıcı kuyruk sonu düşüşlerine (tail drop) yol açar; LLQ, sınırsız bırakılırsa veya video LLQ’yu doldurursa kaynak yetersizliği yaşar.
• Paylaşılan bir arayüzde PTQ’nun olmaması, “gürültülü komşu” overlay’lerinin bant genişliğini tüketmesine ve kritik tünellerin performansını düşürmesine neden olur.

Uygulama Önceliklendirme, İş Amacı ve SLA Uygulaması

Cisco SD-WAN, overlay kontrol düzlemini yöneten ve ilkeleri WAN Edge’lere dağıtan vSmart denetleyicisi üzerindeki merkezi ilke aracılığıyla uygulama amacını ifade eder. Uygulama Farkındalıklı Yönlendirme (AAR), BFD kullanarak her bir taşıma (transport) ve her bir tünel için ölçülen kayıp, gecikme ve jitter’a dayalı olarak trafiği yönlendirir. SaaS optimizasyonu için Cloud OnRamp, bir ağ geçidi sahasına (gateway site) yönelik BFD metriklerine ek olarak uygulamaya yönelik HTTP tabanlı kayıp ve gecikmeyi de dahil edebilir.

En iyi uygulamalar:

• Uygulama listelerini ve SLA sınıflarını iş açısından kritikliklerine göre tanımlayın:
  • VOICE: EF, hedef <150 ms tek yönlü, <30 ms jitter, <%1 kayıp; yalnızca bu eşikleri karşılayan yollar üzerinden yönlendirin.
  • VIDEO: AF4x, sese göre biraz daha gevşek jitter/kayıp; yüksek bant genişlikli düşük kayıplı yolları tercih edin.
  • KRİTİK VERİ: AF3x/AF2x; uygulamanın gerektirdiği şekilde kayıp ve gecikmeyi sınırlandırın.
• Sınıf başına SLA’yı karşılayan yolları tercih etmek için uygulama farkındalıklı yönlendirme (AAR) için merkezi ilke kullanın; bozulma meydana geldiğinde ikincil yollara geri dönün.
• AAR’ı taşıma başına QoS ile birleştirin: seçilen bir yolun sınıf için ayrılmış kaynakları olmalıdır; aksi takdirde trafik, yol SLA’sını karşılasa bile çıkışta kuyruğa alınabilir veya düşürülebilir.
• Bir ağ geçidi sahası (gateway site) aracılığıyla SaaS için her ikisini de doğrulayın:
  • SaaS uç noktasına olan HTTP kayıp/gecikmesi.
  • Ağ geçidi sahasına (gateway site) olan BFD kayıp/gecikmesi.
• DSCP’nin uçtan uca korunmasını zorunlu kılın; çıkışta, yalnızca underlay’lerin gerektirdiği yerlerde yeniden yazın ve karşı uç onlara güvenirse işaretlemeleri geri yükleyin.

Operasyonel kontroller:

show sdwan app-route statistics
show sdwan bfd sessions
show application traffic-flow   (vManage analytics)

Sık karşılaşılan tuzaklar:

• Sıkı SLA eşikleri yol kararsızlığına (path flapping) neden olur; histerezis ve bekleme zamanlayıcıları ekleyin.
• Seçilen yolda sınıf bant genişliğinin olmaması, kendi kendine neden olunan tıkanıklığa yol açar; AAR seçimlerini taşıma başına QoS kapasitesiyle uyumlu hale getirin.
• Şifrelenmiş yükler veya eksik NBAR imzaları nedeniyle yanlış sınıflandırma (örneğin, sesin en iyi çaba (best effort) olarak keşfedilmesi); geri dönüş mekanizması (fallback) olarak DSCP güvenini veya açık L4 eşleşmelerini kullanın.

Çoklu Yayın Temelleri ve Overlay Çoklu Yayın Tasarımı

SD-WAN üzerinden çoklu yayın (multicast), LAN çoklu yayın kontrol düzlemini altyapı (underlay) kısıtlamalarından ayırır:

• Temeller:
  • Alıcılar, IGMPv2/v3 ile ilk atlama (first-hop) LAN yönlendiricisine (servis VPN’indeki WAN Edge) doğru ilgi bildiriminde bulunur.
  • Servis VPN’inde PIM Sparse Mode önerilir; randevu noktaları (RP’ler) ilk katılımları düzenler.
• Overlay kontrol düzlemi:
  • WAN Edge yönlendiricileri, OMP aracılığıyla vSmart denetleyicisine çoklu yayın servis rotaları oluşturur.
  • Çoklu yayın çoğaltıcısı/RP duyurusu rolünde hareket eden vSmart denetleyicisi, RP bilgilerini overlay üzerinden yayar ve istenen gruplar için katılımları, orijinal PIM katılım mesajında belirtildiği gibi kaynağa veya PIM-RP’ye doğru iletir.
  • vSmart, veri düzlemi çoğaltıcıları (replicator) olarak bir veya daha fazla WAN Edge’i seçer. Kaynak tarafındaki Edge, çoğaltıcıya tek bir kopya gönderir, bu da alıcı Edge’lere çoğaltarak kısıtlı bağlantılardaki bant genişliği kullanımını en aza indirir.
• Veri düzlemi:
  • Çoğaltma, overlay tünelleri üzerinden tekli yayın (unicast) şifrelenmiş paketler olarak gerçekleşir; servis VPN sınırları korunur (çoklu yayın, VPN/VRF başına yapılır).
  • VPN’ler arası çoklu yayın otomatik değildir; gerekirse, açıkça servis zincirleme (service-chaining) veya uygulama katmanı ağ geçitleri (gateway) kullanın.

Tasarım hususları ve ödünleşimler:

• RP’yi mantıksal olarak kaynaklara veya merkezi veri merkezlerine yakın konumlandırın. Bir SD-WAN overlay’inde, tutarlı katılımlar sağlamak için alıcılara RP’yi duyurması için vSmart’a güvenin.
• Çoklu yayını yalnızca ihtiyaç duyulan VPN’lerde etkinleştirin; CPU’yu korumak için alıcı kontrol trafiğini (IGMP) hız limitli (rate-limited) tutun.
• Düşük bant genişliğine sahip bağlantılarda, erişim devrelerinde N×akış çoğaltmasını önlemek için çoğaltmayı, bol kapasiteye sahip bir merkez/çoğaltıcıda (hub/replicator) merkezileştirin.
• Yüksek bit hızlı akışların parçalanmasını (fragmentation) önlemek için MTU’yu doğrulayın; video sınıflarını kontrol düzlemi kuyruklarından bağımsız olarak şekillendirmeyi (shaping) düşünün.

Hata modları:

• LAN’da IGMP sorgulayıcısının (querier) olmaması, grup yaşlanmasına ve akış kaybına yol açar; WAN Edge’in veya bir LAN anahtarının sorgulayıcı olarak hareket ettiğinden emin olun.
• Merkezi politikada RP uyuşmazlığı veya filtreleme, katılımları bozar; overlay genelinde RP erişilebilirliğini onaylayın.
• Aşırı küçük paketli çoklu yayın kontrol trafiği, DDoS ile karıştırılabilir; kontrol kuyruklarını hız limitine tabi tutun ve izleyin.
• Yanlış belirtilmiş servis VPN sınırları teslimatın yapılamamasına neden olur; çoklu yayın, açıkça tasarlanmadıkça VPN’ler arasında geçiş yapmaz.

Sorun giderme temelleri:

show ip igmp groups
show ip pim neighbor / rp mapping
show sdwan omp services
show sdwan multicast status
show interface | include drops

Kuyruk düşüşlerini (queue drops) uygulama KPI’ları ile ilişkilendirin; çoklu yayın için, Edge’de IGMP katılımlarının görüldüğünden, OMP servis rotalarının mevcut olduğundan ve seçilen çoğaltıcının sağlıklı bir tünel üzerinden erişilebilir olduğundan emin olun.

Pratik Problem Senaryosu

NorthRiver Health, çift taşıyıcılı (MPLS ve İnternet) 120 klinik işletmektedir. Şikayetler arasında kesik kesik ses, pikselli teletıp videosu ve bekleme odalarındaki kesintili IPTV çoklu yayını yer almaktadır.

Yaklaşım:

1. Güven sınırlarını belirleyin ve trafiği sınıflandırın

• Gerekçe: Doğru sınıflandırma, önceliklendirmenin ön koşuludur. Uyumlu LAN alanlarından gelen DSCP’yi koruyun; olmadığı durumlarda, uygulamaya (NBAR2) ve L4 demetlerine (tuple) göre sınıflandırın, sesi EF’ye, videoyu AF41’e, kritik EMR’yi AF31’e eşleyin.

2. Taşıyıcıya özgü QoS haritaları ve şekillendiriciler oluşturun

• Gerekçe: MPLS, AF/EF’yi dikkate alırken, İnternet genellikle almaz. Renk başına QoS haritaları yapılandırın: MPLS üzerinde tam sınıf seti; İnternet üzerinde EF ve AF4 korunarak birleştirilmiş sınıflar. Sağlayıcı denetleyicilerinden (policer) kaçınmak için MPLS’i CIR’nin %95’ine ve İnternet’i ölçülen sürdürülebilir verime göre şekillendirin.

3. Paylaşılan WAN arayüzlerinde tünel başına QoS’i etkinleştirin

• Gerekçe: Birden fazla overlay aynı fiziksel bağlantıyı paylaşır. PTQ, meşgul bir şube-bulut tünelinin, tünel başına zamanlayıcılar ve minimumlar atayarak şube-veri merkezi ses/video tünellerini kaynak yetersizliğinden boğmasını (starving) önler.

4. Ses için LLQ’yu ayırın ve sınırlayın; video ve kritik verileri ağırlıklandırın

• Gerekçe: Ses, sınırlı gecikme/jitter gerektirir; kaynak yetersizliğini önlemek için LLQ’yu %10 ile sınırlayın. AF4 videoya katı bir maksimum ile %25–30 atayın. AF3 EMR trafiğine %25 ayırın, kalanı en iyi çaba (best effort) ve artık (scavenger) trafiğe ayırın.

5. vSmart üzerinde SLA sınıfları ile merkezi AAR politikası uygulayın

• Gerekçe: vSmart, BFD kayıp/gecikme/jitter kullanarak ses/video/EMR trafiğini SLA hedeflerini karşılayan yollara yerleştiren merkezi bir politika dağıtır. Sürekli durum değişimini (flap) önlemek için histerezis ekleyin. Bir ağ geçidi üzerinden SaaS EHR modülleri için, SaaS’a HTTP kaybı/gecikmesini ve ağ geçidi sitesine BFD’yi dahil edin.

6. vSmart çoğaltıcı seçimi ile overlay çoklu yayınını dağıtın

• Gerekçe: Verimli IPTV dağıtımı, kontrollü çoğaltma gerektirir. IPTV VPN’inde çoklu yayını etkinleştirin, PIM-SM ve RP’yi yapılandırın ve düşük hızlı klinik devrelerini N yönlü çoğaltmadan korumak için vSmart’ın RP’yi duyurmasına ve bir veri merkezi Edge’ini çoğaltıcı olarak seçmesine izin verin.

7. Telemetri ile doğrulayın ve yineleyin

• Gerekçe: Yük altındaki davranışı onaylayın. Şunları kullanın:
  • SLA yol seçimini doğrulamak için show sdwan app-route statistics.
  • Kuyruk kullanımını ve düşüşleri değerlendirmek için show policy qos-queue / show policy-map interface.
  • Çoklu yayın katılımları ve servis rotaları için show ip igmp groups ve show sdwan omp services. Kritik veriler için kabul edilebilir gecikmeyi korurken ses/videodaki kuyruk sonu düşüşlerini (tail drops) ortadan kaldırmak için şekillendirici (shaper) hızlarını ve kuyruk ağırlıklarını ayarlayın.

8. Korumalar ve anomali yönetimi

• Gerekçe: Tekrarlamayı önleyin ve gerilemeleri tespit edin. Yanlış işaretlenmiş trafiği kısmak (throttle) için güvenilmeyen LAN segmentlerinde giriş denetleyicileri (ingress policer) uygulayın, kontrol düzlemi CPU’sunu korumak için IGMP’yi hız limitine tabi tutun ve proaktif iyileştirmeyi tetiklemek için AAR SLA ihlalleri ve kuyruk düşüşü sayaçları üzerine uyarılar ayarlayın.

Bu sıra, NorthRiver Health’in iş hedeflerini tutarlı, taşıyıcıdan haberdar (transport-aware) QoS’e ve güvenilir çoklu yayın dağıtımına dönüştürmesini sağlar. Ses, katı ve sınırlı bir muamele görür; video ve EMR, önceliklendirilmiş, ağırlıklandırılmış bant genişliği alır; yollar, canlı SLA ölçümlerine göre seçilir; ve çoklu yayın, şube bağlantılarını bunaltmadan verimli bir şekilde çoğaltılır.

← Güvenlik · Tüm alanlar · Bulut →

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