Cisco 300-415: Scentralizowane polityki i inżynieria ruchu — 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

Scentralizowana polityka w Cisco SD-WAN to framework, który pozwala programować zachowanie ruchu i intencje routingowe z poziomu kontrolerów vSmart w całej strukturze. vSmart, który zarządza płaszczyzną sterowania nakładki (overlay) za pomocą OMP, dystrybuuje scentralizowaną politykę sterowania (dla tras OMP i TLOC) oraz polityki płaszczyzny danych, takie jak polityki danych, routingu opartego na aplikacjach (app-route) i cflowd. Polityki te kształtują topologię (hub-and-spoke, ograniczenia siatki), wybierają ścieżki na podstawie wydajności aplikacji, kierują przepływy do usług i segmentują ruch według sieci VPN. Ponieważ polityki mogą zmieniać zarówno osiągalność w płaszczyźnie sterowania, jak i przekazywanie w płaszczyźnie danych, staranne projektowanie, podgląd i wdrażanie etapowe są niezbędne, aby uniknąć awarii.

Typy i elementy składowe scentralizowanych polityk

• Scentralizowana polityka sterowania

  • Zakres: Płaszczyzna sterowania (OMP) między urządzeniami WAN Edge a vSmart.
  • Cel: Filtrowanie/modyfikowanie rozgłoszeń tras OMP i TLOC, ustawianie atrybutów (preferencja, tag, pochodzenie, TLOC) oraz budowanie topologii (hub-and-spoke, częściowa siatka).
  • Kierunek: Przychodzący (do vSmart z WAN Edge) i wychodzący (z vSmart do WAN Edge).

• Scentralizowana polityka danych

  • Zakres: Klasyfikacja w płaszczyźnie danych (L3/L4, pola, ID aplikacji) na urządzeniu WAN Edge, instalowana przez vSmart.
  • Cel: Zezwalanie/odrzucanie przepływów, ustawianie VPN, TLOC, DSCP/znaczników, limitowanie (police), kopiowanie (mirror) oraz wstawianie/łańcuchowanie usług (service insertion/chaining).
  • Kierunek: Oceniana na urządzeniu WAN Edge względem strony usługowej (LAN) lub strony tunelowej (WAN), w zależności od miejsca jej zaprogramowania; projekty zazwyczaj celują w ruch przychodzący po stronie usługowej dla przepływów od użytkownika do sieci WAN oraz w ruch przychodzący po stronie tunelowej dla ruchu powrotnego, jeśli wymagane jest zachowanie symetryczne.

• Polityka routingu opartego na aplikacjach (app-route)

  • Zakres: Wybór ścieżki w płaszczyźnie danych na podstawie aplikacji i SLA (straty, opóźnienie, jitter) mierzonych przez BFD.
  • Cel: Kierowanie ruchu do preferowanych TLOC/kolorów, definiowanie klas SLA opartych na sondach, ustawianie ścieżek zapasowych (fallback) oraz realizowanie dynamicznej inżynierii ruchu dla poszczególnych aplikacji/rodzin aplikacji.
  • Kluczowe zachowanie: Ciągle ocenia wydajność ścieżki; może przełączać ścieżki, gdy SLA ulega pogorszeniu.

• Polityka cflowd

  • Zakres: Telemetria przepływów (podobna do IPFIX/NetFlow) generowana przez urządzenia WAN Edge.
  • Cel: Włączanie/wyłączanie eksporterów dla poszczególnych sieci VPN, definiowanie częstotliwości próbkowania, szablonów i kolektorów (vManage lub zewnętrznych).
  • Uwaga projektowa: Próbkowanie musi równoważyć widoczność z narzutem na CPU i przepustowość; włączanie dla poszczególnych sieci VPN wspiera segmentowane raportowanie.

Listy polityk to obiekty dopasowania wielokrotnego użytku:

• Lista lokalizacji (Site list): Identyfikatory lokalizacji używane do wyboru miejsca dołączania polityk oraz do dopasowywania lokalizacji źródłowych/docelowych tras.
• Lista VPN (VPN list): VRF-y (VPN) używane do segmentacji zakresu polityki i budowania reguł dla poszczególnych segmentów.
• Lista prefiksów (Prefix list): Prefiksy IP do dopasowywania tras OMP lub ruchu danych.
• Lista prefiksów danych (Data prefix list): Wyspecjalizowany obiekt prefiksów do klasyfikacji w polityce danych.
• Lista TLOC (TLOC list): Krotki składające się z adresu IP systemu, koloru i enkapsulacji, używane do dopasowywania lub ustawiania atrybutów TLOC.
• Lista kolorów (Color list): Jeden lub więcej kolorów transportu (np. biz-internet, mpls, public-internet) do targetowania/ustalania koligacji z łączem.
• Lista aplikacji (Application list): Aplikacje/grupy NBAR2 do klasyfikacji ruchu dla polityk app-route lub polityk danych.
• Klasa SLA (SLA class): Progi opóźnienia, strat i jittera powiązane z app-route w celu kierowania ruchem na podstawie wydajności.

