Cisco 300-415: Tunele płaszczyzny danych, BFD i routing świadomy aplikacji — Przewodnik do nauki

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

Część Cisco SD-WAN 300-415 ENSDWI — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Cisco, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Cisco SD-WAN oddziela płaszczyznę sterowania od płaszczyzny danych i buduje szyfrowaną, sterowaną politykami sieć nakładkową (overlay) ponad różnorodnymi mediami transportowymi. Kontroler vSmart zarządza płaszczyzną sterowania sieci nakładkowej i łącznością routerów WAN Edge, dystrybuując trasy, klucze bezpieczeństwa i intencje za pomocą protokołu OMP. Routery WAN Edge tworzą bezpieczne tunele IPsec w płaszczyźnie danych do innych routerów WAN Edge, podczas gdy połączenia sterujące z vSmart, vBond i vManage domyślnie używają DTLS (lub TLS). Żywotność i jakość ścieżek są stale mierzone za pomocą BFD, co zasila polityki Application-Aware Routing (AAR) w celu kierowania ruchem aplikacji przez tunele o najlepszej wydajności, zgodnie z klasami SLA opartymi na utracie pakietów, opóźnieniu, jitterze lub wskaźniku MOS.

Podstawy sieci nakładkowej i płaszczyzny danych

• Płaszczyzna sterowania a płaszczyzna danych

  • Płaszczyzna sterowania: Routery WAN Edge ustanawiają bezpieczne połączenia sterujące DTLS/TLS z vBond (do przechodzenia przez NAT i orkiestracji), vSmart (do wymiany polityk i tras przez OMP) oraz vManage (do zarządzania, konfiguracji urządzeń i przechowywania certyfikatów). W stanie staging (przygotowawczym) urządzenia tworzą połączenia sterujące, ale nie ustanawiają tuneli danych.
  • Płaszczyzna danych: Routery WAN Edge tworzą tunele IPsec bezpośrednio do innych routerów WAN Edge dla ruchu użytkowników. Płaszczyzna danych jest odpowiedzialna za przekazywanie pakietów i egzekwuje decyzje inżynierii ruchu przekazane przez polityki płaszczyzny sterowania.

• Tunele IPsec w płaszczyźnie danych i TLOC

  • Transport Locator (TLOC) jednoznacznie identyfikuje przyłączenie do transportu WAN i jest zdefiniowany przez krotkę {system-IP, color, encapsulation}. Enkapsulacją jest IPsec lub GRE; w większości wdrożeń oraz na IOS XE SD-WAN (cEdge) używany jest IPsec.
  • Kolory (colors) to semantyczne etykiety dla typów sieci bazowej (underlay) i właściwości NAT (na przykład mpls, biz-internet, public-internet, lte, private1–private6). Kolory publiczne (public colors) zazwyczaj oznaczają konieczność przechodzenia przez NAT przy wsparciu vBond.
  • Tunele są tworzone między każdą osiągalną parą TLOC, chyba że jest to ograniczone (restricted). Dla dwóch lokalizacji, z których każda ma jeden router WAN Edge i dwa publiczne TLOC, bez atrybutów restrict, tworzone są cztery tunele IPsec (pełna siatka między parami kolorów).
  • Rozszerzenie TLOC (TLOC extension) pozwala dwóm redundantnym routerom WAN Edge w jednej lokalizacji na współdzielenie transportów przez połączenie krzyżowe (cross-link), co umożliwia redundancję transportu bez duplikowania fizycznych obwodów na każde chassis.

• Etykiety transportowe i usługowe

  • vSmart używa OMP do rozgłaszania tras i TLOC oraz do alokowania etykiet przenoszonych w nagłówku sieci nakładkowej. Etykiety transportowe identyfikują zdalne TLOC w celu demultipleksacji ruchu w sieci nakładkowej. Etykiety usługowe identyfikują docelową usługę VPN lub usługę połączoną łańcuchowo (chained service). Te etykiety są wewnętrzne dla sieci nakładkowej SD-WAN i nie są etykietami MPLS sieci bazowej (underlay).

