NetCLI

Blog

  • (T) Teoria protokołu SNMP*

    (T) Teoria protokołu SNMP*

    Wprowadzenie do protokołu SNMP

    Podstawowe zagadnienia dotyczące protokołu SNMP

    • Agent SNMP – Oprogramowanie działające na przełączniku bądź innym urządzeniu sieciowym. Zbierające oraz przechowujące informacje zebrane na temat konfiguracji oraz statusu lokalnego urządzenia.
    • Manager SNMP – Urządzenie zbierające informacje, od wszystkich skonfigurowanych agentów SNMP.
    • NMS (Network Management Station) – Oprogramowanie pobierające informacje od agentów SNMP.
    • MIB (Management Information Base) – Lokalna baza agenta SNMP, zawierającą zmienne określające poszczególne parametry lokalnego urządzenia. Pośród różnych wartości MIB istnieją zmienne uniwersalne dostępne na większości urządzeń jak i te unikalne dla danego producenta czy konkretnej wersji oprogramowania.

    Proces wymiany danych pomiędzy agentem a menadżerem SNMP

    • Menadżer NMS systematycznie wysyła zapytania Get Request, w celu pobrania wartości zmiennych zapisanych w bazie MIB, agentów SNMP. Po zweryfikowaniu poziomu dostępu, agent odsyła odpowiedź w formie wiadomości Get Response, zawierającą wartość zmiennej bądź wielu zmiennych pobranych z bazy MIB.
    • Menadżer NMS systematycznie wysyła wiadomości Get w celu pobrania najnowszych informacji na temat śledzonego agenta. Metoda ta nie zapewnia jednak monitoringu w czasie rzeczywistym, aby go osiągnąć agent SNMP musi mieć włączoną opcję wysyłania wiadomości Trap bądź Inform. Dzięki której zyskuje możliwość informowania menadżera NMS o ważnych wydarzeniach w czasie rzeczywistym.
    • Komunikacja pomiędzy agentem a menadżerem NMS może być również inicjowana z poziomu agenta SNMP, w takim przypadku wysyła on notyfikację (Notification) za pomocą wiadomości Trap bądź wiadomości Inform. Komunikacja ta może być zainicjowana przekroczeniem określonego progu wartości zmiennej bazy MIB bądź zajściem nagłego zdarzenia związanego np. z bezpieczeństwem monitorowanego urządzenia. Przykładową sytuacją obligującą agenta SNMP do wysłania wiadomości Trap może być zmiana statusu interfejsu sieciowego z Up na Down.
    Wiadomości Trap oraz Inform są wysyłana za pomocą protokołu UDP na porcie 162.
    Wiadomości Get oraz Set są wysyłana za pomocą protokołu UDP na porcie 161.

    Wiadomości wykorzystywane przez protokół SNMP

    • Wiadomość Trap – Tak samo jak wiadomość Inform, ma za zadanie informować menadżera NMS o ważnych zmiana zachodzących w bazie MIB agenta protokołu SNMP. Chodź obydwie wiadomości mają podobny cel, różnią się w metodzie działania. Wiadomość Trap kieruje się zasadą „Fire-and-Forget” co oznacza, że po wysłaniu wiadomości agent SNMP nie oczekuje otrzymania potwierdzenia o dotarciu danych od menadżera NMS.
    • Wiadomość Inform – Tak samo jak wiadomość Trap wykorzystuje protokołu UDP w warstwie transportowej, jednak w tym przypadku komunikacja pomiędzy agentem menadżerem a SNMP wzbogacona jest o aplikacyjnie zaimplementowaną osiągalność. Tym samym każda wysłana wiadomość Inform musi być potwierdzona.
    • Wiadomość Get Request – Stanowi żądanie o wartość konkretnej zmiennej MIB.
    • Wiadomość Get Next Request – Stanowi żądanie kolejnej wartości, następującej po tej która została otrzymana.
    • Wiadomość Get Bulk Request – Stanowi żądanie o całą tablicę bądź wartość szeregu zmiennych MIB.
    • Wiadomość Get Response – Stanowi odpowiedź na wiadomości Get Request oraz Get Bulk jak i Get Next.
    • Wiadomość Set Response – Stanowi żądanie o zmianę wartości, konkretnej zmiennej MIB.
    • Wiadomości Get a wersje protokołu SNMP:
      • Get Request, Get Next oraz Get Response wspierają wszystkie wersje protokołu SNMP.
      • Get Bulk wspiera jedynie wersja druga oraz trzecia protokołu SNMP (SNMPv2, SNMPv3).

    Zabezpieczanie protokołu SNMP

    • Według zasady „Best Practices” dostęp do agenta SNMP, powinien być zabezpieczony za pomocą listy dostępu ACL, tak aby tylko zaufane stacje NMS mogły pobierać dane z bazy MIB bądź modyfikować jej zawartość.
    • Protokół SNMP w wersji pierwszej (SNMPv1) wykorzystuje mechanizm autentykacji urządzeń za pomocą hasła (Communities) zapisywanego w postaci czystego tekstu (Community String). Hasła wysyłane są za pomocą wiadomości Get bądź Set przy każdej operacji wykonywanej przez menadżera na agencie SNMP.
    • Protokół SNMP w wersji pierwszej określa poziom dostępu menadżera NMS do agenta za pomocą trybu RO (Read-only community) bądź trybu RW (Read-Write community). W przypadku opcji RO agent zezwala na otrzymywanie jedynie wiadomości Get natomiast w przypadku trybu RW przepuszcza zarówno wiadomości pobierające wartości zmiennych z bazy MIB (Get Request) jak i te mające możliwość wprowadzania zmian w bazie (Set Response).
    • Protokół w wersji drugiej (SNMPv2) w swojej pierwotnej wersji nie posiadał podziału na (communities RO oraz RW) jednak jego poprawiona wersja (SNMPv2c) przywróciła usuniętą funkcjonalność protokołu SNMPv1.
    • Protokół SNMP w wersji trzeciej (SNMPv3) ponownie wykluczył podział na (communities RO oraz RW), dodając w zamian szereg funkcjonalności mających zadbać o bezpieczeństwo wymienianych danych. Funkcje te są następujące:
      • Funkcja Message Integrity – Zaimplementowana we wszystkich rodzajach wiadomości SNMPv3, bada czy wysłana wiadomość uległa zmianie, podczas transmisji pomiędzy menadżerem a agentem SNMP.
      • Funkcja Authentication – Zapewnia dodatkową autentykację przy użyciu loginu oraz za-haszowanego hasła.
      • Funkcja Encryption (Privacy) – Zapewnia dodatkowe szyfrowanie zawartości wiadomości SNMPv3.

    Porównanie wiadomości Get, Trap & Set, Inform

    • Wiadomości Get / Set odnoszą się do komunikacji menadżer NMS -> Agent SNMP.
    • Wiadomości Trap / Inform odnoszą się do komunikacji Agent SNMP -> menadżer NMS.

    MIB – Management Information Base

    Struktura bazy MIB

    • Każdy agent protokołu SNMP posiada swoją własną lokalną bazę MIB, zawierającą informację dotyczące lokalnego urządzenia w postaci zmiennych. Każda zmienna nazywana jest przez protokół SNMP obiektem, posiadającym unikalną wartość ID zwaną OID (Object ID).
    • W przypadku przełączników Cisco Catalyst, baza MIB jest na bieżąco aktualizowana danymi zbieranymi w czasie rzeczywistym, następnie dane te są zapisywane w pamięci urządzenia.
    • Baza MIB posiada zorganizowaną strukturę, w której wartości OID są poukładane w formie drzewa, a zapisywane w postaci ciągu liczb oddzielonych od siebie kropkami, przykładowa wartość wygląda następującą 1.3.6.1.4.1.9.2.1.58.0.
    • Każda baza MIB jest napisana w języku ASN.1 (Abstract Syntax Notation 1).

    Znaczenie przykładowej wartości OID

    • Wartość OID: 1.3.6.1.4.1.9.9.10
      • 1 – Iso, 3 – Org, 6 – Dod, 1 – Internet, 4 – Private, 1 – enterprises, 9 – Cisco, 9 – Cisco mgmt, 10 – Cisco flash group.

    Wersje protokołu SNMP

    • SNMPv1 (RFC 1157).
    • SNMPv2c (RFC 1901).
    • SNMPv3 (RFC 3410–3415).

    SNMPv1 SNMPv2 SNMPv3
    Wspiera GET, nie wspiera GET-BULK Wspiera GET jak i GET-BULK Wspiera GET jak i GET-BULK
    Wykorzystuje uwierzytelnianie za pomocą strink Wykorzystuje uwierzytelnianie za pomocą community strink Wykorzystuje uwierzytelnianie za pomocą nazwy użytkownika
    Nie wspiera szyfrowaniaNie wspiera szyfrowaniaWspiera szyfrowanie

    Protokół SNMP w wersji trzeciej

    Protokół SNMPv3

    • Protokół SNMP w wersji trzeciej nie wykorzystuje znanego ze wcześniejszych wersji protokołu SNMP, podziału na (communities), w zamian za to oferując podział na grupy oraz użytkowników. Inną dodatkową funkcjonalnością protokołu SNMPv3 jest opcjonalna Enkrypcja wysyłanych wiadomości (Message Encryption), Jak i ogólna poprawa bezpieczeństwa uzyskana przy pomocy każdorazowej weryfikacji integralności (Message Integrity) lub opcjonalnej autentykacji (Message Authentication).
    • Jedną z podstawowych zmian wprowadzonych w protokole SNMPv3, jest nowe podejście do zarządzania bazą MIB. Nowy protokół wykorzystuje system widoków (SNMP Views), określających jakie dane na temat lokalnego urządzenia można monitorować a jakie są nie dostępne. Dodatkowo istnieje możliwość tworzenia własnych widoków.
    • Domyślnym widokiem protokołu SNMPv3 jest widok „v1default”, ustawiony w konfiguracji tylko do odczytu. Oczywiście istnieje opcjonalna możliwość ustawienia funkcji zarówno odczytu jak i zapisu danych MIB, za pomocą komendy [snmp-server group name v3 noauth write v1default].
    • Protokół SNMP w wersji trzeciej wprowadził nowe funkcje bezpieczeństwa, umożliwiające wybór jednego z trzech scenariuszy zabezpieczeń, wprowadzonych w komunikacji pomiędzy agentem a menadżerem NMS.
      • Podstawowy scenariusz (noauth) – Zapewnia jedynie podstawowe zabezpieczenie integralności wiadomości SNMP.
      • Środkowy scenariusz (auth) – Zapewnia autentykację za pomocą nazwy użytkownika jak i hasła haszowanego za pomocą algorytmu MD5 bądź algorytmu SHA.
      • Zaawansowany scenariusz (priv) – Zapewnia autentykację za pomocą nazwy użytkownika jak i hasła haszowanego za pomocą algorytmu MD5 bądź SHA oraz enkrypcji całej zawartości wiadomości SNMP za pomocą algorytmu DES, 3DES bądź AES.
    Komenda Wiadomość Sprawdzanie integralności Autentykacja wiadomości SNMP Enkrypcja wiadomości SNMP
    noauth noAuthNoPriv Tak Nie Nie
    auth authNoPriv Tak Tak Nie
    priv priv Tak Tak Tak

    Porównanie metod zabezpieczających komunikację protokołu SNMPv3

    Struktura komend wykorzystywana w konfiguracji protokołu SNMPv3

    • Komenda SNMP Group – Tworzy grupę definiującą wersję protokołu SNMP, scenariusz zabezpieczeń, tryb dostępu (Read, Write), widok bazy MIB oraz dodatkowe zabezpieczenia w postaci listy dostępu ACL.
    • Komenda SNMP User – Tworzy użytkownika przypisanego do danej grupy protokołu SNMPv3, określającego konkretne właściwości scenariusza zabezpieczeń, takie jak nazwę użytkownika, opcjonalne hasło z metodą haszowania oraz opcjonalny algorytm enkrypcji wiadomości SNMP (Dane te muszą byś zgodne z wybranym scenariuszem grupy SNMP, inaczej dany użytkownik nie zostanie połączony z określoną grupą, a tym samym połączenie pomiędzy agentem a menadżerem NMS nie zostanie nawiązane). 
    • Komenda SNMP Host – Definiuje dane dotyczące menadżera NMS, określając jego adres IP, wersję protokołu SNMP, scenariusz zabezpieczeń, nazwę użytkownika oraz wersję wysyłanych wiadomości SNMP (Trap, Inform). Dane dotyczące scenariusza zabezpieczeń muszą byś zgodne z wybranym scenariuszem grupy SNMP, inaczej dany menadżer NMS nie zostanie powiązany z określoną grupą SNMP, a tym samym koniunkcja pomiędzy agentem a menadżerem zawiedzie. 

    Różnice pomiędzy poszczególnymi wersjami protokołu SNMP

    • Cechy charakterystyczne protokołu SNMPv1:
      • Protokół SNMPv1 wprowadził podstawowe wiadomości Get, Set oraz Trap, wraz z zasadą podziału na (communities).
      • Teoretycznie w przypadku protokołu SNMPv1 tylko menadżer NMS należący do odpowiedniej communities (RW), mógł dokonywać zmian w zawartości bazy MIB danego agenta. Jednak w praktyce pozbawiony zabezpieczeń protokół zezwalał na to każdemu, kto wysłał odpowiednio spreparowane żądanie „Set Request”.
    • Cechy charakterystyczne protokołu SNMPv2c:
      • Protokół SNMPv2c zwiększył wielkość zmiennych z 32 bitów do 64 bitów, wprowadzając również nowe wiadomości Get Bulk oraz Get inform.
    • Cechy charakterystyczne protokołu SNMPv3:
      • Protokół SNMPv3 pozbył się podziału na (communities), zastępując go grupami SNMP. Dodatkowo zwiększył poziom zabezpieczeń wspierany przez system użytkowników, autentykacji, badania integralności oraz enkrypcji wysyłanych wiadomości. Nowy protokół SNMP zmienił również sposób zarządzania bazą MIB wprowadzając widoki (View).
    • Różniące pomiędzy protokołem SNMPv2 & SNMPv2c:
      • Protokół SNMP w wersji drugiej (SNMPv2) nie posiada podziału na (communities) RO oraz RW.
      • Poprawiony protokół SNMP w wersji drugiej (SNMPv2c) ponownie wprowadza podział na (communities).

    Pozostałe tematy związane z protokołem SNMP

  • (K) Konfiguracja protokołu SPAN*

    (K) Konfiguracja protokołu SPAN*

    Local SPAN & Remote SPAN

    Konfiguracja funkcji SPAN

    (config)# monitor session numer-sesji source {interface interfejs(zakres interfejsów) / vlan vlan-ID(zakres sieci VLAN) / cpu} [rx / tx / both](both)

    Określa interfejsy lub sieci VLAN, których ruch sieciowy będzie kopiowany a następnie wysyłany do interfejsu docelowego (Monitorującego). Słowo kluczowe „rx” umożliwia przechwytywanie ruch wychodzącego, „tx” przychodzącego natomiast „both” przechwytuje zarówno ruch wychodzący jak i przychodzący. 
    Ruch sieciowy blokowany na podstawie listy PACL, jest nadal przechwytywany przez funkcję SPAN / RSPAN.

    (config)# monitor session numer-sesji destination interface interfejs [encapsulation replicate]

    Określa interfejs docelowy na który przysłany jest przechwycony ruch sieciowy. Dodatkowa opcja „encapsulation replicate” zmienia domyślne ustawienia przechwytywania ruchu sieciowego, przepuszczając cały ruch źródłowy na interfejs docelowy (Domyślnie ramki stworzone przez lokalny przełącznik nie są przechwytywane a tym samym nie dotrą do interfejsu docelowego. Do ramek tych należą wiadomości protokołu STP, VTP, CDP, LLDP czy DTP). 

    Opcjonalna konfiguracja funkcji SPAN:

    (config)# monitor session numer-sesji filter vlan vlan-ID

    Umożliwia filtrowanie monitorowanego ruchu sieciowego dla połączeń typu Trunk, względem konkretnych sieci VLAN. Jedynie określone w komendzie sieci VLAN będą monitorowane

    (config)# monitor session destination

    Nadpisuje domyślne zachowanie funkcji SPAN, RSPAN umożliwiając interfejsowi monitorującemu „Destination Port”, odpieranie jak i wysyłanie ruchu sieciowego.

    (config)# monitor session numer-sesji destination interface interfejs ingress {dot1q vlan vlan-ID / isl / untagged vlan vlan-ID}

    Określa zasadę działania interfejsu monitorującego „Destination Port” (Trunk, Access) przy aktywnej komędzie [monitor session destination].

    (config)# monitor event-trace

    Włącza funkcjonalność umożliwiającą zarządzanie przechwytywanym ruchem sieciowym.

    Konfiguracja funkcji RSPAN

    Etap pierwszy – Konfiguracja sesji źródłowej

    (config)# vlan vlan-ID

    Tworzy sieć VLAN, służącą do przenoszenia przechwyconego ruchu sieciowego (RSPAN VLAN).

    (config-vlan)# remote-span

    Określa funkcję VLAN-u, jako sieci przenoszącej przechwycony ruch sieciowy (RSPAN).

    (config)# monitor session numer-sesji source {interface interfejs(zakres interfejsów) / vlan vlan-ID(zakres interfejsów)} [rx / tx / both](both)

    Określa interfejsy lub sieci VLAN, których ruch sieciowy będzie kopiowany a następnie wysyłany do interfejsu docelowego (Monitorującego). Słowo kluczowe „rx” umożliwia przechwytywanie ruch wychodzącego, „tx” przychodzącego natomiast „both” przechwytuje zarówno ruch wychodzący jak i przychodzący. 
    Ruch sieciowy blokowany na podstawie listy PACL, jest nadal przechwytywany przez funkcję SPAN / RSPAN.

    (config)# monitor session numer-sesji destination remote vlan vlan-ID [reflector-port interfejs]

    Określa docelową sieć VLAN, służącą do przenoszenia przechwyconego ruchu sieciowego.

    Etap drugi – Konfiguracja sesji docelowej

    (config)# vlan vlan-ID

    Tworzy sieć VLAN, służącą do przenoszenia przechwyconego ruchu sieciowego (RSPAN VLAN).

    (config-vlan)# remote-span

    Określa funkcję VLAN-u, jako sieci przenoszącej przechwycony ruch sieciowy (RSPAN).

    (config)# monitor session numer-sesji source remote vlan vlan-ID

    Określa źródłową sieć VLAN, służącą do przenoszenia przechwyconego ruchu sieciowego.

    (config)# monitor session numer-sesji destination interface interfejs [encapsulation replicate]

    Określa interfejs docelowy na który przysłany jest przechwycony ruch sieciowy. Dodatkowa opcja „encapsulation replicate” zmienia domyślne ustawienia przechwytywania ruchu sieciowego, przepuszczając cały ruch źródłowy na interfejs docelowy (Domyślnie ramki stworzone przez lokalny przełącznik nie są przechwytywane a tym samym nie dotrą do interfejsu docelowego. Do ramek tych należą wiadomości protokołu STP, VTP, CDP czy DTP).  
    W przypadku funkcji RSPAN numer ID sesji nie musi być taki sam na obydwóch przełącznikach.

    Dodatkowa konfiguracja funkcji RSPAN

    (config)# monitor session numer-sesji filter vlan vlan-ID

    Umożliwia filtrowanie monitorowanego ruchu sieciowego dla połączeń typu Trunk, względem konkretnych sieci VLAN.

    (config)# monitor session destination

    Nadpisuje domyślne zachowanie funkcji SPAN, RSPAN umożliwiając interfejsowi monitorującemu „Destination Port”, odpieranie jak i wysyłanie ruchu sieciowego.

    (config)# monitor session numer-sesji destination interface interfejs ingress {dot1q vlan vlan-ID / isl / untagged vlan vlan-ID}

    Określa zasadę działania interfejsu monitorującego „Destination Port” (Trunk, Access) przy aktywnej komędzie [monitor session destination].

    (config)# monitor event-trace

    Włącza funkcjonalność umożliwiającą zarządzanie przechwytywanym ruchem sieciowym.

    Encapsulated Remote SPAN

    Konfiguracja funkcji ERSPAN

    Etap pierwszy – Konfiguracja sesji źródłowej

    (config)# monitor session numer-sesji type erspan-source

    Rozpoczyna konfigurację nowej źródłowej sesji ERSPAN.

    (config-mon-erspan-src)# source interface interfejs [rx / tx / both](both)

    Określa źródłowy interfejs sesji ERSPAN.

    (config-mon-erspan-src)# destination

    Przechodzi do poziomu konfiguracji urządzenia docelowego sesji ERSPAN.

    (config-mon-erspan-src-dst)# erspan-id ID

    Określa wartość ID dla danej sesji ERSPAN.

    (config-mon-erspan-src-dst)# ip address docelowy-adres-IP

    Określa docelowy adres IP dla danej sesji ERSPAN.

    (config-mon-erspan-src-dst)# origin ip address źródłowy-adres-IP

    Określa źródłowy adres IP dla danej sesji ERSPAN.

    (config-mon-erspan-src-dst)# no shutdown

    Aktywuje konfigurowaną sesję ERSPAN.

    Etap drugi – Konfiguracja sesji docelowej

    (config)# monitor session numer-sesji type erspan-destination

    Rozpoczyna konfigurację nowej docelowej sesji ERSPAN.

    (config-mon-erspan-dst)# destination interface interfejs

    Określa docelowy interfejs sesji ERSPAN.

    (config-mon-erspan-dst)# source

    Przechodzi do poziomu konfiguracji urządzenia źródłowego sesji ERSPAN.

    (config-mon-erspan-dst-src)# erspan-id ID

    Określa wartość ID dla danej sesji ERSPAN.

    (config-mon-erspan-dst-src)# ip address źródłowy-adres-IP

    Określa źródłowy adres IP dla danej sesji ERSPAN.

    (config-mon-erspan-dst-src)# no shutdown

    Aktywuje konfigurowaną sesję ERSPAN.

    Usuwanie sesji SPAN & RSPAN

    (config)# no monitor session {numer-sesji / range zakres-wielu-sesji}

    Usuwa sesję SPAN, RSPAN, ERSPAN.

    (config)# no monitor session numer-sesji

    Usuwa sesję SPAN, RSPAN, ERSPAN.

    (config)# no monitor session local

    Usuwa sesję RSPAN, ERSPAN.

    (config)# no monitor session remote

    Usuwa sesję RSPAN, ERSPAN.

    Export ???

     (config)# monitor capture 1 export tftp://adres-IP/ścieżka/do/pliku.pcap

    Xxx

    Komendy Show

    # show monitor

    Wyświetla informacje o konfiguracji funkcji SPAN oraz funkcji RSPAN.

    # show running-config | include monitor

    Wyświetla konfigurację funkcji SPAN oraz funkcji RSPAN.

    # show vlan remote-span

    Wyświetla aktywne sieci vlan, przenoszące ruch monitorujący RSPAN.

    Pozostałe tematy związane z protokołem SPAN

  • (Ts) Troubleshooting protokołu SPAN*

    (Ts) Troubleshooting protokołu SPAN*

    Wykorzystanie interfejsów sieciowych

    Funkcję portu źródłowego (Source Port) mogą pełnić

    • Interfejsy fizyczne (FastEthernet, GigabitEthernet …).
    • Interfejsy wirtualne (Etherchannel).
      • Monitorowanie pojedynczego interfejsu fizycznego (Należącego do grupy EtherChannel) nie jest możliwe.
      • Konfiguracja sesji SPAN winna być dokonywana względem interfejsu wirtualnego (Port-Channel).
      • Próba monitorowania pojedynczego interfejsu fizycznego, automatycznie wykluczy go z grupy EtherChannel.
    • Interfejsy należący do innej sesji SPAN & RSPAN.
    • Sieci wirtualne VLAN.
    • Połączenia współdzielone Trunk.

    Funkcję portu źródłowego (Source Port) nie mogą pełnić

    • Jednocześnie interfejsy fizyczne wraz z sieciami wirtualnymi VLAN.
    • Interfejs działający jako port docelowy dla innej sesji SPAN & RSPAN.

    Funkcję portu docelowego (Destination Port) może pełnić

    • Interfejs fizyczny (FastEthernet, GigabitEthernet …).

    Funkcję portu docelowego (Destination Port) nie może pełnić

    • Port docelowy (Destination Port) należący do innej sesji SPAN & RSPAN.
    • Interfejs źródłowy (Source Port).
    • Interfejs wirtualny (Etherchannel).

    Local SPAN & Remote SPAN

    Funkcja SPAN & RSPAN zabrania

    • Jednoczesnego monitorowania interfejsów fizycznych wraz z wirtualnymi sieciami VLAN.
    • Używania interfejsu logicznego jako interfejsu docelowego „Destination Port”.
    • Używania sieci VLAN jako obiektu docelowego „Destination Port”.
    • Używania interfejsu docelowego „Destination Port” jako interfejsu źródłowego „Source Port” dla innej sesji.
    • Używania interfejsu źródłowego „Source Port” jako interfejsu docelowego „Destination Port”.
    • Współdzielenia interfejsów docelowych „Destination Port” pomiędzy różnymi sesjami monitoringu.
    • Wykorzystywania interfejsu wirtualnego Etherchannel jako interfejsu docelowego „Destination Port”.
    Funkcja SPAN oraz RSPAN przesyła przechwycony ruch sieciowy na określony interfejs fizyczny. W tym momencie przestaję on funkcjonować jak zwykły interfejs a staje się interfejsem docelowym „Destination Port”. Blokowana jest na nim obsługa protokołu STP a dotrzeć do niego może jedynie przechwycony ruch sieciowy.
    W przypadku nadesłania na interfejs docelowy zbyt dużej ilości ruchu sieciowego, nadmiarowa ilość jest porzucana.
    • Podczas konfiguracji funkcji SPAN bądź RSPAN należy pamiętać, że docelowy interfejs monitorujący ruch sieciowy „Destination Port”, posiada ograniczoną przepustowość łącza. Tym samym przerzucanie na niego ruchu z wielu interfejsów źródłowych bądź sieci VLAN może być ponad jego możliwość, a tym samym doprowadzić do porzucania monitorowanego ruchu sieciowego. Dodatkowo należy pamiętać, aby host monitorujący ruch sieciowy, posiadał fizyczną możliwość analizy ruchu sieciowego w postaci odpowiedniej mocy procesora (CPU) oraz pamięci RAM.

    Pytania i odpowiedzi

    ? Pytanie 1: Co się stanie gdy interfejs należący do połączenie wirtualnego EtherChannel, zostanie skonfigurowany jako interfejs docelowy „Destination Port” dla funkcji SPAN?

    $ Odpowiedź 1: Interfejs zostanie usunięty z połączenia wirtualnego EtherChannel.

    Pozostałe tematy związane z protokołem SPAN

  • (T) Teoria protokołu SPAN*

    (T) Teoria protokołu SPAN*

    Local SPAN & Remote SPAN

    Nazewnictwo wykorzystywane przez funkcję SPAN & RSPAN

    • Ingress Source Port RX – Interfejs, którego ruch przychodzący jest przechwytywany przez funkcją SPAN & RSPAN.
    • Engress Source Port TX – Interfejs, którego ruch wychodzący jest przechwytywany przez funkcją SPAN & RSPAN.
    • Destination Port – Interfejs, na który przysłany jest przechwycony ruch sieciowy.
    • SPAN Session – Pojedyncza sesja umożliwiającą przechwytywanie ruchu sieciowego z interfejsów sieciowych bądź sieci VLAN „Source Port”, na jeden określony interfejs docelowy „Destination Port”. Dane przechwytywane przez sesję SPAN mogą być ukierunkowane na ruch przychodzący „Ingress Source Port”, ruch wychodzący „Engress Source Port” bądź obydwa kierunki ruchu jednocześnie (Wychodzący jak i przychodzący).
    • Source VLAN – Wirtualna sieć VLAN, której ruch sieciowy jest przechwytywany przez funkcją SPAN & RSPAN.
    • RSPAN Source Session – Sesja źródłową, której ruch sieciowy jest przechwytywany przez funkcją RSPAN.
    • RSPAN VLAN – Specjalna sieć VLAN przeznaczona do transportowania przechwyconego ruchu sieciowego, pomiędzy przełącznikiem posiadającym interfejs źródłowy „Source Port”,a przełącznikiem posiadającym interfejs docelowy „Destination Port”. Wirtualna sieć RSPAN VLAN:
      • Jest przenoszona jedynie przez połączenia Trunk-owe.
      • Może być ograniczana swoim zasięgiem, za pomocą funkcji VTP Pruning.
      • Funkcjonuje na zasadzie rozlewania „flooded” ruchu sieciowego.
      • Posiada aktywną instancję protokołu STP.
        • Ramki BPDU są wymieniane jedynie na połączeniach Trunk-owych.
        • Ruch protokołu STP jest blokowany na interfejsie docelowym „Destination Port”.
    Powyższe punkty nie dotyczą ruchu przechwyconego przez interfejs źródłowy „Source Port”.
    • RSPAN Reflector Port – Port przełącznika działający na zasadzie interfejsu Loopback dla funkcji RSPAN. Odbiera monitorowany ruch sieciowy z źródła „Source Port” by następnie przesłać go do sieci docelowej RSPAN VLAN (Niegdyś wymagany przy konfiguracji funkcji RSPAN, obecnie nie jest dostępny w nowszych wersjach systemu IOS).

    SPAN – Switch Port Analyzer

    • Powiela ruch sieciowy nadchodzący z wielu interfejsów źródłowych bądź sieci VLAN „Source Port”,kopiując go na jeden interfejs monitorujący „Destination Port” (Obydwa interfejsy muszą przynależeć do tego samego przełącznika fizycznego bądź logicznego (Stack Switching)).
    • Blokuje funkcję uczenia się adresów MAC na interfejsie docelowym „Destination Port”.

    RSPAN – Remote Switch Port Analyzer

    • Powiela ruch sieciowy nadchodzący z wielu interfejsów źródłowych bądź sieci VLAN „Source Port”,kopiując go na jeden interfejs monitorujący „Destination Port” (Obydwa interfejsy nie mogą znajdować się na tym samym fizycznym bądź logicznym przełączniku (Stack Switching)).
    • Wykorzystuje dedykowaną sieć VLAN (RSPAN VLAN) przeznaczoną do przenoszenia ruchu sieciowego pomiędzy przełącznikami (Sieć RSPAN VLAN ma zablokowaną funkcję uczenia się adresów MAC).
    • Blokuje funkcję uczenia się adresów MAC na interfejsie docelowym „Destination Port”.
    Sieć RSPAN VLAN może być dynamicznie propagowana za pomocą protokołu VTP w wersji Trzeciej.

    Cechy wspólne funkcji SPAN & RSPAN

    • Funkcja SPAN oraz RSPAN umożliwia przechwytywanie ruchu sieciowego z:
      • Interfejsu fizycznego bądź wielu interfejsów fizycznych konfigurowanego przełącznika.
      • Całej grupy portów EthernetChanel lub pojedynczego interfejsów należącego do grupy PortChanel.
      • Sieci VLAN (VSPAN „VLAN Remote Switch Port Analyzer” bądź „VLAN-based SPAN”).
      • Ruchu przychodzącego, wychodzącego jak i jednego i drugiego jednocześnie.

    Pozostałe tematy związane z protokołem SPAN

  • (Ts) Troubleshooting wydajności urządzeń sieciowych*

    (Ts) Troubleshooting wydajności urządzeń sieciowych*

    Problemy krytyczne

    Błędy krytyczne

    Błędy krytyczne (zrzut TFTP)

    # write core adres-IP

    Zapisuje zrzut pamięci urządzenia sieciowego (Core dump) wraz z czasem wystąpienia błędu krytycznego. W następstwie którego urządzenie te zostanie zresetowane. Na wskazany w komendzie adres IP zostanie wysłany zapisany zrzut pamięci wraz z datą (Za pomocą protokołu TFTP).

    Błędy krytyczne (zrzut FTP)

    (config)# ip ftp username login

    Definiuje login użytkownika, wykorzystywany przez protokół FTP.

    (config)# ip ftp password hasło

    Definiuje hasło użytkownika, wykorzystywane przez protokół FTP.

    (config)# exception protocol ftp

    Wykonuje zrzut pamięci urządzenia sieciowego (Core dump), przy wykorzystaniu protokołu FTP.

    (config)# exception dump adres-IP

    Określa adres IP serwera FTP.

    Pozostałe tematy związane z Troubleshooting-iem

    Podstawy sieci komputerowych

    Warstwy modelu OSI

    Bezpieczeństwo sieci

    Troubleshooting

  • (Ts) Narzędzia Troubleshooting-u*

    (Ts) Narzędzia Troubleshooting-u*

    Narzędzia Troubleshooting-u

    Metody uzyskiwania informacji

    • Troubleshooting information collection – Informacje uzyskane podczas rozwiązywania bieżących problemów.
    • Baseline information collection – Informacje uzyskane podczas normalnego funkcjonowania sieci.
    • Network event information – Informacje uzyskane za pomocą wiadomości systemowych urządzań sieciowych.

    Podstawowe narzędzia

    • CLI – Umożliwia bieżące śledzenie aktywności danego urządzenia.
    • GUI – W przejrzysty graficzny sposób przedstawia aktywność danego urządzenia.
    • Recovery Tools – Umożliwia zapisywanie konfiguracji wielu urządzeń w bezpiecznym miejscu.
    • Logging tools – Umożliwia śledzenie aktywności wielu urządzeń.
    • NTP – Określa czas wystąpienia danego zdarzenia.
    • NetFlow – Monitoruje aktywność sieciową interfejsów.
    • IP SLA – Monitoruję osiągalność wyznaczonego adresu IP.
    • SNMP – Umożliwia zaawansowane śledzenie aktywności wielu urządzeń.
    • Cisco Support – Prowadzi wsparci za pomocą serwisów CMS bądź TAC.

    Komenda Ping i Traceroute

    Możliwe przyczyny braku odpowiedzi na pakiet ICPM

    • Lista ACL blikująca ruch sieciowy po adresach IP czy portach TCP, UDP (List ACL nie może filtrować ruchu wychodzącego, zainicjonowanego przez urządzenie, na którym sama powstała jak i funkcjonuje).
    • Funkcja „PortSecurity” włączona na przełączniku w celu filtrowania np. adresów MAC, może wyłączyć interfejs blokując tym samym cały ruch na niego przychodzący bądź z niego wychodzący.
    • Złe ustawienia trasy domyślnej w tablicy routingu, mogą kierować nadpływający ruch sieciowy w złym kierunku.
    • Błędna adresacja urządzeń, może spowodować przypisanie złych adresów IP należących do innej sieci.
    • Problemy na warstwie drugiej oraz pierwszej modelu OSI, mogą zablokować połączenie sieciowe.
    • Błędna konfiguracja serwera DHCP, mogła spowodować przypisanie błędnego adresu IP, maski czy adresu bramy D.
    • Wadliwa konfiguracja połączenia Trunk-owego, mogła wpłynąć na gubienie pakietów pomiędzy przełącznikiem a ruterem.

    Jeżeli pakiet ICPM dotrze do bramy domyślnej, to można założyć, że

    • Adres IP bramy domyślnej jest osiągalny z poziomu hosta.
    • Sieć lan przepuszcza ruch unicast pomiędzy hostem a bramą domyślną.
    • Przełącznik uczy się adresów MAC nadchodzących na jego interfejsy, w ramkach Ethernetowych.
    • Zaszła wymiana danych pomiędzy hostem a bramą domyślną, mająca na celu obopólną nauką adresów MAC za pomocą protokołu APR (Address Resolution Protocol).

    Zasada działania komendy Traceroute

    1. Host wysyła pakiet ICMP z ustawioną wartością TTL na 1.
    2. Ruter otrzymuje pakiet ICMP, zmniejszając jogo wartość TTL na 0.
    3. Ruter uznaje, że pakiet przekroczył maksymalną drogę a jego sieć docelowa jest nieosiągalną.
    4. Ruter odsyła pakiet ICMP z informacją o nieosiągalności sieci docelowej.
    5. Host wysyła pakiet ICMP, z wartością TTL zwiększoną o 1.

    Wysyłanie wiadomości ICMP

    # ping adres-IP [size 36-18024(100)(Datagram size) / repeat 1-2147483647(5) / timeout 0-3600(2) / source {adres-IP / interfejs} / df-bit(Don’t fragment bit)]

    Xxx

    Hardware Troubleshooting

    Komendy SHOW

    # show processes cpu

    Wyświetla poziom utylizacji procesora CPU.

    # show memory

    Wyświetla zsumaryzowane informacje na temat procesów przetrzymywanych w pamięci.

    # show interfaces interfejs

    Wyświetla informacje dotyczące danego interfejsu.

    # show platform

    Wyświetla szczegółowe informacje na temat danego urządzenia.

    Zaawansowana filtracja komend SHOW

    Komendy SHOW

    # show komenda | begin wyrażenie

    Wyświetla wydruk komendy Show zaczynając do linii zawierającej dane wyrażenie.

    # show komenda | count wyrażenie

    Wyświetla ilość linii komendy Show zawierających dane wyrażenie.

    # show komenda | exclude wyrażenie

    Wyświetla linie komendy Show nie zawierające danego wyrażenia.

    # show komenda | include wyrażenie

    Wyświetla linie komendy Show zawierające dane wyrażenie.

    # show komenda | redirect zasób

    Przekierowuje wydruk komendy show na dany zasób (Docelowy plik nie musi istnieć).

    # show komenda | append zasób

    Przekierowuje wydruk komendy show na dany zasób (Docelowy plik musi istnieć).

    # show komenda | tee zasób

    Przesyła wydruk komendy show na dany zasób.

    # show komenda | section sekcja

    Wyświetla określoną sekcje komendy Show.

    Unix-owe komendy w systemie Cisco IOS

    (config)# shell processing full

    Aktywuje dostęp do komend unix-owych.

    # show komenda-show | grep fraza

    Wyświetla wiersz zawierający podaną frazę.

    # show komenda-show | grep fraza | wc -l

    Wyświetla ilość wierszy zawierających daną frazę.

    Pozostałe tematy związane z Troubleshooting-iem

    Podstawy sieci komputerowych

    Warstwy modelu OSI

    Bezpieczeństwo sieci

    Troubleshooting

  • (Ts) Troubleshooting & Maintenance*

    (Ts) Troubleshooting & Maintenance*

    Wstęp do Troubleshooting-u

    Prosta metoda rozwiązywania problemów

    • Proces
      Troubleshooting-u stanowi proces rozwiązywania problemów sieciowych.
    Prosta metoda rozwiązywania problemów
    • Problem Report – Szczegółowe zdefiniowanie problemu.
    • Problem Diagnosis – Określenie prawdopodobnej przyczyny (Postawienie hipotezy)
    • Problem Resolution – Podjęcie próby naprawy występującego problemu.

    Złożona metoda rozwiązywania problemów

    • Złożona
      metoda rozwiązywania problemów rozbija punkt „Problem Diagnosis” przedstawiony
      w powyższym diagramie na pięć oddzielnych punktów, definiując tym samym siedem
      kroków w rozwiązywaniu problemów sieciowych.
    Złożona metoda rozwiązywania problemów
    1. Problem Report – Szczegółowe zdefiniowanie problemu.
    2. Collect Informations – Zebranie dodatkowych informacji za pomocą dedykowanych narzędzi sieciowych czy rozmów z użytkownikami dotkniętych danym problemem.
    3. Examine Collect Informations – Porównanie między sobą informacji zebranych z rożnych źródeł.
    4. Elminate Potential Causes – Eliminacja prawdopodobnych przyczyn powstania problemu na podstawie zebranych informacji z punktu drugiego oraz z punktu trzeciego.
    5. Propose an Hypothesis – Wysnucie hipotezy co do przyczyny powstania problemu na podstawie zebranych informacji.
    6. Verify Hypothesis – Sprawdzenie wysnutej hipotezy za pomocą dedykowanych narzędzi sieciowych.
    7. Problem Resolution – Podjęcie próby naprawy występującego problemu.

    Podejście strukturalne

    • Strukturalne
      podejście do rozwiązywania problemów sieciowych, powinno być dostosowywane do
      panującej sytuacji danego problemu. Struktura ta umożliwia pominięcie
      niektórych kroków sytuacji w której umożliwi to przyspieszenie samego procesu.
    Strukturalny model rozwiązywania problemów sieciowych

    Problem Report

    • Szczegółowe
      zdefiniowanie problemu wymaga od administratora zebrania podstawowych danych od
      użytkownika zgłaszającego problem. W punkcie tym należy określić jakiego
      rodzaju jest to problem oraz kto powinien się nim zająć.
    • Przykładowo
      użytkownik zgłasza problem z brakiem dostępu do Internetu, po sprawdzeniu
      okazuje się że użytkownikowi wyskakuje „error
      404”       przy czym komunikacja z wewnętrznym serwerem http działa poprawnie.

    Collect Informations

    • Zebranie
      dodatkowych informacji za pomocą dedykowanych narzędzi sieciowych czy rozmów z użytkownikami
      dotkniętych danym problemem, wymaga od administratora wiedzy na temat zasad
      działania zasobów co do których wystąpił problem. Wiedza ta umożliwia
      oszczędzenie czasu, ponieważ administrator skupia się na zebraniu informacji z
      urządzeń oraz od osób które w sposób bezpośredni bądź pośredni związane z
      procesem działania danego zasobu.
    • Przykładowo
      problem związany z dostępnością serwerem FTP, może wynikać z błędnej
      konfiguracji lokalnego programu FTP a nie koniecznie dotyczyć komunikacji
      komputera z serwerem tudzież samego serwera FTP. Wiedząc to administrator
      wpierw skupi się na sprawdzeniu konfiguracji lokalnego urządzenia, zamiast
      marnować czas na weryfikacje ustawień sieciowych.

    Examine Informations

    • Po
      zebraniu niezbędnych informacji na temat danego problemu, takich jak logging-i,
      wydruki komend „show” oraz „debug”, pakiety przechwycone przez
      programy śledzące typu „Sniffer” czy wyniki
      operacji „ping” jak i „traceroute”. Administrator powinien
      zidentyfikować wskaźniki wskazujące na przyczynę powstawania problemu jak i
      dowody wspomagające dalszą weryfikację. Wykonując to zadanie administrator
      powinien porównać ze sobą dwie wartości: to jak konfiguracja sieci wygląda z
      tym jak wyglądać powinna.
    • W tym
      punkcie procesu rozwiązywania problemów sieciowych istotną rolę gra aktualna dokumentacja
      sieciowa.
    • Przykładowo
      użytkownik może być nie świadomy że komunikacja z serwerem FTP wymaga
      posiadania dodatkowej aplikacji, zweryfikowanie tego z dokumentacją uwidacznia
      przyczynę powstania danego problemu.

    Elminate Potential Causes

    • Eliminacja
      prawdopodobnych przyczyn powstania problemu na podstawie zebranych informacji.

    Propose an Hypothesis

    • Po wyborze
      najbardziej prawdopodobnych przyczyn powstania problemu, na podstawie zabranych
      informacji, administrator może skupić się na pozostałych teoriach formując na
      ich podstawie hipotezę.

    Verify Hypothesis

    • Po
      określeniu najbardziej prawdopodobnej hipotezy, należy ją zweryfikować a
      następnie przygotować plan naprawy danego problemu. Może być to rozwiązanie
      zarówno stałe jak i tymczasowe.

    Problem Resolution

    • Podjęcie
      próby naprawy występującego problemu.

    Popularne metody Troubleshooting-u

    Metody rozwiązywania problemów

    • The top-down method (7 ->1) – Metoda rozpoczynająca proces troubleshooting-u od warstwy aplikacji (7) a kończąca na warstwie fizycznej (1).
    • The bottom-up method (1 ->7) – Metoda rozpoczynająca proces troubleshooting-u od warstwy fizycznej (1) a kończąca na warstwie aplikacji (7).
    • The divide-and-conquer method (1 <- 3 -> 7) – Metoda rozpoczynająca proces troubleshooting-u od warstwy trzeciej (3) a następnie idąca w górę do warstwy aplikacji (7) bądź w dół od warstwy fizycznej (1), w zależności od osiągniętego rezultatu. Jeżeli np. komenda Ping nie osiągnie zamierzonego celu, administrator uzna że błąd dotyczy warstw niższych.
    • Following the traffic path – Metoda rozpoczynająca proces troubleshooting-u od weryfikacji połączenia pomiędzy hostem zgłaszającym problem a najbliższym urządzeniem sieciowych. W kolejnym kroku weryfikacji podlega następne urządzenie stojące na drodze od hosta do celu danej transmisji.
    • Comparing configurations – Metoda rozpoczynająca proces troubleshooting-u od porównania konfiguracji bieżącej z ostatnią znaną i wypełni sprawną konfiguracją.
    • Component swapping – Metoda rozpoczynająca proces troubleshooting-u od wymiany komponentów. Przykładowo wymianie takiej może podlegać kabel Ethernet-owy, pojedynczy moduł rutera bądź całe urządzenie sieciowe.

    Konserwacja sieci (Maintenance)

    Definicja procesu konserwacji sieci

    • Proces
      konserwacji pozwala utrzymać sieć w stanie spełniającym wymogi założeń
      biznesowych, związanych z funkcjonowaniem i dostępnością sieci. Przykładowe
      czynności zaliczane do procesu konserwacji są następujące:
      • Instalacja
        i konfiguracja urządzeń sieciowych.
      • Rozwiązywanie
        problemów (Troubleshooting).
      • Monitorowanie
        i zwiększanie wydajności sieci.
      • Tworzenie
        dokumentacji sieci jak i zmian w niej dokonywanych.
      • Sprawdzanie
        sieci pod kontem zgodności z prawem oraz standardami firmowymi.
      • Zabezpieczanie
        sieci przed zewnętrznymi jak i wewnętrznymi zagrożeniami.
      • Tworzenie
        kopi zapasowych.

    Proaktywne (Proactive) & Reaktywne (Reactive) podejście do konserwacji sieci

    • Podejście do procesu konserwacji sieci może być podjęte na dwa sposoby:
      • Interrupt-driven Tasks – Obejmuje proces rozwiązywania problemów w miarę ich zgłaszania.
      • Sructured Tasks – Obejmuje proces rozwiązywania problemów w sposób zaplanowany. Dzięki czemu możliwe staje się zapobieganie awariom, zanim staną się one poważnym problemem dla całej infrastruktury. Podejście to odnosi się również do planowanych inwestycji, w wymianę istniejącego jak i zakup nowego sprzętu oraz oprogramowania.
    • W celu uproszczenia procesu konserwacji sieci, stworzono wiele ustandaryzowanych procedur takich jak:
      • FCAPS (Fault management, Configuration management, Accounting management, Performance management and Security management).
      • ITIL (IT Infrastructure Library).
      • Cisco Lifecycle Service.
    • Poszczególne elementy procesu konserwacji sieci wyglądają następująco:
      • Fault Management – Za pomocą narzędzi monitorujących jak i zbierających dane na temat stanu infrastruktury sieciowej, nadzoruje czy utylizacja urządzeń oraz przepustowość linków nie przekracza dopuszczalnej normy.
      • Configuration Management – Wymaga ciągłej aktualizacji zmian zachodzących w infrastrukturze sieciowej związanych z wymianą urządzeń bądź ich oprogramowania. Proces ten odnosi się również do bieżącej aktualizacji narzędzi monitorujących i zbierających dane na temat stanu infrastruktury sieciowej.
      • Accounting Management – Nadzorowanie zmian zachodzących w infrastrukturze sieciowej.
      • Performance Management – Monitorowanie przepustowości połączeń lokalnych LAN oraz zewnętrznych WAN, z uwzględnieniem implementacji jak i nadzorowania funkcji kolejkowania QoS.
      • Security Management – Wdrażanie jak i monitorowanie zapór ogniowych (Firewall), wirtualnych połączeń prywatnych VPN, systemów prewencyjnych IPS, zabezpieczania dostępu za pomocą funkcji AAA czy nadzorowania polis bezpieczeństwa takich lak np. listy ACL.

    Metody konserwacji sieci

    Rutynowe zadania konserwacyjne

    • Rutynowe zadania konserwacyjne stanowią nierozłączną część każdej odpowiednio zaplanowanej infrastruktury sieciowej, są to zadania wykonywane regularnie co godzinie, dzień, tydzień, miesiąc czy rok bądź też nieregularne takie jak dodawanie nowych użytkowników. Przykładowe zadania związane z rutynową konserwacją mogą być następujące:
      • Configuration changes – Dodawanie nowych użytkowników, urządzeń bądź oprogramowania. Dokonywanie zmian związanych z relokacją obecnych zasobów (Użytkowników, urządzeń) wraz związaną z tym rekonfiguracją systemów.
      • Replacement of older or failed hardware – Wymiana starych bądź uszkodzonych urządzeń.
      • Scheduled backup – Tworzenie kopi zapasowych konfiguracji, logging-ów zebranych z urządzeń sieciowych.
      • Updating software – Aktualizacja oprogramowania sieciowego (IOS, IOS XE oraz IOS XR).
      • Monitoring network performance – Monitorowanie jak i zbieranie informacji na temat utylizacji urządzeń oraz przepustowości linków. Co może uprościć proces troubleshooting-u jak i pomóc w planowaniu nowych inwestycji.

    Planowanie zadań konserwacyjnych

    • Kto zatwierdza zmiany dokonywane w
      infrastrukturze sieciowej.
    • Jakie zadania powinny być wykonywane jedynie w
      oknie czasowym przeznaczonym na zadania konserwacyjne.
    • Jakie procedury obowiązują podczas
      przeprowadzania zadań konserwacyjnych.
    • Jakie kryteria określają sukces bądź porażkę
      przeprowadzonych zadań konserwacyjnych.
    • W jaki sposób będą dokumentowane zmiany
      zachodzące w infrastrukturze sieciowej.
    • Jakie narzędzia pozwolą przywrócić poprzednią
      działającą konfiguracje w przypadku niepowodzenia w wdrażaniu nowych rozwiązań
      bądź aktualizacji obecnej infrastruktury sieciowej.

    Prowadzenie dokumentacji sieciowej

    Dokumentacja infrastruktury sieciowej

    • Tworzenie jak i utrzymywanie bieżącej dokumentacji
      infrastruktury sieciowej ułatwia proces troubleshooting-u, ponieważ
      administrator w łatwy sposób może rozeznać się w konfiguracji sieci porównując
      stan obecny z założeniami.
    • Dokumentacja infrastruktury sieciowej może
      zwierać fizyczną (Physical) i logiczną (Logical) topologię sieci, konfiguracje
      poszczególnych urządzeń, procedury zmiany bieżącej konfiguracji, kontakt z
      osobami odpowiedzialnymi za daną część sieci czy wykaz dokonywanych zmian.
      Podsumowując dokumentacja infrastruktury sieciowej może zwierać:
      • Topologię logiczną
        (Logical Topology).
      • Topologię
        fizyczną (Physical Topology).
      • Listę
        połączeń pomiędzy urządzeniami.
      • Inwentarz
        urządzeń sieciowych.
      • Spis
        adresacji sieciowej.
      • Informacje
        na temat konfiguracji.
      • Plany założeń
        infrastruktury sieciowej.

    Przywracanie sieci po awarii

    • Przywrócenie pełnej funkcjonalności sieci po awarii urządzeń sieciowych, może być dokonane za pomocą:
      • Z duplikowanego wyposażenia (Hardware) znajdującego się w lokalnym magazynie.
      • Zapasowego oprogramowania przetrzymywanego na lokalnych serwerach.
      • Kopi zapasowych (Konfiguracji) pobranych z urządzeń sieciowych.

    Pozostałe tematy związane z Troubleshooting-iem

    Podstawy sieci komputerowych

    Warstwy modelu OSI

    Bezpieczeństwo sieci

    Troubleshooting

  • (K) Konfiguracja protokołu NetFlow*

    (K) Konfiguracja protokołu NetFlow*

    Konfiguracja protokołu NetFlow

    Podstawowa konfiguracja funkcji NetFlow

    (config)# ip flow-export destination adres-IP port-UDP

    Określa adres IP serwera NetFlow (Colector).

    (config)# ip flow-export source interfejs

    Określa interfejs źródłowy (Exported).

    (config)# ip flow-export version {1 / 5 / 9}

    Określa wersję (Flow) protokołu NetFlow.

    (config)# ip flow-export template timeout-rate 1-3600(30)(Minuty)

    Xxx

    (config)# interface interfejs

    Przechodzi do poziomu konfiguracji określonego interfejsu sieciowego.

    (config-if)# ip flow ingress

    Rozpoczyna przechwytywanie statystyk ruchu przychodzącego na dany interfejs .

    (config-if)# ip flow egress

    Rozpoczyna przechwytywanie statystyk ruchu wychodzącego z danego interfejsu.

    # show ip flow interface

    Wyświetla podstawowe informacje dotyczące konfiguracji protokołu NetFlow, względem interfejsów sieciowych na których został on aktywowany.

    Konfiguracja funkcji Flow Sampler

    Funkcja Flow Sampler wyświetla statystyki dotyczące losowo pobranych pakietów.

    (config)# flow-sampler-map nazwa-sampler

    Tworzy nową instancję funkcji Flow Sampler.

    (config-sampler)# mode random one-out-of 1-65535(100)

    Pobiera jeden pakiet na określoną w komedie ilość pakietów.

    (config-sampler)# interface interfejs

    Przechodzi do poziomu konfiguracji określonego interfejsu sieciowego.

    (config-if)# flow-sampler nazwa-sampler

    Aktywuje określoną w komendzie instancję funkcji Flow Sampler.

    # show flow-sampler

    Wyświetla statystyki dotyczące losowo pobranych pakietów.

    # show ip flow interface

    Wyświetla podstawowe informacje dotyczące konfiguracji protokołu NetFlow, względem interfejsów sieciowych na których został on aktywowany.

    Komendy SHOW

    # show ip flow interface

    Wyświetla konfigurację funkcji NetFlow, względem interfejsów danego urządzenia.

    # show ip cache flow

    Wyświetla zawartość pamięci cache, dla funkcji NetFlow.

    # show ip cache verbose flow

    Wyświetla szczegółową zawartość pamięci cache, dla funkcji NetFlow.

    Pozostałe tematy związane z Flexible NetFlow

  • (K) Konfiguracja protokołu SNTP*

    (K) Konfiguracja protokołu SNTP*

    Konfiguracja protokołu SNTP

    Podstawowa konfiguracja protokołu SNTP

    Urządzenie z skonfigurowanym protokołem NTP domyślnie jest klientem oraz serwerem jednocześnie. Dzięki czemu może aktualizować swój czas systemowy z innymi bardziej zaufanymi urządzeniami np. zegarem atomowym jak i samemu odpowiadać na zapytania protokołu NTP od innych hostów w sieci. Aby skonfigurować jedynie rolę klienta należy użyć protokołu SNTP (Simplified Network Time Protocol).
    SNTP nie może funkcjonować razem z protokołem NTP, ponieważ obydwa protokoły korzystają z tych samych portów L4.

    (config)# sntp server {nazwa-hosta / adres-IP} prefer

    Określa adres IP bądź nazwę domenową serwera SNTP (dodatkowa opcja „prefer” definiuje adres jako domyślny w przypadku skonfigurowania większej liczby serwerów SNTP).

    (config)# sntp source-interface interfejs

    Określa interfejs źródłowy, dla wysyłanych komunikatów SNTP.

    Autentykacja protokołu SNTP

    (config)# sntp authentication-key ID-klucza md5 klucz

    Definiuje klucz z przypisanym numerem ID.

    (config)# sntp authenticate

    Aktywuje uwierzytelnianie serwerów SNTP.

    (config)# sntp trusted-key ID-klucza

    Określa zaufany klucz do uwierzytelniania serwerów SNTP.

    (config)# sntp server {nazwa-hosta / adres-IP} key ID-klucza

    Przypisuje klucz dla danego serwera SNTP.

    Komendy Show

    # show clock [detail]

    Wyświetla czas oraz date lokalnego systemu (software). Dodatkowa komenda „detail” wyświetla źródło, z którego system pobierał informacje o czasie zegara.

    # show calendar

    Wyświetla czas oraz date lokalnego urządzenia (Hardware). Dodatkowa komenda „detail” wyświetla źródło, z którego system pobierał informacje o czasie zegara.

    # show ntp associations

    Wyświetla skonfigurowane serwery czasu. W przypadku klienta komunikat „unsynchronized” oznacza, że urządzenie nie pobiera jeszcze żadnych danych od serwera NTP. Natomiast w przypadku serwera „ntp master” ten komunikat będzie widoczny przez cały czas.

    # show ntp status

    Wyświetla status protokołu NTP na danym urządzeniu.

    # show ntp config

    Wyświetla konfiguracją protokołu NTP na danym urządzeniu.

    # show ntp information

    Wyświetla informacje dotyczące wersji protokołu NTP na danym urządzeniu.

    # show ntp packets

    Wyświetla ilość wysłanych / odebranych pakietów protokołu NTP na danym urządzeniu.

    Pozostałe tematy związane z protokołem NTP

  • (T) Wstęp do DNA Center*

    (T) Wstęp do DNA Center*

    Wstęp do DNA Center

    Czym jest DNA Center

    • DNA Center stanowi graficzny system zarządzania
      siecią, łączący istniejące już komponenty takie jak: ISE, NCP czy NDP, w jeden
      spójny system zarządzania siecią. W przeciwieństwie do starszego rozwiązania (Campus
      Fabric) w którym wymienione powyżej komponenty były niezależne a konfiguracja była
      wykonywana względem każdego urządzenia sieciowego z osobna, DNA center łączy je
      w całość, tworząc jeden punkt konfiguracji. Obecnie jedynie ISE posiada
      oddzielną konsole częściowo zintegrowaną z DNA Center (Np. polisy stworzone za
      pomocą konsoli DNA są przesyłane do ISE).

    Komponenty składowe DNA Center

    Model sieci DNA
    • ISE (Identity Services Engine) –
    • NCP (Network Control Platform) –
    • NDP (Network Data Platform) –
    • Design –
    • Policy –
    • Provision –
    • Assurance –

    Cykl wdrażania jak i utrzymania DNA Center

    • Design –
      • Global Settings –
      • Site Profiles –
      • DDI, SWIM, PNP –
      • User Access –
    • Policy –
      • Virtual Networks –
      • ISE, AAA, Radius –
      • Endpoint Groups –
      • Group Policies –
    • Provision –
      • Fabric Domains –
      • CP, Border, edge –
      • FEW, OTT WLAN –
      • External Connect –
    • Assurance –
      • Health Dashboard –
      • 360O Views –
      • Path Traces –

    Pozostałe tematy związane z DNA Center

  • (K) Wstęp do zarządzania siecią SD-WAN*

    (K) Wstęp do zarządzania siecią SD-WAN*

    Wstęp do zarządzania siecią SD-WAN

    Budowa menu vManage

    • Monitor –
      • Geography –
      • Network –
      • Alarms –
      • Events –
      • Audit Log –
      • ACL Log –
    • Configuration –
      • Device –
      • Certificates –
      • Templates –
      • Policies –
      • CloudExpress –
      • Cloud onRamp –
    • Tools –
      • SSH Terminal –
      • Rediscover Network –
      • Operational Commands –
    • Administration –
      • Settings –
      • Manage users –
      • Cluster Management –
    • vAnalytics –

    Pozostałe tematy związane z SD-WAN

  • (T) Licencjonowanie SD-WAN*

    (T) Licencjonowanie SD-WAN*

    Licencjonowanie SD-WAN

    Hardware & Subscription

    • Identify license tier –
    • Select bandwidth –
    • Pick license term –
    • Choose on premises or cloud managed –
    • Determine platform for future scale –

    Hardware

    • VEDGE Platform –
    • ISR Platform –
    • ASR Platform –
    • ENCS Platform –

    Subscription

    • Tier:
      • DNA Essentials –
      • DNA Advantage –
      • C1 Advantage –
    • Bandwidth:
      • 10M – 10G –
    • Term:
      • 3 or 5 Year –

    Pozostałe tematy związane z SD-WAN

  • (T) Certyfikacja rozwiązania SD-WAN*

    (T) Certyfikacja rozwiązania SD-WAN*

    Certyfikacja rozwiązania SD-WAN

    Podstawowe założenia certyfikacji

    • Authentication – Umożliwia:
      • Proces identyfikacji nadawcy.
      • Podwójną autentykację (nadawcy i odbiorcy).
    • Integrity – Umożliwia:
      • Weryfikację zawartości, odebranej wiadomości.
      • Potwierdzenie nienaruszalności wiadomości podczas przesyłu.
    • Confidentiality – Potwierdza odczytanie nadanej wiadomości jedynie przez uprawnione do tego urządzenia.
    • Nonrepudiation – Potwierdza że odebrana wiadomość została wysłana przez uprawnione do tego urządzenia.
      • Gotowa do wysłania wiadomość jest oznaczana kluczem prywatnym (Private Key), a następnie na podstawie całej zawartości generowana jest wartość kontrolna (Encrypted Hash).

    vEdge

    • Każdy ruter vEdge posiada własny wlutowany w płytę główną moduł TPM (Tamper-Proof Module), przetrzymujący prywatne jak i publiczne klucze. Moduł TPM ulega samozniszczeniu przy próbie fizycznego dostępu.
    • Klucze zaszyte w module TPM są podpisywane cyfrowo przez firmę Avnet (Trusted Certificate Signing Authority), a domyślnie walidowane przez firmę Symantec (Inny serwer walidacji CA może być podany w procesie ZTP).

    Pozostałe tematy związane z SD-WAN

  • (T) Wdrażanie rozwiązań SD-WAN*

    (T) Wdrażanie rozwiązań SD-WAN*

    Wdrażanie rozwiązań SD-WAN

    Rejestracja komponentów sieci SD-WAN

    1. Moduł vManage jak i moduły vSmart nawiązują bezpieczne połączenie (DTSL) z modułem vBond.
    2. Rutery vEdge nawiązują bezpieczne połączenie (DTSL) z modułem vBond rejestrując się w systemie.
      1. Na tym etapie następuje weryfikacja ruterów brzegowych na podstawie certyfikatów jak i białych list.
        1. Certyfikaty określają czy dany produkt jest urządzeniem wyprodukowanym przez Cisco.
        2. Kombinacja certyfikatów z białymi listami sprawdza czy dane urządzenie przynależy do określonego klienta.
    3. Rutery brzegowe vEdge nawiązują bezpieczne połączenie (DTSL/TSL) z modułami vSmart.

    Automatyczne rejestrowanie ZTP

    • Rutery brzegowe mogą być wdrażane zgodnie z modelem ZTP (Zero Touch Provisioning). W takim przypadku klient musi zarejestrować się w systemie Cisco, tworząc własny profil użytkownika.
    • Wszystkie nowo podłączane do sieci rutery, domyślnie łączą się z serwisem Cisco (ZTP, PNP Server), skąd pobierają informację na temat klienta do którego zostały sprzedane, wraz z danymi umożliwiającymi podłączenie do struktury wewnętrznej sieci klienckiej.
    • Ruter vEdge nawiązuje połączenie z ZTP, PNP Server (Cisco Public vBond) -> Client public vBond -> vSmart.

    Single / Multi-Tenant Orchestration

    • Multi-Tenant Orchestration – Umożliwia stworzenie oddzielnych struktur sieci SD-WAN dla każdego klienta z osobna. Poszczególne struktury będą zawierały oddzielne komponenty bazowe (vManage, vSmart oraz vBond). Model Multi-Tenant może być wdrożony w jeden z następujących sposobów:
      • Dedicated Tenancy –  Zgodnie z powyższą grafiką sieci SD-WAN została rozdzielona na dwie niezależne struktury zwierające własne komponenty (vManage, vSmart oraz vBond), dzięki czemu każdy z klientów może dysponować niezależną strukturą sieci, np. takimi samymi numerami ID sieci VPN. Model ten, cechuje:
        • Dedykowane instancję (Dedicated Tenancy / No Multitenancy).
        • Odseparowanie wszystkich komponentów sieci SD-WAN (vManage, vSmart oraz vBond).
        • Wsparcie dla wszystkich dostępnych rodzajów wdrożeń.
        • Możliwość pełnego odseparowania ruchu sieciowego.
      • VPN as a Tenant – Stanowi częściowe rozwiązanie Multi-Tenant w którym jako poszczególne struktur SD-WAN traktowane są sieci VPN. Rozwiązanie to nie stanowi w pełni modelu Multi-Tenant ponieważ współdzieli on poszczególne komponenty (vManage, vSmart oraz vBond) pomiędzy klientami, co może doprowadzić do przypadkowego np. wdrożenia polisy względem całej infrastruktury zamiast pojedynczego klienta. Model ten, cechuje:
        • Sieć VPN traktowaną jako niezależną instancję (Tenancy).
        • Współdzielenie wszystkich komponentów sieci SD-WAN (vManage, vSmart oraz vBond).
        • Wsparcie dla wszystkich dostępnych rodzajów wdrożeń.
      • Enterprise Tenancy – Wprowadza wirtualny podział struktury sieci SD-WAN, przy jednoczesnym wykorzystaniu tych samych komponentów bazowych (vManage oraz vBond). Wymagając przy tym oddzielnych wdrożeń komponentu vManage dla każdej instancji SD-WAN z osobna. Model ten, cechuje:
        • Pełny podział poszczególnych instancji (Tenancy).
        • Współdzielenie komponentów vManage oraz vBond pomiędzy poszczególnymi instancjami (Tenancy).
        • Odseparowanie instancji vManage pomiędzy poszczególnymi instancjami (Tenancy).
        • Wsparcie dla wszystkich dostępnych rodzajów wdrożeń.
        • Możliwość pełnego odseparowania ruchu sieciowego.
    • Single-Tenant Orchestration –

    Service Management

    • Domyślnie konsola vManage współpracuje jedynie z ruterami vEdge stworzonymi przez Viptelę jak i ruterami Cisco działającymi pod kontrolą systemu SD-WAN.
    • Obecnie oprócz domyślnych urządzeń vEdge konsola vManage może współpracować z innymi urządzeniami takimi jak rutery Cisco działające pod kontrolą systemu IOS, maszyny wirtualne czy rutery z serii ENCS/NFVIS za pośrednictwem rozszerzonych narzędzi (Extended SD-WAN Orchestration NSO) komunikującymi się z konsolą vManage za pomocą API.

    Rodzaje wdrożeń SD-WAN

    • Opcję wdrażania rozwiązania Cisco SD-WAN, dotyczą komponentów vManage, vSmart oraz vBond:
      • Cloud Delivered (Cisco) – Poszczególne komponenty nadzorujące strukturę sieci (vManage, vSmart oraz vBond) są hostowane jak i zarządzane poprzez firmę Cisco z poziomu chmury publicznej. Wdrożenie to, cechuje:
        • Dostarczanie usługi w formie serwisu.
        • Hostowanie usługi w chmurze publicznej.
        • Utrzymanie struktury przez specjalistów (Cisco Cloud Ops).
        • Możliwość zarządzania usługą przez klientów bądź partnerów Cisco.
      • Partner Delivered – Poszczególne komponenty nadzorujące strukturę sieci (vManage, vSmart oraz vBond) są zarządzane przez partnerów Cisco, dzięki czemu mogą oni udostępniać rozwiązania SD-Wan dla swoich klientów (Przykładowym zastosowaniem danego rodzaju wdrożenia mogą być dostawcy usług Internetowych (ISP) zapewniający nowoczesne rozwiązania dla swoich klientów). Wdrożenie to, cechuje:
        • Dostarczanie usługi z poziomu infrastruktury partnera Cisco.
        • Utrzymanie struktury przez partnera Cisco.
        • Zarządzanie usługą przez partnera Cisco.
      • Customer On-Prem – Poszczególne komponenty nadzorujące strukturę sieci (vManage, vSmart oraz vBond) są w pełni zarządzane po stronie klienta. Wdrożenie to, cechuje:
        • Pełne wdrożenie po stronie klienta.
        • Dostarczanie usługi z poziomu lokalnej infrastruktury.
        • Utrzymanie struktury po stronie lokalnego zespół IT klienta.
        • Zarządzanie usługą po stronie lokalnego zespół IT klienta.
    Wizualizacja sieci SD-WAN w modelu Dedicated Tenancy (Multi-Tenant Orchestration)

    Model – Cloud Delivered

    Model – Cloud Delivered
    • Wrażanie rozwiązania SD-Wan za pomocą modelu „Cisco Cloud Delivered”, przenosi ciężar
      zarządzania poszczególnymi komponentami sieci SD-WAN takimi jak: vManage,
      vSmart oraz vBond, na barki zespołu Cisco Ops.
    • Rozwiązania oferowane przez Cisco są globalnie
      dostępne z poziomu sieci publicznej (Microsoft Azure).
    • Cisco zapewnia wdrożenie zawansowanych narzędzi
      administracyjnych umożliwiając komunikacją pomiędzy platformą vManage a
      klientem za pomocą API, tym samym umożliwiając wdrażanie automatyzacji.

    Model – Partner Delivered

    • Wrażanie rozwiązania SD-Wan za pomocą modelu „Partner Delivered”, przenosi ciężar
      zarządzania poszczególnymi komponentami sieci SD-WAN takimi jak: vManage,
      vSmart oraz vBond, na barki partnera biznesowego firmy Cisco.
    • Rozwiązanie SD-WAN umożliwia współprace
      zewnętrznych narządzi automatyzujących prace administratora, z platformą
      vManage, za pomocą API, jak i innych produktów firmy Cisco takich jak: NSO czy
      VMS.
    • W przypadku wdrażania modelu Partner Delivered:
      • Partner
        Cisco zapewnia pełne utrzymanie struktury SD-WAN (vManage, vSmart oraz vBond) w
        własnym zakresie, utrzymując maszyny wirtualne na dostępnych witalizatorach: VMware
        ESXi, KVM, AWS bądź też Azure.
      • Wszelką
        odpowiedzialność za wdrażanie, konfigurację czy utrzymanie sieci SD-WAN ponosi
        partner biznesowy.
      • Klient
        końcowy może mieć dostęp do zarządzania własną siecią SD-WAN za pomocą platformy
        GUI (vManage), bądź też innego narzędzia przygotowanego przez partnera, które
        to następnie komunikuje się z vManage za pomocą API.
    • W dużej mierze partnerami korzystającymi z
      powyższego rozwiązania są dostawcy usług Internetowych.

    Model – Customer On-Prem

    • Wrażanie rozwiązania SD-Wan za pomocą modelu „Customer On-Prem”, przenosi ciężar
      zarządzania poszczególnymi komponentami sieci SD-WAN takimi jak: vManage,
      vSmart oraz vBond, na barki klienta.
    • Proces wdrażania, konfiguracji jak i
      zarządzania strukturą SD-WAN zostaje przeniesiony na barki klienta, który
      ponadto musi zadbać o odpowiednią infrastrukturę wirtualizacją mogącą bezpiecznie
      jak i wydajnie hostować dostęp do wszelkich komponentów sieci SD-WAN (vManage,
      vSmart oraz vBond). Obecnie dostępnymi środowiskami witalizacyjnymi umożliwiającymi
      oficjalne wdrożenie sieci SD-WAN są: VMware ESXi, KVM, AWS bądź też Azure.
    • Wszelkie zewnętrzne narzędzia administracyjne
      komunikujące się z konsolą vManage za pomocą API są dostępne dla klienta o ile
      je zakupi bądź też sam je zaprojektuje.
    • W dużej mierze klientami korzystającymi z
      powyższego rozwiązania są firmy bankowe czy też rządzy.

    Pozostałe tematy związane z SD-WAN

  • (T) Wprowadzenie do sieci SD-WAN*

    (T) Wprowadzenie do sieci SD-WAN*

    Wprowadzenie do sieci SD-WAN

    Cisco SD-WAN Architecture

    Zagadnienia związane z SD-WAN

    • Control Plane Module –
    • Switch Fabric –
    • Data Plane I/O Module –
    • vManage – Moduł zarządzający siecią SD-WAN.
    • vBond – Moduł wykrywający, a następnie autentykujący wszystkie komponenty wchodzące w skład sieci SD-WAN.
      • Moduł vBond powinien posiadać dostęp do sieci publicznej aby móc nawiązać kontakt z nowymi komponentami.
      • Każdy z komponentów sieci SD-WAN musi najpierw zarejestrować się w module vBond.
    • vSmart – Moduł dystrybucyjny propagujący trasy, polisy jak i inne informacje do ruterów brzegowych vEdge.
    • vAnalytics – Moduł analityczny sieci SD-WAN.
    • vEdge – Rutery brzegowe stanowiące kraniec sieci lokalnych, oddziałów głównych jak biur zdalnych.
    • cEdge – Rutery brzegowe stworzone przez Cisco (Rutery z serii ISR 1000 / 4000, ASR 1000 oraz ENCS 5100 / 5400).
    • OMP (Overlay Management protocol) –Połączenie umożliwiające bezpośrednią, bezpieczną wymianę danych pomiędzy modułami dystrybucyjnymi. Dzięki czemu wszystkie moduły dystrybucyjne są ze sobą zsynchronizowane.
    • DTLS/TLS Tunnel – Protokół umożliwiający bezpieczną wymianę informacji modułami dystrybucyjnymi.
      • DTLS (UDP) –
      • TLS (TCP) –
    • IPsec Tunnel – Jedynie możliwe do nawiązania połączenie pomiędzy ruterami brzegowymi. Urządzenie brzegowe nie wymieniają pomiędzy sobą informacji kontrolnych (Control Plane) a jedynie zwykł ruch sieciowy (Data Plane).
    • VPN (Cisco VRF) –
      • VPN 0 (Transport) –
      • VPN 512 (Management) –
      • VPN n (Service 1-65535) –

    TLOG

    • Site ID – Określa lokalizacje rutera brzegowego względem oddziału, biura do którego przynależy (Rutery brzegowe należące do tego samego oddziału nie będą nawiązywały łączności pomiędzy sobą).
    • System IP – Określa konkretne urządzenie brzegowe, za pomocą adresu IP (Router-ID).
    • Color – Opisuje medium transmisji danych, łączące rutery brzegowe (Internet, MPLS czy 4G), identyfikuje konkretne połączenie sieciowe pomiędzy ruterami. Wyróżniane zostały dwa rodzaje kolorów: Prywatne (Nie przewidujące wykorzystania translacji NAT) jak i Publiczne (Wykorzystujące translacje NAT).
    • TLOG (System IP + Color + Encapsulation) Transport Location – Unikalna wartość identyfikująca konkretny interfejs sieciowy rutera brzegowego (Endpoint),  (Enkapsulacja IPsec, GRE).
    • TLOG Extenction –

    Komponenty fizyczne wirtualne

    • vManage – Moduł występujący jedynie w postaci maszyny wirtualnej.
    • vBond – Moduł występujący jedynie w postaci maszyny wirtualnej.
    • vSmart – Moduł występujący jedynie w postaci maszyny wirtualnej.
    • vEdge – Ruter występujący zarówno w postaci maszyny wirtualnej jak i fizycznego urządzenia.

    Rodzaje topologii biur zdalnych

    • Branch Type 1 –
    • Branch Type 2 –

    Pozostałe tematy związane z SD-WAN

  • (Lx) Połączenie serialowe*

    (Lx) Połączenie serialowe*

    Konfiguracja połączenia serialowego

    Konfiguracja połączenia serialowego COM

    Server:/$ dmesg | grep tty

    Wyświetla dostępne połączenia konsolowe COM.

    Server:/$ apt-get install minicom

    Instaluje program do zarządzania połączeniami serialowymi.

    Server:/$ minicom -s

    Przechodzi do menu konfiguracji programu Minicom.

    Server:/$ minicom

    Odpala program Minicom. Następujące skróty klawiszowe powodują:
    * CTRL-A Z – Przechodzi do menu pomocy.
    *CTRL-A X – Wychodzi z programu.

    Pozostałe tematy związane z systemem Linux

  • (Lx) Monitorowanie ruchu sieciowego*

    (Lx) Monitorowanie ruchu sieciowego*

    Monitorowanie ruchu sieciowego

    Podstawowe komendy

    Server:/$ sudo tcpdump -i interfejs

    Włącza śledzenie ruchu sieciowego na danym porcie:
    * host adres-IP – Filtruje dane wyjściowe pod kontem wskazanego adresu IP.
    * net adres-IP/prefix – Filtruje dane wyjściowe pod kontem wskazanej sieci.
    * port port – Filtruje dane wyjściowe pod kontem wskazanego portu.
    * portrange zakres-portów – Filtruje dane wyjściowe pod kontem wskazanych portów [portrange 20-34].
    * src {adres-IP / port port} – Filtruje dane wyjściowe pod kontem wskazanego adresu źródłowego lub portu.
    * dst {adres-IP / port port} – Filtruje dane wyjściowe pod kontem wskazanego adresu docelowego lub portu.
    * protocol – Filtruje dane wyjściowe pod kontem wskazanego protokołu (IP, ICMP, UDP, TCP…).
    * {less liczba / greater liczba / <= liczba} – Wyświetla dane mniejsze, równe bądź większe od wskazanej liczby.
    * -i {nazwa-interfejsu / any} – Określa śledzony interfejs sieciowy.
    * -D – Wyświetla listę dostępnych interfejsów sieciowych.
    * -c liczba – Wyświetla określoną ilość pakietów.
    * -E klucz – Deszyfruje i wyświetla ruch IPSec z użyciem podanego klucza.
    * -q – Zmniejsza ilość wyświetlanych danych.
    * -e – Wyświetla docelowe i źródłowe adresy MAC.
    * -w plik – Zapisuje dane do wskazanego pliku.
    * -r plik – Wyświetla dane zawarte w wskazanym pliku.
    * {and / &&} – Łączy pojedyncze komendy w większą całość [tcpdump src port 20 && stc host 192.168.20.1].
    * and {not / !} – Nie wyświetla wskazanej zawartości [tcpdump src port 20 && ! icmp].

    Przykładowe komendy flirtujące ruch TCP

    Server:/$ sudo tcpdump {‘tcp[13] & 32!=0’ / ‘tcp[tcpflags] == tcp-urg’}

    Wyświetla wszystkie pakiety URG.

    Server:/$ sudo tcpdump {‘tcp[13] & 16!=0’/ ‘tcp[tcpflags] == tcp-ack’}

    Wyświetla wszystkie pakiety ACK.

    Server:/$ sudo tcpdump {‘tcp[13] & 4!=0’ / ‘tcp[tcpflags] == tcp-rst’}

    Wyświetla wszystkie pakiety RST.

    Server:/$ sudo tcpdump {‘tcp[13] & 2!=0’ / ‘tcp[tcpflags] == tcp-syn’}

    Wyświetla wszystkie pakiety SYN.

    Server:/$ sudo tcpdump {‘tcp[13] & 1!=0’ / ‘tcp[tcpflags] == tcp-fin’}

    Wyświetla wszystkie pakiety FIN.

    Server:/$ sudo tcpdump ‘tcp[13] & 8!=0’

    Wyświetla wszystkie pakiety PSH.

    Server:/$ sudo tcpdump ‘tcp[13]=18’

    Wyświetla wszystkie pakiety SYNACK.

    Pozostałe tematy związane z systemem Linux

  • (Lx) Konfiguracja ustawień sieciowych*

    (Lx) Konfiguracja ustawień sieciowych*

    Podstawowe ustawienia sieciowe

    Konfiguracja sieci przy użyciu pliku tekstowego

    Server:/$ sudo nano /etc/network/interfaces

    Przechodzi do pliku zawierającego konfiguracje kart sieciowych:
    * auto interfejs – Określa jakiego interfejsu będzie dotyczyła poniższa konfiguracja.
    * iface interfejs inet {static / dhcp} – Umożliwią skonfigurowanie adresu statycznego bądź protokołu DHCP.
    * address adres-IP-serwera
    * netmask maska
    * network adres-IP-sieci
    * gateway adres-IP-bramy
    * dns-nameservers adres-IP-DNS-u

    Server:/$ sudo ifdown interfejs

    Wyłącza interfejs w celu restart ustawień sieciowych.

    Server:/$ sudo ifup interfejs

    Ponownie włącza interfejs.

    Tworzenie trasy statycznej

    Server:/$ sudo ip route add adres-IP/prefix via adres-IP-następnego-skoku dev interfejs

    Tworzy statyczny wpis w tablicy routingu serwera.

    Server:/$ route –n

    Wyświetla zawartość tablicy routingu serwera.

    Konfiguracja serwera VIRL

    Czyszczenie konfiguracji domyślnej

    VIRL:/$ sudo ip link set interfejs down

    VIRL:/$ sudo ip link set lo down

    Konfiguracja statycznego adresu IP

    VIRL:/$ sudo ifconfig interfejs adres-IP netmask maska-sieci

    VIRL:/$ sudo ifconfig interfejs broadcast 255.255.255.255

    VIRL:/$ sudo ifconfig interfejs

    VIRL:/$ sudo ip route add default via adres-IP-bramy-domyślnej

    VIRL:/$ sudo route add default gw adres-IP-bramy-domyślnej

    Konfiguracja dynamicznego adresu IP

    VIRL:/$ sudo ifconfig interfejs dynamic

    Pozostałe tematy związane z systemem Linux