Struktura i ocena sekwencji polityk:

• Sekwencje są uporządkowane, obowiązuje pierwsze dopasowanie. Każda sekwencja zawiera:
  • Warunki dopasowania: Listy/pola (lokalizacja/VPN/prefiks/TLOC/kolor/aplikacja, porty L4, DSCP, protokół).
  • Akcje: Akceptuj/odrzuć, ustaw atrybuty (TLOC, VPN, DSCP, preferencja, tag), wstawianie usług, limitowanie (police), kopiowanie (mirror).
• Akcja domyślna: Stosowana, jeśli żadna sekwencja nie zostanie dopasowana. Powszechnymi akcjami domyślnymi są akceptacja (dla polityk sterowania/danych), aby uniknąć niezamierzonych odrzuceń; jawne domyślne odrzucenie jest używane celowo i wymaga starannej walidacji.
• Kierunek:
  • Kierunek polityki sterowania jest określany na poziomie vSmart (przychodzący/wychodzący OMP).
  • Polityki danych i app-route działają na ruchu na urządzeniu WAN Edge; wybierz zachowanie po stronie usługowej lub tunelowej, aby dopasować je do przepływu, na który chcesz wpłynąć, i zapewnij symetrię ruchu powrotnego, gdy na ścieżce znajdują się usługi stanowe.

Projektowanie polityk płaszczyzny sterowania i manipulacja trasami/TLOC

Polityka sterowania (control policy) jest głównym narzędziem do kształtowania topologii nakładkowej (overlay), ponieważ określa, które trasy OMP i TLOC-i dana lokalizacja może wysyłać lub odbierać:

• Manipulacja trasami OMP

  • Użyj przychodzącej polityki sterowania (inbound control policy) do filtrowania, tagowania lub ustawiania atrybutów na trasach otrzymanych z lokalizacji, zanim wejdą one do tablicy RIB nakładki na vSmart.
  • Użyj wychodzącej polityki sterowania (outbound control policy), aby ograniczyć, które trasy są rozgłaszane do określonych lokalizacji (np. nie rozgłaszaj prefiksów nauczonych od spoke’ów do innych spoke’ów).
  • Częste akcje: ustawienie preferencji (wpływa na wybór najlepszej ścieżki OMP), ustawienie tagu (do późniejszego dopasowywania), ustawienie pochodzenia (origin), ustawienie ograniczeń dotyczących lokalizacji pochodzenia (site-of-origin).

• Manipulacja TLOC

  • Dopasowuj atrybuty TLOC (system IP, color, encap), aby filtrować lub preferować określone transporty.
  • Akcje obejmują zmianę preferowanych atrybutów TLOC lub preferencji, aby rozgłoszenia tras faworyzowały dany kolor (np. preferuj MPLS dla krytycznych podsieci).
  • Kompromis: Zbyt agresywne filtrowanie TLOC może odizolować lokalizacje, jeśli pozostały transport ulegnie awarii. Preferuj dostrajanie atrybutów zamiast ogólnego blokowania (blanket deny), chyba że posiadasz redundantne ścieżki.

• Wzorce topologii

  • Hub-and-spoke: Wychodząca polityka sterowania z vSmart do lokalizacji spoke blokuje rozgłaszanie tras pochodzących od spoke’ów do innych spoke’ów; huby odbierają i rozgłaszają wszystko.
  • Ograniczenie siatki (mesh): Podobne do hub-and-spoke, ale zezwala na komunikację określonych par spoke-spoke (np. regionalne siatki) poprzez wyjątki w sekwencjach polityki.
  • Segmentacja: Połącz listy VPN z filtrowaniem tras, aby utrzymać izolację nakładek per-VPN; rozgłaszaj tylko trasę domyślną lub wybrane prefiksy do lokalizacji o ograniczonym dostępie.

Scenariusze awarii i kompromisy:

• Błędnie zastosowana wychodząca polityka sterowania z domyślnym blokowaniem (deny default) może wycofać krytyczne trasy, izolując lokalizacje. Zawsze stosuj domyślne zezwolenie (default accept) i dodawaj ukierunkowane blokady, chyba że podgląd polityki (preview) jawnie potwierdza jej prawidłowe działanie.
• Zmiana atrybutów OMP na dużą skalę może wywołać niestabilność tras (route churn); rozłóż wdrożenie w czasie, wdrażając na poszczególne listy lokalizacji, aby zmniejszyć obciążenie płaszczyzny sterowania.
• Zmiana atrybutów TLOC może prowadzić do asymetrycznego przesyłania ruchu, jeśli ścieżka powrotna nie jest zmodyfikowana w analogiczny sposób; zweryfikuj oba kierunki.

Application-Aware Routing, wstawianie usług i segmentacja

Application-aware routing (AAR) wraz z polityką danych (data policy) zapewniają szczegółową inżynierię ruchu:

• AAR i sterowanie ruchem

  • Klasy SLA definiują akceptowalną utratę pakietów/opóźnienie/jitter; sondy BFD dla każdej pary TLOC dostarczają pomiary w czasie rzeczywistym.
  • Polityka app-route dopasowuje aplikacje lub pola L3/L4 i wybiera preferowane listy kolorów/TLOC; jeśli SLA zostanie naruszone, następuje przełączenie awaryjne (failover) zgodnie z polityką.
  • Wskazówki projektowe:
    • Unikaj zbyt restrykcyjnych progów SLA, które powodują niestabilność (flapping); uwzględnij histerezę, używając mnożników sond i rozsądnych progów.
    • Dla aplikacji wrażliwych na zmianę kolejności pakietów, preferuj opcję „przełącz przy następnym nowym przepływie” (move on next new flow) zamiast przełączania w trakcie trwania przepływu, lub przypinaj przepływy za pomocą consistent hashing, jeśli jest to wspierane.
    • Gdy zarówno AAR, jak i polityka danych ustawiają TLOC, przyznaj priorytet AAR w wyborze ścieżki, a politykę danych wykorzystaj do wstawiania usług/znakowania; unikaj nakładających się akcji w tej samej klasie ruchu.

• Łańcuchy usług (service chaining) i wstawianie usług

  • Akcja „service” w polityce danych wstawia ruch przez usługi on-premise lub w kolokacji (firewall, IDS/IPS, węzły usługowe SD-WAN).
  • Łącz wiele usług w wymaganą sekwencję; zapewnij symetryczne wstawianie dla usług stanowych (stateful) zarówno na ścieżce wychodzącej, jak i powrotnej.
  • Kompromisy: Każdy przeskok przez usługę dodaje opóźnienie i potencjalne domeny awarii. Zaimplementuj mechanizmy sprawdzania stanu (health checks) oraz zachowania fail-open/closed zgodne z polityką bezpieczeństwa.

• Segmentacja ruchu

  • Sieci VPN zapewniają twardą segmentację; scentralizowana polityka jest stosowana per-VPN przy użyciu list VPN.
  • Routing między sieciami VPN (route leaking) można osiągnąć za pomocą polityki danych, używając akcji „set VPN” dla określonych przepływów; ściśle ograniczaj to dopasowaniami prefiksów/aplikacji i często audytuj.
  • Dla usług współdzielonych (np. DNS, tożsamość), rozgłaszaj prefiksy usług z dedykowanej sieci VPN dla usług do sieci VPN konsumentów za pomocą polityki sterowania, zamiast stosować szerokie przecieki w płaszczyźnie danych.

Przykładowy fragment polityki app-route ilustrujący sterowanie oparte na SLA:

app-route-policy CRITICAL-APPS
  sequence 10
    match application-list BUS_APPS
    sla-class GOLD
    preferred-color mpls fallback biz-internet
  !
  sequence 20
    match application-list BEST_EFFORT
    sla-class BRONZE
    preferred-color biz-internet fallback public-internet
  !
  default-action accept
!

Operacje: dołączanie, walidacja i rozwiązywanie problemów

Dołączanie polityk przez vSmart:

• Zdefiniuj scentralizowane polityki w vManage i dołącz je do list lokalizacji (site lists) i list VPN. vSmart kompiluje politykę i dystrybuuje ją do urządzeń WAN Edge za pośrednictwem bezpiecznych sesji DTLS/TLS OMP w VPN 0.
• Ostrożnie określaj zakres zmian; pojedyncza instancja polityki może wpłynąć na setki lokalizacji. Używaj list lokalizacji do etapowego wdrażania według regionu lub funkcji.

Symulacja, podgląd i etapowe wdrażanie polityk:

• Podgląd (Preview): Przed aktywacją użyj podglądu w vManage, aby sprawdzić skompilowaną politykę specyficzną dla urządzenia (co otrzyma każdy WAN Edge). Potwierdź logikę dopasowania/akcji (match/action), domyślne akcje i kierunki.
• Symulacja (Simulation): Użyj symulacji polityk, aby przetestować dopasowania przepływów i oczekiwane akcje (np. którego TLOC użyje dana aplikacja/5-krotka). Zweryfikuj mapowania klas SLA i klasyfikację aplikacji.
• Wdrażanie etapowe (Staged deployment):
  • 1. Dołącz do listy lokalizacji typu „kanarek” (canary site list) (kilka lokalizacji).
  • 2. Monitoruj wskaźniki KPI płaszczyzny sterowania i danych (liczba tras OMP, BFD, trafienia app-route).
  • 3. Stopniowo rozszerzaj listę lokalizacji.
• Wersjonowanie i wycofywanie (rollback): Utrzymuj poprzednie wersje polityk; jeśli wykryte zostanie nieoczekiwane zachowanie, natychmiast dezaktywuj nową politykę lub przywróć poprzednią wersję.

Debugowanie niezamierzonych wyników i pierwszeństwa:

• Weryfikacja płaszczyzny sterowania

  • show omp tlocs, show omp routes: Potwierdź obecność/brak tras i TLOC zgodnie z intencją polityki.
  • show policy received/installed: Sprawdź liczniki polityki sterowania i które sekwencje zostały dopasowane.
  • Symptom: Oddziały (spokes) nie mogą komunikować się z innymi po wdrożeniu → sprawdź linie deny w wychodzącej polityce sterowania do oddziałów oraz domyślne akcje.

• Weryfikacja płaszczyzny danych i AAR

  • show app-route stats/flows i show bfd sessions: Zweryfikuj stan SLA i decyzje dotyczące wyboru ścieżki.
  • show sdwan policy service-path lub odpowiednik: Potwierdź liczniki wstawiania usług (service insertion) i kolejność łączenia w łańcuch (chaining).
  • show ip route vpn X i traceroute vpn X: Sprawdź rzeczywistą ścieżkę przekazywania pakietów.
  • Symptom: Nieoczekiwane zmiany ścieżki/flapping → złagodź wymagania SLA lub dostosuj mnożniki sond (probe multipliers); upewnij się, że nakładająca się polityka danych nie ustawia również TLOC.

• Pierwszeństwo i konflikty polityk

  • Decyzje AAR zazwyczaj mają pierwszeństwo przy wyborze ścieżki; używaj polityki danych głównie do wstawiania usług, znakowania (marking) i kontroli dostępu.
  • Nakładające się kryteria dopasowania w różnych politykach mogą tworzyć niejednoznaczność. Utrzymuj wzajemnie wykluczające się domeny dopasowania lub wprowadź kolejność i tagi, aby usunąć niejednoznaczność.
  • Domyślna akcja accept może maskować brakujące sekwencje; dodaj jawne liczniki „tylko do obserwacji” (np. mirror/police low) lub tymczasowe logowanie, aby zweryfikować dopasowania przed wdrożeniem reguł deny.

• Walidacja cflowd

  • show cflowd statistics/exporters: Upewnij się, że eksportery dla poszczególnych VPN są aktywne i próbkowanie (sampling) działa zgodnie z zamierzeniami.
  • Wysokie użycie CPU po włączeniu cflowd → zwiększ interwał próbkowania lub ogranicz go do niezbędnych VPN/aplikacji.

Praktyczny scenariusz problemowy

Firma Northwind Traders migruje do Cisco SD-WAN i musi wdrożyć topologię hub-and-spoke dla sieci VPN zgodnych z PCI, kierować ruch Office 365 najlepszą ścieżką internetową oraz wstawić regionalną usługę firewalla dla ruchu gości, nie wpływając na krytyczne aplikacje.

Podejście:

1. Zbuduj listy dla polityk

   • Utwórz listy lokalizacji (site lists): HUBS (centra danych), SPOKES (oddziały).
   • Utwórz listy VPN: PCI_VPN, GUEST_VPN, CORP_VPN.
   • Utwórz listy aplikacji: O365, BEST_EFFORT.
   • Utwórz listy kolorów (color lists): PRIVATE (mpls), DIA (biz-internet, public-internet). Uzasadnienie: Listy wielokrotnego użytku pozwalają na precyzyjne określenie zakresu i bezpieczne, etapowe wdrożenie; rozdzielenie VPN wspiera segmentację.