• Kompromisy operacyjne i tryby awarii

  • Błędnie oznaczone kolorem transporty (np. oznaczenie MPLS jako public-internet) mogą powodować nieoptymalne tworzenie tuneli lub błędy w przechodzeniu przez NAT.
  • Atrybut restrict zapobiega niepożądanemu rozrostowi pełnej siatki (full-mesh); pominięcie go dla kolorów internetowych może prowadzić do nadmiernej skali tuneli i niepotrzebnego narzutu związanego z sondowaniem.
  • Problemy z certyfikatami lub zegarem uniemożliwiają łączność w płaszczyźnie sterowania (DTLS/TLS). Bez konwergencji płaszczyzny sterowania z vSmart, klucze płaszczyzny danych nie są wymieniane, a tunele IPsec nie są tworzone.

Pomiar żywotności i jakości ścieżki za pomocą BFD

• Działanie BFD

  • Cisco SD-WAN uruchamia BFD na każdym tunelu płaszczyzny danych, aby zapewnić wykrywanie żywotności i pomiar jakości w czasie zbliżonym do rzeczywistego. BFD używa lekkich, okresowych pakietów hello do wykrywania stanu up/down (awarie typu blackout) oraz aktywnych sond do pomiaru opóźnienia, jittera i utraty pakietów (degradacje typu brownout).
  • Kluczowe timery i interwały
    • Interwał hello: zazwyczaj 1000 ms (konfigurowalny dla każdego koloru lub globalnie).
    • Mnożnik: zazwyczaj 6 (konfigurowalny), co daje czas wykrycia równy iloczynowi interwału hello i mnożnika (np. ~6 sekund).
    • Interwał sondowania aplikacji (app-probe) dla próbkowania wydajności AAR: typowo 1 sekunda (konfigurowalny), ze średnimi kroczącymi obliczanymi w krótkim oknie czasowym w celu wygładzenia chwilowych skoków.
  • Mierniki BFD
    • Opóźnienie: czas podróży w obie strony (round-trip time) sond na każdym tunelu.
    • Jitter: zmienność opóźnienia między sondami.
    • Utrata pakietów: procent sond, które nie wróciły.
    • MOS: wskaźnik pochodny od opóźnienia, jittera i utraty pakietów, określający przydatność dla transmisji głosu.

• Obsługa degradacji (brownout) a awarii (blackout)

  • Blackout (awaria): Sesja BFD jest w stanie down (brak łączności), co powoduje natychmiastowe usunięcie ścieżki z tablicy przekazywania. Ruch jest przenoszony zgodnie z preferencją następnego dostępnego tunelu, bez oczekiwania na ocenę przez AAR.
  • Brownout (degradacja): Sesja BFD pozostaje w stanie up, ale mierzone wskaźniki naruszają progi SLA. AAR może przekierować określone przepływy aplikacji do alternatywnych tuneli, które spełniają SLA, nawet jeśli oryginalny tunel nadal przenosi inny ruch.

• Wskazówki projektowe i kompromisy

  • Agresywne timery przyspieszają przełączanie awaryjne (failover), ale zwiększają obciążenie procesora i narzut na przepustowość, zwłaszcza w dużych topologiach siatki (mesh). Należy zrównoważyć interwały pakietów hello i sond w stosunku do skali i stabilności transportu.
  • Charakterystyki ścieżek asymetrycznych (np. łącza satelitarne lub komórkowe) wymagają łagodniejszych progów SLA i potencjalnie wyższych mnożników, aby uniknąć niestabilności połączenia (flapping).
  • Dla aplikacji głosowych i interaktywnych preferowane są krótsze interwały sondowania aplikacji (app-probe) oraz włączenie histerezy/czasu wstrzymania (hysteresis/hold-down), aby zredukować oscylacje podczas chwilowego przeciążenia sieci.

Routing Świadomy Aplikacji (AAR): Projektowanie Polityk i SLA

• Identyfikacja i klasyfikacja aplikacji

  • Brzegowe urządzenia WAN używają DPI (NBAR2 w IOS XE SD-WAN) do klasyfikacji aplikacji na podstawie sygnatur, heurystyk protokołów oraz, tam gdzie to możliwe, metadanych takich jak TLS SNI i QUIC ALPN. W przypadku ruchu szyfrowanego bez możliwych do zidentyfikowania metadanych, silnik powraca do atrybutów przepływu (5-krotka) i skonfigurowanych mapowań (porty, DSCP).
  • Klasyfikacja zazwyczaj odbywa się na pierwszych pakietach i jest buforowana w celu zapewnienia spójności sesji. Utrzymuj aktualne sygnatury, aby zachować dokładność.

• Klasy SLA i polityka pomiarów

  • Zdefiniuj klasy SLA z progami dla utraty pakietów, opóźnienia, jittera i opcjonalnie MOS. Każda klasa SLA odwołuje się do profilu sondowania wydajności (app-probe), który steruje interwałem próbkowania i zachowaniem wygładzania przez BFD.
  • Typowe przykłady SLA:
    • Głos: opóźnienie ≤ 150 ms, jitter ≤ 30 ms, utrata ≤ 1%, MOS ≥ 4.0.
    • Transakcyjny: opóźnienie ≤ 200 ms, utrata ≤ 1%.
    • Masowy: brak ścisłego SLA; preferowane ścieżki o wyższej przepustowości i niższym koszcie.

• Zachowanie preferencji ścieżki

  • Polityka AAR wiąże listy aplikacji z klasami SLA i określa preferowany kolor (preferred-color) oraz kolor zapasowy (backup-color) (lub listy TLOC). Logika decyzyjna:
    1. Jeśli preferowana ścieżka spełnia SLA, ruch jest wysyłany tą ścieżką.
    2. Jeśli preferowana ścieżka narusza SLA, ale zapasowa je spełnia, ruch jest kierowany na ścieżkę zapasową.
    3. Jeśli żadna ścieżka nie spełnia SLA, używana jest najlepsza dostępna ścieżka według preferencji lub kosztu (płynna degradacja).
  • Sterowanie w warunkach brownout odbywa się per-przepływ; istniejące przepływy mogą być przenoszone w zależności od polityki (domyślnie sterowanie dotyczy nowych przepływów; przeniesienie w trakcie trwania przepływu może być ograniczone dla TCP, chyba że zaprojektowano odporność sesji).

• Elementy konstrukcji polityki

  • W vManage zbuduj listy aplikacji (grupy DPI), klasy SLA (utrata/opóźnienie/jitter/MOS) oraz listy TLOC (kolory). Następnie utwórz sekwencję polityki AAR mapującą lista-aplikacji → klasa-SLA → preferowane/zapasowe kolory.
  • Połącz z politykami danych o ruchu (traffic data policies), jeśli musisz ustawić DSCP, egzekwować strefy lub wstawić łańcuch usług (service chaining) przed podjęciem decyzji przez AAR.
  • Używaj polityki sterowania (control-policy) oddzielnie, aby wpływać na akceptację/rozgłaszanie tras; nie należy mylić AAR (data-policy) z polityką sterowania (control-policy). Listy lokalizacji (site lists) określają zakres stosowania AAR.

• Kompromisy projektowe

  • Zbyt rygorystyczne SLA mogą powodować oscylacje. Wprowadź histerezę lub liczniki karne (penalty timers), aby uniknąć częstych zmian ścieżek.
  • Weź pod uwagę koszt: umieszczaj rozliczane za zużycie danych ścieżki komórkowe tylko jako zapasowe ścieżki ostatniej szansy; włącz limity danych, jeśli są dostępne.
  • Koordynuj z QoS: AAR wybiera ścieżkę; QoS i kolejkowanie na każdej ze ścieżek muszą nadal chronić krytyczne klasy podczas przeciążenia.

Weryfikacja i rozwiązywanie problemów

• Szybkie sprawdzanie stanu

  • Płaszczyzna sterowania:
    • cEdge: show sdwan control connections
    • vEdge: show control connections
  • Tunele płaszczyzny danych:
    • cEdge: show sdwan tunnels
    • vEdge: show ipsec outbound-connections / show ipsec inbound-connections
  • Sesje BFD i jakość połączenia:
    • cEdge: show sdwan bfd sessions; show sdwan app-route stats
    • vEdge: show bfd sessions; show app-route stats

• Przykładowe fragmenty poleceń

  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