2. Zdefiniuj klasy SLA

   • GOLD: utrata pakietów 0,5%, opóźnienie 100 ms, jitter 20 ms.
   • SILVER: utrata pakietów 1%, opóźnienie 150 ms, jitter 30 ms. Uzasadnienie: Dopasuj progi do realistycznej wydajności transportu, aby zapobiec niestabilności ścieżki (path flapping); bardziej rygorystyczne dla O365 niż dla ruchu best-effort.

3. Zaimplementuj politykę sterowania dla topologii hub-and-spoke w sieci PCI

   • Ruch przychodzący do vSmart: oznacz tagiem trasy otrzymane od oddziałów (SPOKES) w PCI_VPN.
   • Ruch wychodzący z vSmart: do oddziałów (SPOKES) rozgłaszaj trasy z hubów (HUB) i trasy domyślne; blokuj rozgłaszanie tras PCI pochodzących z oddziałów do innych oddziałów; do hubów (HUBS) rozgłaszaj wszystko. Uzasadnienie: Topologia jest wymuszana na płaszczyźnie sterowania, co zapewnia, że oddziały uczą się o sobie nawzajem tylko przez huby i zachowuje segmentację w sieci PCI VPN.

4. Utwórz politykę app-route dla O365 i ruchu best-effort

   • Dopasuj O365 w CORP_VPN do klasy GOLD SLA; preferowany kolor DIA z awaryjnym (fallback) PRIVATE.
   • Dopasuj BEST_EFFORT do klasy SILVER; preferowany PRIVATE z awaryjnym (fallback) DIA. Uzasadnienie: O365 działa najlepiej przez bezpośrednie połączenie internetowe (DIA), gdy spełnione jest SLA; w razie potrzeby przełączaj awaryjnie na MPLS. Ruch best-effort może preferować MPLS ze względu na koszty/politykę, jednocześnie pozwalając na awaryjne użycie DIA.

5. Wstaw regionalny firewall dla ruchu gości

   • Polityka danych w GUEST_VPN: wstawienie usługi (service insertion) do łańcucha usług regionalnego firewalla w obu kierunkach – do przodu (od strony usługi do WAN) i powrotnym (z tunelu do usługi).
   • Upewnij się, że stan usługi firewalla jest monitorowany; zdefiniuj fail-open dla przypadku użycia gości, aby zachować dostępność. Uzasadnienie: Inspekcja stanowa (stateful inspection) wymaga symetrycznego przepływu ruchu; dwukierunkowe wstawienie usługi zapobiega zrywaniu sesji. Tolerancja ryzyka dla gości pozwala na fail-open, jeśli usługa jest niedostępna.

6. Dołącz polityki przez vSmart z etapowym wdrożeniem

   • Dołącz politykę sterowania do hubów (HUBS) i do podzbioru „kanarkowego” (canary) oddziałów (SPOKES) w PCI_VPN.
   • Dołącz polityki app-route i danych najpierw do ograniczonego regionu. Uzasadnienie: Ogranicza promień rażenia (blast radius); waliduje zachowanie polityki przed globalnym wdrożeniem.

7. Zweryfikuj i monitoruj

   • Wykonaj podgląd skompilowanych polityk dla każdego urządzenia; potwierdź domyślne akcje.
   • Użyj symulacji do przetestowania przykładowych przepływów (ruch O365 z oddziału w CORP_VPN, ruch webowy gości z GUEST_VPN).
   • Monitoruj show omp routes/tlocs (osiągalność PCI), show app-route stats (ścieżka O365), show policy service-path (liczniki firewalla dla gości) oraz sesje BFD. Uzasadnienie: Potwierdza, że wyniki zarówno na płaszczyźnie sterowania, jak i danych są zgodne z projektem, a sterowanie ruchem oparte na SLA działa zgodnie z oczekiwaniami.

8. Rozszerz i wzmocnij zabezpieczenia

   • Stopniowo dodawaj pozostałe oddziały (SPOKES) do dołączonej polityki sterowania.
   • Zaostrz politykę dla gości, dodając limity przepustowości (rate limits); dostosuj progi SLA dla O365, jeśli występują oscylacje ścieżki. Uzasadnienie: Iteracyjne dostrajanie zmniejsza ryzyko operacyjne i zapewnia stabilne doświadczenie użytkownika.

Ta sekwencja w czytelny sposób oddziela kontrolę topologii (OMP) od sterowania ruchem na płaszczyźnie danych i usług, wykorzystuje segmentację do ochrony środowiska PCI, stosuje routing aplikacji oparty na SLA w celu zapewnienia wydajności oraz utrzymuje bezpieczeństwo operacyjne poprzez podgląd, symulację i etapowe dołączanie polityk.

← Tunele płaszczyzny danych · Wszystkie domeny · Bezpieczeństwo →

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