• Na co zwrócić uwagę

  • Stan tunelu to ‘up’, ale utrata pakietów/opóźnienie/jitter w BFD przekracza SLA: sytuacja typu ‘brownout’ — należy spodziewać się przekierowania przez AAR. Sprawdź, czy ścieżka zapasowa spełnia SLA i czy polityka jest powiązana z właściwą listą aplikacji.
  • Niestabilność sesji BFD (flapping): zmniejsz agresywność ustawień lub zbadaj przyczyny odrzucania/kolejkowania pakietów w warstwie ‘underlay’; zweryfikuj MTU i fragmentację (obsługę bitu DF), aby uniknąć utraty sond.
  • Brak tuneli utworzonych przez dany ‘color’: zweryfikuj semantykę ‘color’ (NAT/public/private), konfigurację NAT na interfejsie oraz czy vBond jest osiągalny w celu obsługi NAT traversal. Potwierdź poprawność czasu i certyfikatów, jeśli brakuje połączeń płaszczyzny sterowania.
  • Nieoczekiwana pełna siatka (full-mesh) i skala sondowania: zastosuj ‘restrict’ na ‘color’ internetowych lub użyj list TLOC do ograniczenia łączności.
  • Błędna klasyfikacja przez DPI: zaktualizuj sygnatury NBAR2 i upewnij się, że nie ma konfliktów z nadpisanymi portami L4. Dla aplikacji szyfrowanych rozważ klasyfikację opartą na SNI/ALPN lub znakowanie DSCP w górę strumienia (upstream).

• Logika operacyjna

  • Zawsze najpierw weryfikuj łączność płaszczyzny sterowania (vBond dla orkiestracji/NAT, vSmart dla OMP/polityk, vManage dla konfiguracji/certyfikatów). Bez vSmart klucze płaszczyzny danych nie są dystrybuowane i nie tworzy się żadne IPsec SA.
  • Koreluj decyzje AAR z pomiarami BFD i klasami SLA. Jeśli ścieżka jest wybierana wbrew oczekiwaniom, sprawdź status zgodności z SLA w momencie podejmowania decyzji, a nie tylko bieżące średnie.
  • W projektach z dwoma centrami danych (dual-DC) unikaj zduplikowanych tras LAN poprzez harmonizację numerów AS w warstwie ‘overlay’ na urządzeniach DC WAN Edge podczas redystrybucji OMP↔BGP przez połączenie między centrami danych.

Praktyczny scenariusz problemu

Firma Contoso Health obsługuje 300 klinik, z których każda posiada dwa łącza transportowe: MPLS (‘color’ mpls) i szerokopasmowe (‘color’ biz-internet). Użytkownicy zgłaszają okresowe problemy z jakością połączeń głosowych, podczas gdy aplikacje danych działają poprawnie. Celem jest preferowanie łącza MPLS dla ruchu głosowego, przełączanie awaryjne na łącze szerokopasmowe w przypadku pogorszenia parametrów (‘brownout’) oraz zapewnienie szybkiego przełączania w przypadku całkowitej awarii (‘blackout’) bez oscylacji.

1. Weryfikacja stanu ‘overlay’ i tworzenia płaszczyzny danych

• Uzasadnienie: Potwierdzenie warunków wstępnych. Użyj polecenia show sdwan control connections, aby upewnić się, że połączenia DTLS/TLS do vSmart/vBond/vManage są stabilne, oraz show sdwan tunnels, aby zweryfikować pełną siatkę tuneli przez MPLS i łącze szerokopasmowe. Jeśli brakuje tuneli przez biz-internet, sprawdź przypisanie ‘color’ i konfigurację NAT; vBond musi być osiągalny w przestrzeni publicznej, aby wspomóc NAT traversal.

2. Kalibracja timerów BFD i sond

• Uzasadnienie: Ustaw interwał BFD hello na 1000 ms i mnożnik na 6, aby uzyskać zrównoważone wykrywanie aktywności (~6 s) i rozsądną skalę. Skonfiguruj interwał sondowania aplikacji (app-probe interval) na 1 s w celu terminowego wykrywania ‘brownout’. Zbyt agresywne timery mogą powodować obciążenie procesora i niestabilność (flapping); zbyt łagodne opóźniają reakcję na problemy z ruchem głosowym.

3. Definiowanie klas SLA

• Uzasadnienie: Utwórz klasę SLA Voice-SLA z opóźnieniem ≤ 150 ms, jitterem ≤ 30 ms, utratą pakietów ≤ 1% i MOS ≥ 4.0. Utwórz klasę Data-SLA z opóźnieniem ≤ 200 ms i utratą pakietów ≤ 1%. Te progi odzwierciedlają wrażliwość ruchu głosowego i typową wydajność sieci WAN; MOS konsoliduje doświadczenie użytkownika na podstawie wielu metryk.

4. Tworzenie list aplikacji

• Uzasadnienie: Użyj DPI (NBAR2), aby zdefiniować App-List-Voice dla ruchu SIP/RTP/Teams/Zoom oraz App-List-Data dla aplikacji transakcyjnych. Uwzględnij wzorce TLS SNI/QUIC ALPN dla nowoczesnych platform głosowych/wideo. Gdy klasyfikacja jest niepewna, należy oprzeć się na znakowaniach DSCP EF/AF41 wymuszanych na brzegu sieci LAN.

5. Konstruowanie polityki AAR

• Uzasadnienie: Przypisz App-List-Voice do Voice-SLA z preferowanym ‘color’ mpls i zapasowym ‘color’ biz-internet. Przypisz App-List-Data do Data-SLA z preferowanym ‘color’ biz-internet i zapasowym ‘color’ mpls, aby oszczędzać przepustowość łącza MPLS. Zapewnia to, że ruch głosowy korzysta z MPLS, gdy łącze jest w dobrym stanie, i przełącza się na łącze szerokopasmowe tylko podczas ‘brownout’ lub ‘blackout’, podczas gdy ruch danych preferuje bardziej opłacalny internet.

6. Dodawanie histerezy i ‘hold-down’

• Uzasadnienie: Skonfiguruj ‘revert timer’, aby ruch głosowy wracał na łącze MPLS dopiero po utrzymaniu zgodności z SLA przez określony czas (na przykład 30–60 s). Pozwala to uniknąć oscylacji podczas przejściowych skoków jittera. Podobnie, zastosuj karę (penalty) lub tłumienie (dampening) dla łącza szerokopasmowego, jeśli wielokrotnie narusza ono SLA w krótkim oknie czasowym.

7. Koordynacja QoS i MTU

• Uzasadnienie: Na obu łączach transportowych upewnij się, że kolejkowanie EF i ‘shaping’ są zgodne z przepustowością łączy. Niezgodność może zawyżać wartości jittera/utraty pakietów widziane przez sondy BFD i ruch głosowy RTP. Zweryfikuj Path MTU i wyłącz bit DF tam, gdzie fragmentacja jest nieunikniona, aby zapobiec odrzucaniu sond, co mogłoby być mylnie interpretowane jako utrata pakietów.

8. Weryfikacja i iteracja

• Uzasadnienie: Użyj polecenia show sdwan app-route stats sla-class Voice-SLA, aby potwierdzić spełnienie/niespełnienie SLA dla każdego tunelu. Obserwuj przepływy na żywo za pomocą polecenia show sdwan app-route statistics flows, aby upewnić się, że ruch głosowy jest kierowany do MPLS i przełącza się na łącze szerokopasmowe tylko wtedy, gdy MPLS narusza SLA. Podczas testów celowo wywołaj przeciążenie na łączu MPLS, aby zweryfikować zachowanie w sytuacji ‘brownout’, a następnie zmierz czas powrotu na łącze podstawowe.

Postępując zgodnie z tymi krokami, Contoso Health zapewnia, że BFD umożliwia szybkie wykrywanie awarii (‘blackout’), AAR reaguje na pogorszenie parametrów (‘brownout’) przy użyciu precyzyjnych klas SLA, a DPI dokładnie klasyfikuje aplikacje głosowe. Ta kombinacja zapewnia przewidywalną jakość głosu, efektywne wykorzystanie łącz transportowych i kontrolowane zachowanie przełączania awaryjnego w całej infrastrukturze SD-WAN.

← Konfiguracja urządzeń WAN Edge i zarządzanie szablonami · Wszystkie domeny · Scentralizowane polityki i inżynieria ruchu →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →