Laboratorium: Projektowanie i Wymiarowanie Sieci Campus (PiWSC)

Wykład 1 Definicja sieci Campus, Wykład 2 Model hierarchiczny Cisco.

Dynamicznie rozwijający się uniwersytet planuje budowę nowoczesnej sieci w nowym kampusie. Jako główny inżynier sieciowy musisz zaprojektować i wdrożyć fizyczną oraz logiczną strukturę opartą na klasycznym modelu trójwarstwowym. Sieć musi być gotowa na obsługę tysięcy użytkowników, zapewniając przy tym modularność i łatwość rozbudowy. Obecna struktura "płaska" powoduje liczne problemy z wydajnością i stabilnością. Twoim zadaniem jest stworzenie szkieletu, który oddzieli szybkie przełączanie w rdzeniu od agregacji polityk w warstwie dystrybucji i bezpośredniego dostępu dla użytkowników końcowych.

• Implementacja co najmniej 2 przełączników warstwy Core (L3) w architekturze nadmiarowej.
• Dodanie warstwy Distribution składającej się z 2 przełączników agregujących ruch z budynków.
• Wdrożenie warstwy Access z co najmniej 3 przełącznikami obsługującymi hosty końcowe.
• Zapewnienie połączeń typu 'full-mesh' między warstwami Core i Distribution.
• Konfiguracja opisów interfejsów (interface description) na wszystkich urządzeniach.
• Ustalenie planu adresacji IP dla połączeń punkt-punkt między switchami L3.
• Konfiguracja Hostname zgodna ze standardem uczelni (np. C-CORE-01, C-DIST-01).
• Weryfikacja fizycznej spójności łączy (show interfaces status).
• Włączenie protokołu LLDP lub CDP do wykrywania topologii sąsiedztwa.
• Ustawienie banerów informacyjnych (MOTD) o dostępie autoryzowanym.
• Zabezpieczenie trybu EXEC hasłem typu secret.
• Weryfikacja dostępności (ping) między bezpośrednio połączonymi interfejsami L3.

1. Uruchom GNS3 lub EVE-NG i utwórz nowy projekt dla laboratorium PiWSC.
2. Umieść dwa przełączniki warstwy L3 w roli Core (np. C-CORE-01 i C-CORE-02) używając obrazów IOL (IOS on Linux) lub odpowiednich routerów/switchów Cisco.
3. Umieść dwa przełączniki warstwy Distribution (np. C-DIST-01 i C-DIST-02) łącząc je kablami ethernetowymi z przełącznikami Core w topologii pełnego siatki (full-mesh) - każdy Distribution z każdym Core.
4. Umieść co najmniej trzy przełączniki warstwy Access (np. ACC-01, ACC-02, ACC-03) i połącz je z przełącznikami Distribution.
5. Skonfiguruj hostname na każdym urządzeniu zgodnie ze standardem uczelnianym (np. C-CORE-01, C-DIST-01, ACC-01) używając polecenia hostname.
6. Skonfiguruj hasło typu secret dla trybu EXEC poleceniem enable secret [hasło] na wszystkich urządzeniach.
7. Skonfiguruj baner MOTD (Message of the Day) poleceniem banner motd # informacja o autoryzowanym dostępie #.
8. Na każdym przełączniku Core skonfiguruj interfejsy L3 (gigabit ethernet) jako routingowe poleceniem no switchport i przypisz unikalne adresy IP z osobnych podsieci /30.
9. Użyj planu adresacji np. 10.0.0.0/30 dla połączeń Core-Core, 10.0.0.4/30 dla Core1-Dist1, itd. Maska /30 (255.255.255.252) zapewnia dokładnie 2 użyteczne adresy IP.
10. Skonfiguruj opis interfejsów (description) na każdym porcie, np. "## UPLINK_TO_CORE-01 ##" dla lepszej dokumentacji.
11. Włącz protokół LLDP globalnie poleceniem lldp run (lub CDP dla urządzeń Cisco-only) do wykrywania topologii sąsiedztwa.
12. Zweryfikuj fizyczne połączenia poleceniem show interfaces status i upewnij się, że wszystkie linki są w stanie up/up.
13. Przetestuj łączność ping między bezpośrednio połączonymi interfejsami L3 (np. z C-CORE-01 ping 10.0.0.2 do C-CORE-02).
14. Wykonaj zrzuty ekranu z topologii GNS3 oraz wyników poleceń weryfikacyjnych do sprawozdania.
15. W warstwie Core unikaj stosowania skomplikowanych list ACL - skoncentruj polityki bezpieczeństwa w warstwie dystrybucji dla maksymalnej wydajności przełączania.

Na podstawie przeprowadzonych ćwiczeń laboratoryjnych należy opracować następujące wnioski:

1. Model hierarchiczny trójwarstwowy (Core-Distribution-Access) zapewnia znacząco wyższą skalowalność w porównaniu z architekturą płaską (flat), ponieważ każda warstwa pełni odrębną i ściśle zdefiniowaną funkcję, co eliminuje problem "jeden przełącznik = cała sieć" i pozwala na niezależny rozwój poszczególnych warstw.
2. Redundancja w warstwie Core jest kluczowym elementem zapewnienia ciągłości działania uczelni – awaria pojedynczego przełącznika rdzeniowego nie powinna powodować przestoju w dostępie do zasobów, co w modelu płaskim skutkowałoby całkowitą utratą łączności dla wszystkich użytkowników.
3. Separacja warstw umożliwia optymalizację wydajności: warstwa Core zajmuje się wyłącznie szybkim przełączaniem (switching) bez obciążania procesora politykami bezpieczeństwa, warstwa Distribution agreguje ruch i stosuje polityki, a warstwa Access zapewnia bezpośredni dostęp dla użytkowników końcowych.
4. Implementacja pełnej matrycy połączeń (full-mesh) między warstwami Core i Distribution gwarantuje alternatywną ścieżkę transmisji danych w przypadku awarii dowolnego łącza, co zwiększa ogólną dostępność infrastruktury do wartości typowych dla środowisk produkcyjnych.
5. Model hierarchiczny umożliwia stopniowe zwiększanie przepustowości poprzez modernizację poszczególnych warstw bez konieczności przebudowy całej infrastruktury – np. wymiana przełączników Core na modele o wyższej wydajności nie wymusza zmian w warstwie dystrybucji ani dostępu.
6. Adresacja typu point-to-point (/30) dla połączeń między przełącznikami L3 jest standardem przemysłowym, który minimalizuje zużycie przestrzeni adresowej przy jednoczesnym zapewnieniu dokładnie dwóch użytecznych adresów IP na łącze.
7. Protokół LLDP (Link Layer Discovery Protocol) jest otwartym standardem umożliwiającym wykrywanie topologii sąsiedztwa niezależnie od producenta urządzeń, co ma kluczowe znaczenie w środowiskach akademickich z mieszaną infrastrukturą.
8. Zabezpieczenie trybu EXEC hasłem typu secret (a nie type 7) jest wymaganiem bezpieczeństwa, ponieważ hasła typu secret są szyfrowane algorytmem MD5, co uniemożliwia ich odczytanie z konfiguracji.
9. Opis interfejsów (description) jest fundamentalny dla dokumentacji sieci i przyszłego rozwiązywania problemów – brak dokumentacji utrudnia identyfikację połączeń i znacząco wydłuża czas lokalizacji usterek w środowiskach produkcyjnych.
10. Topologia full-mesh generuje wiele potencjalnych pętli warstwy 2, co wymaga włączenia protokołu STP/RSTP – bez niego połączenie wszystkich przełączników bezpośrednio skutkowałoby burzą rozgłoszeniową i całkowitym paraliżem sieci.

Wykład 3 VLAN, IEEE 802.1Q, Trunking, VTP (teoria).

W dziale administracji uczelni wykryto przypadek podsłuchiwania ruchu sieciowego między dziekanatem a rektoratem. Obecnie wszyscy użytkownicy znajdują się w jednej dużej domenie rozgłoszeniowej, co zagraża bezpieczeństwu danych osobowych. Twoim zadaniem jest przeprowadzenie logicznej segmentacji sieci przy użyciu technologii VLAN. Musisz odizolować ruch Studentów, Administracji oraz Gości, a następnie zapewnić przesyłanie tych segmentów między przełącznikami za pomocą łączy typu Trunk. Zwróć szczególną uwagę na zabezpieczenie łączy trunkingowych przez zmianę domyślnego VLANu natywnego, co zapobiegnie atakom typu VLAN Hopping.

• Stworzenie VLAN 10 (Administracja), VLAN 20 (Studenci) i VLAN 99 (Management).
• Nadanie czytelnych nazw dla każdego VLANu (np. ADMIN, STUDENTS, MGMT).
• Przypisanie portów dostępowych na przełącznikach ACC do odpowiednich VLANów.
• Konfiguracja połączeń między przełącznikami jako Trunk przy użyciu enkapsulacji dot1q.
• Zmiana Native VLAN na wszystkich łączach Trunk na VLAN 999 (nieużywany).
• Wyłączenie protokołu DTP (Dynamic Trunking Protocol) poleceniem switchport nonegotiate.
• Ograniczenie dozwolonych VLANów na trunku tylko do tych, które są faktycznie używane (allowed vlan).
• Weryfikacja konfiguracji poleceniem show vlan brief oraz show interfaces trunk.
• Udowodnienie braku komunikacji między hostami w różnych VLANach bez użycia routera.
• Zabezpieczenie nieużywanych portów przełącznika przez ich wyłączenie i przypisanie do martwego VLANu.
• Testowanie szczelności izolacji przy użyciu sniffera wpiętego w port innego VLANu.
• Udokumentowanie tagowania ramek 802.1Q w trybie symulacji GNS3.

1. Utwórz VLANy zgodnie z wymaganiami: VLAN 10 dla Administracji, VLAN 20 dla Studentów, VLAN 99 dla Management na każdym przełączniku poleceniem vlan [numer] a następnie name [nazwa].
2. Nadaj czytelne nazwy VLANom (np. name ADMIN, name STUDENTS, name MGMT) dla ułatwienia identyfikacji w tablicy VLAN.
3. Na przełącznikach Access przypisz porty do odpowiednich VLANów w trybie access poleceniem switchport mode access a następnie switchport access vlan [numer].
4. Skonfiguruj połączenia między przełącznikami jako Trunk używając polecenia switchport mode trunk na obu końcach łącza.
5. Wymuś enkapsulację dot1q poleceniem switchport trunk encapsulation dot1q (jeśli przełącznik wspiera obie enkapsulacje).
6. Zmień Native VLAN na VLAN 999 (nieużywany) na wszystkich łączach Trunk po obu stronach poleceniem switchport trunk native vlan 999 - musi być identyczny po obu stronach!
7. Wyłącz protokół DTP poleceniem switchport nonegotiate na portach Trunk dla zabezpieczenia przed nieautoryzowanym tworzeniem trunków.
8. Ogranicz dozwolone VLANy na trunku poleceniem switchport trunk allowed vlan 10,20,99 - tylko te VLANy, które są faktycznie używane.
9. Weryfikuj konfigurację VLAN poleceniem show vlan brief i show interfaces trunk.
10. Udowodnij izolację: podłącz hosty z różnych VLANów do tego samego przełącznika i sprawdź, że nie mogą się pingować bez routera.
11. Zabezpiecz nieużywane porty przełącznika poleceniem shutdown i przypisz je do nietworzonego VLANu (np. 1000) lub pozostaw w domyślnym VLANie 1 ale wyłączone.
12. Przetestuj szczelność izolacji używając sniffera (Wireshark) wpiętego w port innego VLANu - nie powinien widzieć ruchu z VLANu innego.
13. W trybie symulacji GNS3 zaobserwuj tagowanie ramek 802.1Q - sprawdź pole TPID (0x8100) i TCI zawierające VID.
14. Pamiętaj o błędzie Native VLAN Mismatch - jeśli po obu stronach trunku jest inny Native VLAN, pojawią się błędy STP i możliwa jest utrata łączności.
15. Uwaga: Pozostawienie Native VLAN jako 1 (domyślny) jest błędem konfiguracyjnym w kontekście bezpieczeństwa - atakujący może przechwycić ruch w nietagowanych ramkach.

Na podstawie przeprowadzonych ćwiczeń laboratoryjnych należy opracować następujące wnioski:

1. Domena rozgłoszeniowa (broadcast domain) to zbiór urządzeń, które odbierają ramki rozgłoszeniowe (broadcast frames) wysyłane w warstwie 2 – jej rozmiar bezpośrednio wpływa na wydajność CPU wszystkich urządzeń końcowych i przełączników, ponieważ każde urządzenie musi przetwarzać każdą ramkę broadcast niezależnie od jej faktycznego przeznaczenia.
2. Pozostawienie Native VLAN jako 1 (domyślny VLAN) jest poważnym błędem konfiguracyjnym w kontekście bezpieczeństwa, ponieważ atakujący może umieścić kartę sieciową w VLAN 1 i przechwycić cały ruch nietagowany przechodzący przez łącza trunk bez żadnego szyfrowania ani uwierzytelniania.
3. Zmiana Native VLAN na nieużywany (np. 999) eliminuje ryzyko ataku VLAN Hopping typu Double Tagging, ponieważ atakujący nie zna numeru nowego Native VLAN i nie może manipulować tagami 802.1Q.
4. Technologia VLAN zapewnia logiczną segmentację sieci niezależną od fizycznej topologii – można izolować ruch działów (Administracja, Studenci, Goście) przy użyciu jednej infrastruktury fizycznej, co znacząco redukuje koszty wdrożenia.
5. Trunk 802.1Q umożliwia przesyłanie wielu VLANów przez jedno fizyczne łącze poprzez dodanie znacznika (tag) identyfikującego VLAN docelowy, co jest niezbędne w środowiskach wielowarstwowych.
6. Protokół DTP (Dynamic Trunking Protocol) jest domyślnie włączony i stanowi potencjalne zagrożenie bezpieczeństwa – wyłączenie negocjacji trunk (switchport nonegotiate) zapobiega nieautoryzowanemu tworzeniu trunków przez atakującego.
7. Ograniczenie dozwolonych VLANów na trunku (allowed vlan list) jest najlepszą praktyką bezpieczeństwa, która zapobiega przesyłaniu ruchu z nieautoryzowanych VLANów nawet w przypadku kompromitacji przełącznika.
8. Wyłączenie nieużywanych portów przełącznika i przypisanie ich do martwego VLANu (np. 1000) eliminuje ryzyko podłączenia nieautoryzowanego urządzenia do sieci przez nieużywane gniazdko.
9. Izolacja VLAN warstwy 2 nie zapewnia komunikacji między segmentami – hosty w różnych VLANach NIE mogą się komunikować bez routera lub przełącznika warstwy 3, co jest zamierzonym zachowaniem realizującym zasadę najmniejszych przywilejów.
10. Poprawna konfiguracja Native VLAN po obu stronach trunku jest krytyczna – niezgodność (mismatch) skutkuje błędami STP, utratą łączności i potencjalnymi stormami rozgłoszeniowymi.

Wykład 4 Inter-VLAN Routing, SVI, Router-on-a-stick.

Po udanej segmentacji sieci na VLANy, użytkownicy z działu administracji zgłosili brak możliwości korzystania ze wspólnej drukarki sieciowej znajdującej się w innym segmencie. Izolacja warstwy 2 musi zostać uzupełniona o mechanizm routingu między VLANami, aby autoryzowany ruch mógł swobodnie przepływać między działami. Musisz wdrożyć dwa rozwiązania: tradycyjny "Router-on-a-Stick" dla mniejszych oddziałów oraz wydajny routing SVI (Switched Virtual Interface) na przełącznikach warstwy 3 w sercu kampusu. Celem jest zapewnienie płynnej komunikacji między hostami przy zachowaniu struktury VLANów.

• Konfiguracja subinterfejsów na routerze (np. g0/0.10, g0/0.20) dla modelu Router-on-a-stick.
• Włączenie enkapsulacji dot1q z odpowiednim numerem VLAN na każdym subinterfejsie.
• Uruchomienie interfejsów SVI (interface Vlan 10, 20) na przełączniku wielowarstwowym (MLS).
• Włączenie globalnego routingu na przełączniku MLS poleceniem 'ip routing'.
• Poprawna adresacja bramy domyślnej dla hostów w każdym z VLANów.
• Weryfikacja tabeli routingu (show ip route) na routerze i przełączniku L3.
• Testowanie łączności (ping) między komputerami w różnych VLANach.
• Użycie traceroute do udokumentowania ścieżki pakietu między segmentami.
• Porównanie wydajności (teoretyczne) obu rozwiązań w kontekście przepustowości magistrali trunk.
• Konfiguracja statycznego routingu powrotnego, jeśli jest to wymagane do pełnej dostępności.
• Zapewnienie, że interfejsy fizyczne routera są w stanie 'up/up'.
• Weryfikacja poprawności mapowania MAC-adresów w tabeli ARP po obu stronach routera.

1. Utwórz najpierw router-on-a-stick: na routerze wejdź w tryb konfiguracji interfejsu głównego (np. interface g0/0) i aktywuj go poleceniem no shutdown.
2. Skonfiguruj subinterfejsy dla każdego VLANu: interface g0/0.10 dla VLAN 10, interface g0/0.20 dla VLAN 20.
3. Na każdym subinterfejsie włącz enkapsulację dot1q poleceniem encapsulation dot1q [numer_vlan] oraz przypisz adres IP z odpowiedniej podsieci (np. 192.168.10.1/24 dla VLAN 10).
4. Skonfiguruj interfejsy SVI na przełączniku wielowarstwowym (MLS): najpierw upewnij się, że VLANy istnieją w bazie danych (vlan 10, vlan 20).
5. Włącz routing IP globalnie na MLS poleceniem ip routing jeśli nie jest włączony.
6. Utwórz interfejsy SVI poleceniem interface vlan 10 oraz interface vlan 20 i przypisz im adresy IP (bramy domyślne dla każdego VLANu).
7. Aktywuj interfejsy SVI poleceniem no shutdown - muszą być w stanie up/up.
8. Skonfiguruj bramy domyślne na hostach końcowych: dla VLAN 10 ustaw 192.168.10.1, dla VLAN 20 ustaw 192.168.20.1 jako default gateway.
9. Zweryfikuj tabelę routingu poleceniem show ip route na routerze (tramwaj) i na MLS (prefiks "C" przy trasach connected).
10. Testuj łączność między VLANami poleceniem ping z hosta w VLAN 10 do adresu IP hosta w VLAN 20.
11. Użyj traceroute (lub Windows tracert) do udokumentowania ścieżki pakietu przez router lub SVI.
12. Porównaj teoretyczną wydajność obu rozwiązań: Router-on-a-stick używa jednego interfejsu fizycznego dla wszystkich VLANów (potencjalne wąskie gardło), SVI na MLS przełącza w warstwie L2/L3 bez dodatkowego sprzętu.
13. Sprawdź tabelę ARP poleceniem show arp na obu urządzeniach, aby zweryfikować poprawne mapowanie adresów IP na adresy MAC.
14. Uwaga: interfejs fizyczny routera musi być aktywny (no shutdown), nawet jeśli nie ma przypisanego adresu IP - inaczej subinterfejsy nie będą działać.
15. Uwaga: jeśli interfejs SVI jest w stanie down, sprawdź czy VLAN istnieje w bazie danych (show vlan brief) i czy porty przełącznika są aktywne.

Na podstawie przeprowadzonych ćwiczeń laboratoryjnych należy opracować następujące wnioski:

1. Architektura "Router-on-a-stick" stanowi potencjalne wąskie gardło (bottleneck) sieci, ponieważ cały ruch między VLANami musi przechodzić przez pojedynczy interfejs fizyczny routera, co ogranicza przepustowość do maksymalnej prędkości tego interfejsu (np. 1 Gbps dla GigabitEthernet).
2. Routing SVI (Switched Virtual Interface) na przełącznikach warstwy 3 (MLS) jest preferowanym rozwiązaniem w nowoczesnych sieciach kampusowych, ponieważ przełączniki L3 przełączają pakiety w warstwie 2 (hardware-based), co zapewnia wielokrotnie wyższą wydajność niż routing softwareowy na routerach.
3. SVI eliminuje potrzebę stosowania routera do komunikacji między VLANami wewnątrz kampusu – przełącznik L3 realizuje routing z prędkością przełączania (Line-rate), osiągając pełną przepustowość łączy.
4. Interfejs fizyczny routera w konfiguracji "Router-on-a-stick" musi być aktywny (no shutdown), nawet jeśli nie ma przypisanego adresu IP – w przeciwnym razie subinterfejsy nie będą funkcjonować, ponieważ wymagają aktywnego interfejsu nadrzędnego.
5. Subinterfejsy routera używają enkapsulacji dot1q do tagowania ramek odpowiednim numerem VLAN, co umożliwia rozdzielenie ruchu na poszczególne VLANy przy użyciu jednego fizycznego interfejsu.
6. Brama domyślna (default gateway) musi być skonfigurowana na każdym hoście końcowym w każdym VLANie – bez poprawnej bramy host nie może komunikować się z hostami w innych VLANach ani z internetem.
7. Polecenie "ip routing" musi być włączone na przełączniku L3 przed skonfigurowaniem interfejsów SVI – domyślnie routing IP jest wyłączony na przełącznikach i musi być jawnie aktywowane.
8. Interfejs SVI musi mieć przypisany adres IP z podsieci odpowiadającej danemu VLANowi – adres SVI pełni rolę bramy domyślnej dla wszystkich hostów w tym VLANie.
9. Konieczność skonfigurowania tras powrotnych (return routes) jest często pomijana – router musi znać trasę do każdej podsieci źródłowej, aby pakiety powrotne mogły dotrzeć do nadawcy.
10. Użycie traceroute pozwala udokumentować faktyczną ścieżkę pakietu między VLANami – w przypadku Router-on-a-stick pakiety przechodzą przez router, podczas gdy w architekturze SVI pozostają w przełączniku L3.

Wykład 5 STP, RSTP (802.1w), Root Bridge Selection, Path Cost.

Aby zapewnić wysoką dostępność usług, sieć kampusowa została wyposażona w nadmiarowe połączenia fizyczne między wszystkimi przełącznikami. Niestety, po podłączeniu kabli na panelu kontrolnym routerów zapaliły się czerwone diody, a utrata pakietów sięgnęła 100% – doszło do powstania pętli w warstwie drugiej i burzy rozgłoszeniowej (broadcast storm). Twoim zadaniem jest poprawne skonfigurowanie protokołu Rapid Spanning Tree (RSTP), który automatycznie zablokuje nadmiarowe ścieżki. Musisz świadomie wybrać główne urządzenie zarządzające topologią (Root Bridge) i zoptymalizować czasy zbieżności sieci, aby użytkownicy nie odczuwali przerw w pracy dłuższych niż kilka sekund.

• Włączenie trybu 'spanning-tree mode rapid-pvst' na wszystkich przełącznikach.
• Wymuszenie roli Root Bridge dla głównego przełącznika Distribution (priorytet 4096).
• Skonfigurowanie zapasowego Root Bridge (priorytet 8192) dla zapewnienia odporności na awarię.
• Modyfikacja kosztów ścieżki (spanning-tree cost), aby wymusić ruch preferowanym łączem.
• Włączenie funkcji PortFast na portach dostępowych do komputerów (szybsza aktywacja).
• Włączenie BPDU Guard na portach z PortFast, aby zapobiec nieautoryzowanym mostom.
• Weryfikacja stanu portów (Designated, Root, Altn/Blk) poleceniem show spanning-tree.
• Analiza czasu zbieżności po fizycznym rozłączeniu jednego z kabli (symulacja awarii).
• Zidentyfikowanie identyfikatora mostu (Bridge ID) oraz adresu MAC jednostki centralnej.
• Ustalenie, który port został zablokowany i dlaczego (analiza kosztu i port ID).
• Weryfikacja stabilności topologii przy użyciu 'debug spanning-tree events'.
• Zastosowanie Load Balancingu opartego na VLANach (różne Root Bridge dla różnych VLANów).

1. Włącz tryb Rapid PVST na wszystkich przełącznikach poleceniem spanning-tree mode rapid-pvst - zapewnia szybszą zbieżność niż klasyczny STP.
2. Skonfiguruj główny przełącznik Distribution jako Root Bridge poleceniem spanning-tree vlan 10,20 root primary (auto ustawia priorytet na 4096) lub ręcznie spanning-tree vlan 10,20 priority 4096.
3. Skonfiguruj zapasowy Root Bridge (np. drugi Distribution) poleceniem spanning-tree vlan 10,20 root secondary lub priority 8192.
4. Zweryfikuj wybór Root Bridge poleceniem show spanning-tree - poszukaj wpisu z flagą "This bridge is the root".
5. Zmodyfikuj koszty ścieżki (spanning-tree cost) na wybranych portach, aby wymusić preferowaną ścieżkę, np. spanning-tree cost 19 na porcie gigabitethernet.
6. Włącz PortFast na portach dostępowych do komputerów poleceniem spanning-tree portfast na trybie interface (dla pojedynczego portu) lub spanning-tree portfast default globalnie.
7. Włącz BPDU Guard na portach z PortFast poleceniem spanning-tree bpduguard enable - chroni przed nieautoryzowanymi mostami (np. domowymi routerami studentów).
8. Weryfikuj stan portów poleceniem show spanning-tree - powinieneś zobaczyć role: Desg (Designated), Root, Altn/BLK (Alternate/Blocked).
9. Przetestuj zbieżność: fizycznie odłącz jeden kabel (lub wykonaj shutdown interfejsu) i zmierz czas potrzebny na zmianę stanu zablokowanego portu na forwarding.
10. Zidentyfikuj Bridge ID (priorytet+MAC) i zobacz adres MAC najważniejszego urządzenia - sprawdź show spanning-tree bridge.
11. Przeanalizuj który port jest zablokowany i dlaczego: obejrzyj koszt (cost) i port ID w tabeli show spanning-tree.
12. Włącz debugowanie zdarzeń STP poleceniem debug spanning-tree events dla zaawansowanej analizy (używaj ostrożnie na produkcji).
13. Skonfiguruj Load Balancing: dla różnych VLANów ustaw różne Root Bridge (np. DIST-01 dla VLAN 10, DIST-02 dla VLAN 20) co optymalizuje wykorzystanie łączy.
14. Pamiętaj: domyślny priorytet STP to 32768. Bez jawnej konfiguracji Root Bridge wybierze najniższy adres MAC - może to być najstarszy, najwolniejszy switch w szafie.
15. Zabezpieczenie: BPDU Guard automatycznie wyłącza port (err-disabled) po otrzymaniu BPDU z nieautoryzowanego urządzenia - wymaga ręcznego admin shutdown/no shutdown aby przywrócić.

Na podstawie przeprowadzonych ćwiczeń laboratoryjnych należy opracować następujące wnioski:

1. Wybór Root Bridge w protokole STP opiera się na najniższej wartości Bridge ID (priorytet + adres MAC) – bez jawnej konfiguracji Root Bridge zostanie wybrany przełącznik z najniższym adresem MAC, który może być najstarszym, najwolniejszym urządzeniem w szafie.
2. Klasyczny STP (802.1D) wymaga 30-50 sekund na zbieżność po awarii łącza (tylko 1 hello = 2 sekundy, Max Age = 20 sekund), podczas gdy Rapid STP (802.1w/RSTP) osiąga zbieżność w mniej niż 10 sekund (proposal/agreement mechanism).
3. Podłączenie nieautoryzowanego domowego routera do portu przełącznika bez BPDU Guard może spowodować przejęcie roli Root Bridge przez atakującego, co skutkuje przekierowaniem całego ruchu sieciowego przez urządzenie atakującego i umożliwia przechwytywanie danych (Man-in-the-Middle).
4. Funkcja PortFast na portach dostępowych znacząco przyspiesza ich aktywację (z pominięciem stanów Disabled → Blocking → Listening → Learning → Forwarding), co jest kluczowe dla urządzeń końcowych, które nie uczestniczą w STP.
5. BPDU Guard automatycznie wyłącza port (stan err-disabled) po otrzymaniu BPDU z nieautoryzowanego urządzenia, co wymaga ręcznej interwencji administratora do przywrócenia łączności – zabezpieczenie to chroni przed manipulacją topologią STP.
6. Zmiana kosztu ścieżki (spanning-tree cost) pozwala wymusić preferowaną ścieżkę ruchu – niższy koszt oznacza preferowaną ścieżkę, wyższy koszt oznacza ścieżkę zapasową.
7. Load Balancing oparty na VLANach (różne Root Bridge dla różnych VLANów) optymalizuje wykorzystanie łączy – każdy VLAN może korzystać z innego fizycznego połączenia, co zwiększa sumaryczną przepustowość.
8. Alternatywne porty (Alternate Ports) w RSTP są w stanie Discarding i gotowe do natychmiastowego przejęcia roli portu Root w przypadku awarii, co eliminuje straty czasowe związane z kolejnymi stanami STP.
9. Debugowanie zdarzeń STP (debug spanning-tree events) pozwala na szczegółową analizę procesu wyboru portów i zmian topologii, co jest nieocenione przy rozwiązywaniu problemów z zbieżnością.
10. Identyfikacja Bridge ID (priorytet + MAC) każdego przełącznika jest niezbędna do zrozumienia decyzji STP – polecenie show spanning-tree bridge wyświetla priorytet i adres MAC wszystkich przełączników w topologii.

Wykład 6 EtherChannel, LACP (802.3ad), PAgP, Load Balancing algorithms.

Główne łącze dosyłowe (uplink) między warstwą dostępu a dystrybucją osiągnęło 95% utylizacji w godzinach szczytu, co powoduje opóźnienia w systemach e-learningowych. Dodanie kolejnego kabla bez odpowiedniej konfiguracji spowoduje zablokowanie go przez protokół STP, co nie zwiększy sumarycznej przepustowości. Musisz wdrożyć technologię EtherChannel, która pozwoli na logiczne połączenie wielu fizycznych kabli w jeden szeroki kanał transmisji danych przy użyciu otwartego standardu LACP. Dzięki temu nie tylko zwiększysz pasmo, ale również zapewnisz natychmiastową nadmiarowość – awaria jednego kabla w wiązce nie przerwie pracy całej sieci.

• Fizyczne połączenie dwóch przełączników za pomocą co najmniej 2 (maks. 4 w labie) kabli Ethernet.
• Stworzenie wirtualnego interfejsu 'interface Port-channel 1'.
• Przypisanie interfejsów fizycznych do grupy 'channel-group 1 mode active'.
• Zastosowanie standardu LACP (industry standard) zamiast PAgP (Cisco proprietary).
• Konfiguracja interfejsu Port-channel jako Trunk (dot1q).
• Upewnienie się, że wszystkie parametry (speed, duplex, vlan) są identyczne na wszystkich portach in wiązce.
• Weryfikacja statusu wiązki poleceniem 'show etherchannel summary' (flagi P i U).
• Testowanie odporności: odłączenie jednego kabla podczas przesyłania dużego pliku i analiza strat.
• Sprawdzenie algorytmu Load Balancing (show etherchannel load-balance).
• Zmiana domyślnego mechanizmu równoważenia obciążenia na oparty o IP źródłowe i docelowe.
• Weryfikacja przepustowości logicznej (Bandwidth) interfejsu Port-channel.
• Dokumentacja pracy STP w kontekście nowopowstałego interfejsu logicznego.

1. Połącz fizycznie dwa przełączniki używając co najmniej 2 kabli ethernetowych (np. e1/0 i e1/1) pomiędzy tymi samymi parami portów na obu przełącznikach.
2. Wejdź w tryb konfiguracji interfejsów fizycznych (interface range e1/0 - 1 dla grupy) i przypisz je do grupy LACP poleceniem channel-group 1 mode active po obu stronach.
3. Użyj trybu active (aktywny LACP) zamiast PAgP lub trybu "on" - LACP jest otwartym standardem IEEE 802.3ad i zapewnia automatyczną negocjację.
4. Po przypisaniu portów do grupy automatycznie utworzy się wirtualny interfejs Port-channel 1 - sprawdź poleceniem show etherchannel summary (powinna być flaga "SU" oznaczająca Bundle).)
5. Skonfiguruj interfejs Port-channel jako Trunk poleceniem interface port-channel 1 a następnie switchport mode trunk i opcjonalnie switchport trunk allowed vlan.
6. Ważne: Konfiguruj parametry (speed, duplex, VLANy) na interfejsie Port-channel, NIE na poszczególnych portach fizycznych - zostaną automatycznie rozpropagowane.
7. Upewnij się, że wszystkie interfejsy fizyczne w wiązce mają identyczne parametry (prędkość, duplex, tryb) - inaczej LACP nie utworzy wiązki.
8. Zweryfikuj status EtherChannel poleceniem show etherchannel summary - flaga "P" oznacza PE (Physical), flaga "SU" oznacza Bundle (S=dialog, U=in Use).
9. Przetestuj odporność na awarie: podczas transferu dużego pliku odłącz jeden kabel fizyczny i obserwuj czy transmisja trwa (minimalne straty).
10. Sprawdź domyślny algorytm load-balancing poleceniem show etherchannel load-balance - zwykle oparty na źródłowym lub docelowym MAC.
11. Zmień algorytm na źródłowy i docelowy IP dla lepszego rozkładu obciążenia: port-channel load-balance src-dst-ip.
12. Zweryfikuj przepustowość logiczną interfejsu Port-channel poleceniem show interfaces port-channel 1 (Bandwidth = suma przepustowości wszystkich fizycznych portów).
13. Pamiętaj: EtherChannel jest widziany przez STP jako pojedyncze łącze - nie spowoduje pętli w warstwie L2.
14. Uwaga: Tryb "on" (static) nie negocjuje parametrów LACP - ryzykowny bo może prowadzić do niespójności. Zawsze używaj "active" lub "passive".
15. Uwaga: Pojedyncza sesja TCP nigdy nie przekroczy przepustowości jednego fizycznego kabla - EtherChannel pomaga przy wielu równoległych sesjach.

Na podstawie przeprowadzonych ćwiczeń laboratoryjnych należy opracować następujące wnioski:

1. EtherChannel jest widziany przez STP jako pojedyncze łącze logiczne – wszystkie fizyczne linki w wiązce są traktowane jako jeden port, co eliminuje problem pętli warstwy 2 i pozwala na pełne wykorzystanie wszystkich łączy bez blokady STP.
2. Standard LACP (IEEE 802.3ad) jest preferowany nad ręczną konfiguracją "mode on", ponieważ automatycznie negocjuje parametry wiązki i wykrywa niezgodności konfiguracyjne, co zapobiega problemom wynikającym z błędów konfiguracji.
3. Pojedyncza sesja TCP nigdy nie przekroczy prędkości jednego fizycznego kabla w wiązce, ponieważ EtherChannel rozprowadza ruch na poziomie pakietów (flow-based), nie sesji – do wykorzystania pełnej przepustowości potrzebne są wielokrotne równoległe sesje lub połączenia.
4. LACP automatic negocjacja (mode active lub passive) zapewnia, że oba końce wiązki mają identyczne parametry (prędkość, duplex, VLANy) – niezgodność parametrów fizycznych uniemożliwia utworzenie wiązki.
5. Konfiguracja interfejsu Port-channel, a nie poszczególnych portów fizycznych, jest obowiązkowa – parametry skonfigurowane na interfejsie wirtualnym są automatycznie rozpropagowane na wszystkie porty w wiązce.
6. Tryb active LACP inicjuje negocjację, podczas tryb passive tylko odpowiada na propozycje – przynajmniej jeden koniec musi być w trybie active.
7. Zmiana algorytmu load-balancing na src-dst-ip poprawia rozkład obciążenia w środowiskach z wieloma użytkownikami, ponieważ pakiety z różnych par źródło-docelowy są kierowane różnymi fizycznymi łączami.
8. Przepustowość logiczna interfejsu Port-channel jest sumą przepustowości wszystkich fizycznych portów w wiązce – np. 2 porty GigabitEthernet dają 2 Gbps przepustowości logicznej.
9. Awania jednego kabla w wiązce jest automatycznie kompensowana przez pozostałe kable – minimalizuje to straty pakietów podczas awarii fizycznych.
10. Load balancing oparty na samym adresie MAC źródłowym lub docelowym może prowadzić do nierównomiernego rozkładu obciążenia w sieciach z małą liczbą unikalnych adresów MAC – dlatego warto rozważyć algorytmy oparte na adresach IP.

Wykład 8 IPv4 addressing, IPv6 Global Unicast, DHCPv4, DHCP Relay Agent.

Wraz z wdrożeniem nowej sieci WiFi, liczba urządzeń końcowych drastycznie wzrosła, a ręczne przypisywanie adresów IP stało się niemożliwe. Dodatkowo, uczelnia otrzymała od dostawcy pulę adresów IPv6, co wymaga wdrożenia architektury Dual-Stack. Twoim zadaniem jest uruchomienie centralnego serwera DHCP (może to być router centralny), który będzie dynamicznie przydzielał adresy dla różnych VLANów. Ponieważ serwer znajduje się w innej podsieci niż studenci, musisz skonfigurować mechanizm DHCP Relay (ip helper-address) na bramach domyślnych. Równolegle należy włączyć adresację IPv6 typu GUA, aby zapewnić nowoczesną łączność z globalnym internetem.

• Konfiguracja puli DHCPv4 na routerze centralnym (pool ADMIN, pool STUDENTS).
• Wykluczenie adresów statycznych (bramy, serwery) z przydzielania przez DHCP.
• Ustawienie parametrów sieciowych: DNS, Gateway, Domain-name w puli DHCP.
• Konfiguracja 'ip helper-address' na interfejsach SVI przełącznika L3/routera.
• Włączenie routingu IPv6 poleceniem 'ipv6 unicast-routing'.
• Przypisanie adresów IPv6 (GUA) do interfejsów w standardzie 2001:db8::/64.
• Konfiguracja bezstanowej autokonfiguracji (SLAAC) dla hostów końcowych.
• Zweryfikowanie otrzymania adresacji przez hosty końcowe (ipconfig / all).
• Analiza komunikatów DHCP (Discover, Offer, Request, Ack) w programie Wireshark.
• Testowanie dostępności usług przy użyciu ping i ping6.
• Konfiguracja statycznego odwzorowania IPv4 dla wybranego serwera (DHCP Reservation).
• Udokumentowanie tablicy dzierżaw (show ip dhcp binding).

1. Skonfiguruj pulę DHCPv4 na routerze centralnym (lub przełączniku L3) poleceniem ip dhcp pool [nazwa_puli], np. ip dhcp pool ADMIN.
2. Zdefiniuj sieć dla puli poleceniem network [adres_sieci] [maska], np. network 192.168.10.0 255.255.255.0.
3. Ustaw domyślną bramę (default-router) i serwer DNS poleceniami default-router i dns-server [adres_IP].
4. Skonfiguruj nazwę domeny poleceniem domain-name [nazwa_domeny] dla klientów DHCP.
5. Wyklucz adresy z puli DHCP dla urządzeń statycznych (bramy, serwery) poleceniem ip dhcp excluded-address [początek] [koniec], np. ip dhcp excluded-address 192.168.10.1 192.168.10.10.
6. Na przełączniku L3 lub routerze (gdzie są bramy VLAN) włącz DHCP Relay poleceniem ip helper-address [adres_serwera_DHCP] na każdym interfejsie SVI (interface vlan X).
7. Włącz routing IPv6 globalnie poleceniem ipv6 unicast-routing na wszystkich routerach/przełącznikach L3.
8. Przypisz adresy IPv6 GUA (Global Unicast Address) do interfejsów używając notacji 2001:db8::/64 lub podobnej, np. ipv6 address 2001:db8:1::1/64.
9. Skonfiguruj bezstanową autokonfigurację SLAAC dla hostów końcowych poleceniem ipv6 address autoconfig na interfejsach routera (opcjonalnie).
10. Sprawdź otrzymanie adresacji na hostach: w Windows użyj ipconfig /all, w Linux ip addr show.
11. Uruchom Wireshark i zaobserwuj komunikaty DHCPv4: Discover (broadcast), Offer, Request, Acknowledgment - czteroetapowy proces DORA.
12. Testuj łączność IPv4 i IPv6 używając ping (dla IPv4) i ping6 (dla IPv6) do bramy i innych hostów.
13. Skonfiguruj statyczne odwzorowanie DHCP (reservation) dla wybranego serwera: ip dhcp pool, then host 192.168.10.100 255.255.255.0 i client-id.
14. Wyświetl tablicę dzierżaw DHCP poleceniem show ip dhcp binding - powinny widnieć wszystkie przydzielone adresy.
15. Pamiętaj: IPv6 nie używa broadcast - komunikaty DHCP są wysyłane multicastem (ff02::1:2 dla All DHCP Relay Agents). Router jako Relay zamienia broadcast na unicast.
16. Uwaga: Upewnij się, że router centralny ma trasę powrotną do podsieci, dla których przydziela adresy (routing musi działać w obie strony).

Na podstawie przeprowadzonych ćwiczeń laboratoryjnych należy opracować następujące wnioski:

1. Konfiguracja Stateful IPv6 (z serwerem DHCPv6) wymaga jawnego śledzenia stanu wszystkich adresówIPv6 w sieci, co zwiększa obciążenie administratora w porównaniu z trybem Stateless (SLAAC), ale umożliwia pełną kontrolę nad przydzielanymi adresami.
2. Konfiguracja Stateless IPv6 (SLAAC) pozwala hostom na automatyczne generowanie adresów IPv6 na podstawie prefixu ogłoszonego przez router i adresu MAC karty sieciowej, co eliminuje potrzebę serwera DHCPv6 i zmniejsza złożoność zarządzania.
3. Mechanizm DHCP Relay (ip helper-address) jest niezbędny w sieciach wielosegmentowych, ponieważ komunikaty DHCP są wysyłane broadcastem, który nie jest przekazywany przez routery między różnymi podsieciami – router musi "przekazać" zapytanie DHCP do serwera w innej podsieci.
4. W przeciwieństwie do IPv4, IPv6 nie używa broadcast – komunikaty DHCP są wysyłane multicastem (ff02::1:2 dla All DHCP Relay Agents), co wymaga innego podejścia do konfiguracji relay.
5. Przejście na IPv6 eliminuje potrzebę stosowania mechanizmów NAT, ponieważ przestrzeń adresowa jest praktycznie nieograniczona (2^128 adresów), co upraszcza architekturę sieci i eliminuje problemy z translacją adresów.
6. Serwer DHCP musi mieć skonfigurowane trasy powrotne do każdej podsieci, dla której przydziela adresy – bez trasy powrotnej pakiety odpowiedzi nie dotrą do klientów.
7. Wykluczenie adresów z puli DHCP (excluded-address) jest krytyczne dla urządzeń o stałych adresach IP (bramy, serwery, drukarki) – bez wykluczenia serwer DHCP może przydzielić adres już przypisany innemu urządzeniu.
8. Proces DORA (Discover, Offer, Request, Acknowledgment) w DHCPv4 składa się z czterech komunikatów broadcast – każdy z nich jest niezbędny do prawidłowego przydzielenia adresu IP.
9. SLAAC generuje adres IPv6 na podstawie prefixu otrzymanego od routera i identyfikatora interfejsu (IIF) wygenerowanego z adresu MAC – mechanizm ten zapewnia unikalność adresów bez udziału serwera.
10. Konfiguracja DNS i Domain Name w puli DHCP jest niezbędna dla prawidłowego działania usług sieciowych – bezpoprawnego DNS hosty nie mogą rozwiązywać nazw domen na adresy IP.

Wykład 7 Routing Table, Static Routes, Default Route, Administrative Distance.

Twoja sieć uniwersytecka posiada dwa niezależne łącza do Internetu: szybkie łącze światłowodowe (Main ISP) oraz zapasowe łącze radiowe (Backup ISP). Musisz skonfigurować routing tak, aby cały ruch domyślnie wychodził łączem głównym, a w przypadku jego awarii – automatycznie przełączał się na łącze zapasowe. Dodatkowo, wybrane podsieci serwerowe muszą komunikować się ze zdalnym oddziałem uczelni (Branch Office) poprzez dedykowany tunel, co wymaga precyzyjnego zdefiniowania tras statycznych. Twoim celem jest optymalizacja tablicy routingu i zapewnienie wysokiej dostępności wyjścia na świat.

• Konfiguracja trasy domyślnej (0.0.0.0/0) skierowanej do Main ISP.
• Implementacja pływającej trasy domyślnej (Floating Default Route) z wyższą wartością Administrative Distance (np. 200) skierowanej do Backup ISP.
• Konfiguracja tras statycznych do konkretnych sieci zdalnych oddziałów.
• Uzycie interfejsów wyjściowych oraz adresów Next-Hop w definicjach tras.
• Konfiguracja trasy sumarycznej (Summary Route) w celu zmniejszenia rozmiaru tablicy routingu.
• Weryfikacja priorytetów tras w tablicy routingu (show ip route).
• Symulacja awarii łącza głównego (shutdown interfejsu) i obserwacja przełączenia na Backup.
• Udokumentowanie zmiany Administrative Distance dla trasy pływającej.
• Zastosowanie trasy statycznej typu 'Recursive Lookup' i wyjaśnienie jej działania.
• Konfiguracja domyślnej trasy IPv6 (::/0).
• Testowanie ścieżek przy użyciu polecenia traceroute.
• Wyjaśnienie zasady 'Longest Match' przy wyborze trasy przez router.

1. Skonfiguruj trasę domyślną do głównego ISP poleceniem ip route 0.0.0.0 0.0.0.0 [adres_next_hop] lub [interfejs_wyjściowy].
2. Skonfiguruj pływającą trasę domyślną (floating static route) do zapasowego ISP z wyższym dystansem administracyjnym, np. ip route 0.0.0.0 0.0.0.0 [backup_ip] 100.
3. Ważne: Dystans administracyjny (AD) dla trasy statycznej to domyślnie 1. Ustaw AD trasy zapasowej większy niż 1 ale mniejszy niż 255 (np. 50, 100 lub 200).
4. Skonfiguruj trasy statyczne do sieci oddziałów: ip route [sieć_docelowa] [maska] [next_hop], np. ip route 192.168.100.0 255.255.255.0 10.1.1.1.
5. Użyj interfejsu wyjściowego lub adresu next-hop w definicjach tras - oba sposoby działają, next-hop wymaga istniejącej trasy do tego adresu.
6. Skonfiguruj trasę sumaryczną (summary route) dla redukcji rozmiaru tablicy routingu, np. ip route 192.168.0.0 255.255.0.0 10.1.1.1 agreguje wszystkie /24.
7. Wyświetl tablicę routingu poleceniem show ip route - trasy statyczne są oznaczone literą "S", trasa domyślna "S*". Sprawdź kolumnę AD.
8. Symuluj awarię łącza głównego poleceniem shutdown na interfejsie WAN i obserwuj automatyczne przejęcie trasy zapasowej (Floating Route).
9. Udokumentuj zmianę AD w show ip route - trasa zapasowa pojawi się w tabeli dopiero gdy trasa główna będzie niedostępna.
10. Skonfiguruj trasę rekurencyjną (recursive lookup): ip route 0.0.0.0 0.0.0.0 [IP_następnego_hopa], gdzie router sam znajdzie trasę do tego IP.
11. Skonfiguruj trasę domyślną IPv6 poleceniem ipv6 route ::/0 [interfejs_lub_ipv6_next_hop].
12. Testuj ścieżki poleceniem traceroute - pokaże hopsy do celu. Sprawdź różnice dla trasy głównej i zapasowej.
13. Wyjaśnij zasadę Longest Match: router wybiera trasę z najdłuższym dopasowaniem maski (/24 vs /16 = wybiera /24).
14. Pamiętaj: Jeśli AD będzie takie same dla obu tras, router użyje Equal Cost Multi Path (ECMP) i rozdzieli ruch oboma łączami.
15. Uwaga: Trasa sumaryczna musi pokrywać wszystkie bardziej szczegółowe trasy - aggregation wymaga zgodności bitów maski.

Na podstawie przeprowadzonych ćwiczeń laboratoryjnych należy opracować następujące wnioski:

1. Dystans administracyjny (AD) to wartość zaufania przypisana każdej trasie – trasy z niższym AD są preferowane, nawet jeśli mają gorszą metrykę, co pozwala na priorytetyzację tras (główna vs zapasowa).
2. Routing statyczny generuje znacznie mniejsze obciążenie CPU routera niż routing dynamiczny, ponieważ router nie musi przeliczać algorytmu routingu ani wymieniać informacji z sąsiadami – jest to zaleta w małych sieciach.
3. W dużych sieciach ręczne zarządzanie trasami statycznymi jest niewykonalne – każda zmiana topologii wymaga ręcznej rekonfiguracji wszystkich routerów, co generuje błędy i opóźnienia.
4. Trasa sumaryczna (Summary Route) jest kluczowa dla wydajności routerów brzegowych, ponieważ agreguje wiele tras szczegółowych do jednego wpisu w tablicy routingu, co zmniejsza rozmiar tablicy i obciążenie CPU.
5. Trasa pływająca (Floating Default Route) z wyższym AD (np. 200) pozostaje nieaktywna tak długo, jak trasa główna jest dostępna – aktywuje się automatycznie po awarii trasy głównej, co zapewnia automatyczny failover.
6. Zasada Longest Match (najdłuższe dopasowanie) oznacza, że router wybiera trasę z najdłuższą maską – np. trasa /24 jest preferowana nad trasą /16 dla sieci 10.1.10.0/24.
7. Konfiguracja interfejsu wyjściowego w trasie statycznej wymaga, aby interfejs był aktywny i miał adres IP – trasa z interfejsem wyjściowym jest preferowana nad trasą z next-hop.
8. Trasa rekurencyjna (recursive lookup) wymaga, aby istniała trasa do adresu next-hop – router najpierw znajduje trasę do next-hop, a następnie przesyła pakiet.
9. W przypadku jednakowych AD dla wielu tras router stosuje ECMP (Equal Cost Multi Path) i rozdziela ruch równo między wszystkie trasy – może to powodować asymetryczny przepływ ruchu.
10. Trasa domyślna (0.0.0.0/0) jest ostatnią deską ratunku – jest używana tylko wtedy, gdy nie ma żadnej innej pasującej trasy w tablicy routingu.

Wykład 8 Dynamic Routing, Link-State protocols, OSPFv2, Router-ID, Area 0.

Sieć kampusowa rozrosła się do kilkunastu routerów, co sprawia, że ręczna aktualizacja tras statycznych przy każdej zmianie topologii kończy się błędami i przerwami w działaniu. Postanowiono wdrożyć protokół dynamicznego routingu stanu łącza – OSPF. Twoim pierwszym krokiem jest uruchomienie OSPF v2 w obrębie jednego obszaru (Area 0). Musisz zapewnić, by wszystkie routery wewnątrz kampusu "widziały się" nawzajem i automatycznie wymieniały informacje o dostępnych podsieciach. Skonfiguruj proces OSPF, zdefiniuj identyfikatory routerów i upewnij się, że sąsiedztwa są stabilne, co pozwoli na błyskawiczną zbieżność sieci po awarii dowolnego łącza.

• Uruchomienie procesu OSPF na wszystkich routerach (router ospf 1).
• Ręczne ustawienie unikalnego Router-ID dla każdego urządzenia.
• Rozgłaszanie bezpośrednio podłączonych sieci do Area 0 przy użyciu komendy 'network' z maską blankietową (wildcard mask).
• Konfiguracja interfejsów pasywnych (passive-interface) w stronę użytkowników końcowych (bezpieczeństwo).
• Weryfikacja stanów sąsiedztwa (show ip ospf neighbor) – oczekiwany stan FULL.
• Sprawdzenie bazy danych stanu łącza (show ip ospf database).
• Modyfikacja kosztu interfejsu (ip ospf cost) i obserwacja wpływu na wybór trasy.
• Propagacja trasy domyślnej do domeny OSPF (default-information originate).
• Analiza metryki OSPF (koszt jako suma odwrotności przepustowości).
• Weryfikacja zbieżności: wyłączenie łącza i czas pojawienia się nowej trasy w tablicy.
• Ustawienie autentykacji MD5 między routerami dla zwiększenia bezpieczeństwa.
• Włączenie logowania zmian stanów sąsiedztwa (log-adjacency-changes).

1. Uruchom proces OSPF na każdym routerze poleceniem router ospf [pid], gdzie PID to numer procesu (np. 1) - może być różny na każdym routerze.
2. Skonfiguruj unikalny Router-ID dla każdego routera poleceniem router-id [adres_IP], np. 1.1.1.1. Jeśli nie ustawisz, router użyje najwyższego IP interfejsu loopback lub fizycznego.
3. Rozgłoś bezpośrednio podłączone sieci do Area 0 poleceniem network [adres] [wildcard_mask] area 0 - używaj wildcard mask (odwrócona maska podsieci).
4. Przykłady wildcard mask: dla /24 (255.255.255.0) będzie 0.0.0.255, dla /30 (255.255.255.252) będzie 0.0.0.3.
5. Skonfiguruj interfejsy passive w stronę użytkowników końcowych poleceniem passive-interface [interfejs] lub passive-interface default - zapobiega przesyłaniu Hello.
6. Ważne: Interfejs passive NIE będzie aktywnym interfejsem OSPF - sieci za nim NIE będą rozgłaszane do innych routerów.
7. Weryfikuj sąsiedztwo poleceniem show ip ospf neighbor - oczekiwany stan FULL (Full Exchange), czasem 2-WAY dla DR/BDR.
8. Sprawdź bazę danych LSA (Link State Database) poleceniem show ip ospf database - powinieneś widzieć Router LSA (typ 1) i Network LSA (typ 2).
9. Zmodyfikuj koszt interfejsu OSPF poleceniem ip ospf cost [wartość] (1-65535, niższy koszt = preferowana ścieżka) i obserwuj zmianę trasy.
10. Propaguj trasę domyślną do domeny OSPF poleceniem default-information originate w trybie konfiguracji routera OSPF.
11. Przeanalizuj metrykę OSPF: metryka = suma kosztów wszystkich łączy na ścieżce (domyślnie cost = 100/bandwidth w Mbps).
12. Przetestuj zbieżność: wyłącz interfejs (shutdown) i mierz czas pojawienia się alternatywnej trasy - RSTP Convergence < 50 sekund.
13. Skonfiguruj autentykację MD5 poleceniem ip ospf message-digest-key 1 md5 [hasło] i area 0 authentication message-digest.
14. Włącz logowanie zmian sąsiedztwa poleceniem log-adjacency-changes w trybie konfiguracji OSPF dla monitorowania.
15. Pamiętaj: Interfejs passive jest kluczowy dla bezpieczeństwa - zapobiega wysyłaniu Hello do sieci bez routerów (oszczędza pasmo i blokuje manipulacje routingiem).

Na podstawie przeprowadzonych ćwiczeń laboratoryjnych należy opracować następujące wnioski:

1. Algorytm SPF (Dijkstra) w protokołach stanu łącza oblicza najkrótszą ścieżkę do każdego celu na podstawie kosztu łączy – każdy router posiada pełną mapę sieci (LSDB), co zapewnia szybką zbieżność.
2. OSPF jest lepszym wyborem dla sieci kampusowej niż RIP, ponieważ OSPF oferuje szybszą zbieżność (sekundy vs minuty), nieograniczoną liczbę przeskoków (RIP max 15), hierarchiczną strukturę obszarów i niższe zużycie pasma.
3. Router-ID pełni rolę unikalnego "podpisu" każdego routera w domenie OSPF – jest używany do identyfikacji sąsiadów, wyboru DR/BDR i rozgłaszania tras. Router-ID musi być unikalny w całej domenie OSPF.
4. Interfejsy passive zapobiegają wysyłaniu pakietów Hello do sieci bez routerów, co oszczędza pasmo i chroni przed manipulacją routingiem przez atakującego w segmencie użytkowników.
5. Metryka OSPF (koszt) jest obliczana jako suma odwrotności przepustowości wszystkich łączy na ścieżce – domyślnie cost = 100 / bandwidth (Mbps), co preferuje łącza o wyższej przepustowości.
6. Autentykacja MD5 zapewnia, że tylko autoryzowane routery mogą uczestniczyć w wymianie informacji OSPF – chroni przed fałszywymi routerami i manipulacją tablicy routingu.
7. Propagacja trasy domyślnej (default-information originate) włącza trasę domyślną do tablic routingu wszystkich routerów w obszarze, co jest przydatne przy połączeniu z internetem przez jeden router brzegowy.
8. Stan sąsiedztwa FULL oznacza pełną wymianę informacji LSA – routery są w pełni zsynchronizowane i gotowe do wymiany tras. Stan 2-WAY jest wystarczający dla DR/BDR w sieciach wielodostępowych.
9. Baza danych LSDB (Link State Database) zawiera wszystkie LSA w obszarze – zgodność LSDB na wszystkich routerach w tym samym obszarze jest warunkiem poprawnego routingu OSPF.
10. Logowanie zmian sąsiedztwa (log-adjacency-changes) jest kluczowe dla monitorowania stabilności sieci – nagłe zmiany stanów sąsiedztwa mogą wskazywać na problemy fizyczne lub konfiguracyjne.

Wykład 9 Hierarchical OSPF, Area types, ABR, ASBR, LSA types, Route Summarization.

Twoja domena OSPF rozrosła się do punktu, w którym baza danych LSDB staje się zbyt duża, a każde "mignięcie" łącza w odległym akademiku wymusza przeliczenie algorytmu SPF na wszystkich routerach w kampusie, paraliżując pracę rdzenia. Musisz pilnie wdrożyć strukturę wieloobszarową (Multi-Area), aby odizolować od siebie różne części sieci. Wyznacz obszar szkieletowy (Area 0) oraz obszary satelitarne (np. Area 1 dla Wydziału Informatyki, Area 2 dla Administracji). Twoim zadaniem jest konfiguracja routerów ABR, które będą pełniły rolę bariery dla szczegółowych informacji topologicznych i agregowały trasy, co znacząco odciąży procesory wszystkich urządzeń.

• Zaprojektowanie hierarchii z centralnym Area 0 i co najmniej dwoma obszarami nie-szkieletowymi.
• Prawidłowa konfiguracja routerów ABR (interfejsy w różnych obszarach).
• Implementacja agregacji tras (Area Range) na routerach ABR w celu wysyłania tras sumarycznych.
• Weryfikacja różnych typów tras w tablicy (O - intra, O IA - inter-area).
• Analiza bazy danych LSDB pod kątem różnych typów LSA (Router LSA, Network LSA, Summary LSA).
• Konfiguracja routera jako ASBR i redystrybucja tras zewnętrznych (np. statycznych).
• Przegląd statusu routerów (show ip ospf) i identyfikacja ich ról w hierarchii.
• Ograniczenie floodingu LSA poprzez zastosowanie obszarów typu Stub (opcjonalnie dla chętnych).
• Testowanie zbieżności wewnątrz jednego obszaru i sprawdzenie braku wpływu na SPF w Area 0.
• Weryfikacja metryki dla tras międzyobszarowych.
• Stworzenie dokumentacji podziału obszarów z uzasadnieniem granic.
• Analiza wpływu braku połączenia z Area 0 na poprawność routingu.

1. Zaprojektuj hierarchię OSPF: Area 0 jako szkieletowy, Area 1 dla Wydziału Informatyki, Area 2 dla Administracji - Area 0 musi być ciągłe.
2. Skonfiguruj routery ABR (Area Border Router) - muszą mieć interfejsy w minimum dwóch obszarach, w tym obowiązkowo w Area 0.
3. Na ABR skonfiguruj sieci w odpowiednich obszarach poleceniem network [adres] [wildcard_mask] area [numer_area].
4. Zaimplementuj agregację tras na ABR poleceniem area [numer] range [adres_sieci] [maska_podsieci] - UWAGA: używa NORMALNEJ maski (nie wildcard!).
5. Przykład: area 1 range 10.1.0.0 255.255.0.0 agreguje wszystkie sieci 10.1.X.X do jednej trasy 10.1.0.0/16.
6. Zweryfikuj typy tras w tablicy routingu: "O" = intra-area (w tym samym obszarze), "O IA" = inter-area (między obszarami).
7. Przeanalizuj bazę LSDB poleceniem show ip ospf database - powinieneś widzieć różne typy LSA: Router (typ1), Network (typ2), Summary (typ3/4).
8. Skonfiguruj ASBR (router na granicy z inną domeną routingu) i wykonaj redystrybucję tras statycznych poleceniem redistribute static subnets.
9. Sprawdź status procesu OSPF poleceniem show ip ospf - pokaże rolę każdego routera (Internal, ABR, ASBR).
10. Opcjonalnie: skonfiguruj obszar Stub poleceniem area [numer] stub na wszystkich routerach w obszarze - zmniejsza propagację LSA typ 5.
11. Przetestuj zbieżność: wyłącz łącze w jednym obszarze i sprawdź czy nie wpływa na SPF w Area 0 - izolacja awarii działa.
12. Weryfikuj metrykę tras międzyobszarowych - jest sumą kosztu do ABR + kosztu ABR do sieci docelowej.
13. Stwórz dokumentację podziału obszarów z uzasadnieniem granic (np. granice organizacyjne, fizyczne budynki).
14. Przeanalizuj wpływ braku połączenia z Area 0 - jeśli obszar nie jest połączony z Area 0, trasy międzyobszarowe nie będą działać!
15. Uwaga: Agregacja tras (summarization) możliwa jest TYLKO na ABR lub ASBR - NIGDY wewnątrz standardowego obszaru.
16. Uwaga: Polecenie "network" używa WILDCARD mask, ale "area range" używa STANDARDOWEJ maski podsieci - częsty błąd!

Na podstawie przeprowadzonych ćwiczeń laboratoryjnych należy opracować następujące wnioski:

1. LSA typu 3 (Summary LSA) jest generowane przez router ABR i przenosi informacje o trasach między obszarami – umożliwia komunikację między obszarami bez ujawniania szczegółowej topologii wewnątrz obszarów.
2. Area 0 (obszar szkieletowy) musi być ciągłe (contiguous) – wszystkie obszary muszą być bezpośrednio lub pośrednio połączone z Area 0, w przeciwnym razie trasy międzyobszarowe nie będą funkcjonować.
3. Podział na obszary zwiększa stabilność sieci, ponieważ zmiany topologii w jednym obszarze nie wymuszają przeliczenia SPF w innych obszarach – izolacja awarii lokalnych chroni przed paraliżem całej domeny.
4. Agregacja tras (area range) na ABR jest możliwa tylko dla tras wewnątrz danego obszaru – agreguje sieci z obszaru do jednego wpisu przed wysłaniem do Area 0, co zmniejsza rozmiar LSDB w innych obszarach.
5. Routery ABR pełnią rolę bariery dla szczegółowych informacji topologicznych – nie rozgłaszają szczegółowych LSA typu 1 i 2 z jednego obszaru do drugiego, co chroni przed rozrostem bazy danych.
6. LSA typu 5 (External LSA) rozgłaszają trasy zewnętrzne (np. z redystrybucji) na całą domenę OSPF i mogą być filtrowane na ABR w obszarach Stub.
7. Trasy międzyobszarowe (O IA) mają wyższą metrykę niż trasy wewnątrzobszarowe (O) – metryka jest sumą kosztu do ABR i kosztu ABR do sieci docelowej.
8. Routery ASBR (Autonomous System Boundary Router) redystrybuują trasy z innych domen routingu (statyczne, RIP, connected) do OSPF – umożliwiają komunikację między różnymi protokołami routingu.
9. Obszary Stub zmniejszają rozmiar LSDB poprzez zastąpienie LSA typu 5 trasą domyślną – wszystkie trasy zewnętrzne są dostępne przez ABR z jedną trasą domyślną.
10. Brak połączenia z Area 0 powoduje, że obszar staje się "stub area" bez łączności z resztą domeny – trasy międzyobszarowe nie będą rozgłaszane, a komunikacja z innymi obszarami będzie niemożliwa.

Wykład 10 Network Security at Layer 2, Port Security, MAC address sticky, Violation modes.

W bibliotece uniwersyteckiej regularnie dochodzi do kradzieży pasma przez osoby postronne, które odłączają komputery stacjonarne i podpinają własne routery/laptopy, co często prowadzi do ataków typu Man-in-the-Middle lub pętli sieciowych. Musisz wdrożyć rygorystyczną politykę bezpieczeństwa na portach dostępowych. Skonfiguruj mechanizm Port Security tak, aby do każdego gniazdka mógł być podpięty tylko jeden, konkretny, autoryzowany komputer. Jeśli przełącznik wykryje obcy adres MAC, musi natychmiast wyłączyć port i wysłać powiadomienie do administratora, uniemożliwiając nieautoryzowany dostęp do zasobów kampusu.

• Włączenie Port Security na wszystkich aktywnych interfejsach dostępowych.
• Ograniczenie maksymalnej liczby dozwolonych adresów MAC do 1 na port.
• Zastosowanie funkcji 'mac-address sticky', aby przełącznik na stałe zapamiętał pierwszy podłączony numer MAC.
• Konfiguracja trybu naruszenia (violation mode) na 'shutdown' (całkowite wyłączenie portu).
• Konfiguracja drugiego portu w trybie 'restrict' (blokowanie ruchu, ale port pozostaje aktywny).
• Ręczne wpisanie jednego z adresów MAC do konfiguracji (static secure MAC).
• Symulacja ataku poprzez zmianę adresu MAC karty sieciowej hosta (lub podpięcie innego urządzenia w GNS3).
• Weryfikacja statusu portu po naruszeniu (stan err-disabled).
• Przywracanie portu do działania po naruszeniu (shutdown / no shutdown).
• Udokumentowanie komunikatów logów systemowych po wykryciu ataku.
• Przegląd tabeli bezpiecznych adresów (show port-security address).
• Sprawdzenie ogólnych statystyk bezpieczeństwa przełącznika (show port-security).

1. Na każdym porcie dostępowym (access port) włącz Port Security poleceniem switchport port-security w trybie konfiguracji interfejsu.
2. Ważne: Port musi być w trybie access (switchport mode access) - na portach trunk Port Security zwykle nie działa.
3. Ogranicz maksymalną liczbę dozwolonych adresów MAC do 1 poleceniem switchport port-security maximum 1.
4. Włącz funkcję sticky (zapamiętywanie pierwszego MAC) poleceniem switchport port-security mac-address sticky - zapisuje pojawiający się adres w konfiguracji.
5. Skonfiguruj tryb naruszenia (violation) na shutdown poleceniem switchport port-security violation shutdown - port zostanie wyłączony (err-disabled) po naruszeniu.
6. Skonfiguruj drugi port w trybie restrict: switchport port-security violation restrict - blokuje ruch ale port pozostaje aktywny (wysyła logi).
7. Skonfiguruj statyczny bezpieczny adres MAC poleceniem switchport port-security mac-address [adres_MAC] (np. aaaa.bbbb.cccc) - ręcznie przypisany.
8. Podłącz w GNS3 drugie urządzenie (lub zmień MAC w emulatorze karty sieciowej) do tego samego portu, aby zasymulować atak.
9. Po naruszeniu sprawdź stan portu - będzie err-disabled (show interface status pokaże err-disable).
10. Przywróć port: najpierw wyłącz (shutdown), potem włącz (no shutdown) - lub użyj errdisable recovery.
11. Wyświetl logi systemowe po wykryciu ataku - poleceniem show log lub bezpośrednio na konsoli.
12. Przeglądaj tabelę bezpiecznych adresów poleceniem show port-security address - pokaże wszystkie dozwolone MAC.
13. Sprawdź ogólne statystyki bezpieczeństwa przełącznika poleceniem show port-security - licznik naruszeń, aktywnych portów.
14. Uwaga: Adresy MAC "sticky" są zapisywane w konfiguracji bieżącej (running-config) - musisz zapisać konfigurację (copy run start) aby przetrwały restart.
15. Uwaga: Tryb Protect blokuje ruch bez logowania - używaj Restrict lub Shutdown do monitorowania bezpieczeństwa.
16. Zabezpieczenie: Po restarcie przełącznika bez zapisanej konfiguracji sticky adresy zostaną utracone i port będzie wymagał nowego "nauczenia".

Na podstawie przeprowadzonych ćwiczeń laboratoryjnych należy opracować następujące wnioski:

1. Tryb Protect blokuje ruch z nieautoryzowanych MAC bez generowania logów – jest niewystarczający do monitorowania bezpieczeństwa i wykrywania prób ataku, dlatego zaleca się stosowanie trybu Restrict lub Shutdown.
2. Tryb Restrict blokuje ruch z nieautoryzowanych MAC, ale port pozostaje aktywny i generuje logi – odpowiedni dla środowisk, gdzie ciągłość dostępu jest krytyczna, ale administrator chce być powiadamiany o naruszeniach.
3. Tryb Shutdown całkowicie wyłącza port (stan err-disabled) po naruszeniu – najbezpieczniejszy tryb, który wymaga ręcznej interwencji administratora do przywrócenia łączności, co skutecznie blokuje atakującego.
4. Port Security jest podstawowym, ale niewystarczającym elementem zabezpieczania warstwy 2 – nie chroni przed atakami na warstwie 3+ (np. IP Spoofing, DDoS) ani przed atakami na uwierzytelnianie (np. 802.1X bypass).
5. Atak typu MAC Spoofing polega na podszyciu się pod autoryzowany adres MAC – Port Security z trybem sticky zapobiega temu, ponieważ zapisuje pierwszy wykryty adres w konfiguracji.
6. Funkcja 802.1X (Port-based Network Access Control) jest rozszerzeniem Port Security o uwierzytelnianie użytkowników – oferuje znacznie wyższy poziom bezpieczeństwa niż sam MAC.
7. Adresy MAC sticky są zapisywane w konfiguracji bieżącej (running-config) – muszą być skopiowane do konfiguracji startowej (copy run start), aby przetrwały restart przełącznika.
8. Po restarcie przełącznika bez zapisanej konfiguracji sticky adresy zostaną utracone – atakujący może podłączyć nowe urządzenie przed przejęciem kontroli przez administratora.
9. Maksymalna liczba adresów MAC na porcie powinna odpowiadać rzeczywistej liczbie urządzeń – ustawienie wartości wyższej niż potrzeba osłabia bezpieczeństwo, ale zbyt niska wartość powoduje fałszywe alarmy.
10. Port Security nie chroni przed atakami na warstwie 3 (np. ARP spoofing, DHCP starvation) – wymaga dodatkowych mechanizmów seguridad takich jak Dynamic Arp Inspection, IP Source Guard i DHCP Snooping.

Wykład 10 Access Control Lists (ACL), IPv4 Filtering, Standard ACLs matching criteria.

Uczelniany serwer z ocenami (Grade Server) powinien być dostępny wyłącznie dla komputerów z podsieci Administracji. Niestety, obecnie każdy student może podjąć próbę logowania do panelu zarządzania tym serwerem. Musisz wdrożyć podstawowy mechanizm filtrowania ruchu przy użyciu standardowych list kontroli dostępu (ACL). Twoim zadaniem jest stworzenie reguły, która pozwoli na dostęp do segmentu serwerowego tylko z konkretnej podsieci źródłowej, a cały pozostały ruch odrzuci. Pamiętaj o zasadzie umieszczania standardowych list ACL jak najbliżej celu podróży pakietu.

• Stworzenie numerowanej standardowej listy ACL (zakres 1-99).
• Zdefiniowanie reguły pozwalającej na ruch z podsieci Administracji (np. 192.168.10.0/24).
• Zastosowanie maski blankietowej (wildcard mask) w definicji sieci.
• Zrozumienie i udokumentowanie działania niejawnej zasady 'deny any' na końcu listy.
• Przypisanie listy ACL do odpowiedniego interfejsu (SVI lub interfejs routera) w kierunku 'out'.
• Weryfikacja działania ACL przy użyciu ping z różnych podsieci (Administracja vs Studenci).
• Sprawdzenie liczników dopasowań (match counters) poleceniem show access-lists.
• Konfiguracja nazwanej standardowej listy ACL (Standard Named ACL) dla lepszej czytelności.
• Dodanie komentarza (remark) do listy ACL opisującego jej przeznaczenie.
• Udokumentowanie komunikatów o odrzuceniu pakietu (ICMP Destination Unreachable).
• Analiza kolejności przetwarzania wpisów w liście.
• Testowanie edycji listy ACL (usuwanie i dodawanie pojedynczych wpisów przy użyciu numerów sekwencyjnych).

1. Utwórz numerowaną standardową listę ACL poleceniem access-list [1-99] permit [sieć_źródłowa] [wildcard_mask].
2. Przykład: access-list 10 permit 192.168.10.0 0.0.0.255 zezwala na całą podsieć /24 (255.255.255.0 = wildcard 0.0.0.255).
3. Możesz użyć słowa kluczowego host zamiast mask, np. access-list 10 permit host 192.168.10.50 dla pojedynczego IP.
4. Ważne: Na końcu każdej listy ACL jest niejawna zasada "deny any" (niejawne odrzucenie wszystkiego niezgodnego z regułami).
5. Przypisz listę ACL do interfejsu w kierunku out (wyjście) poleceniem ip access-group [numer] out - standardowe ACL umieszczaj blisko celu.
6. Alternatywnie: przypisz w kierunku in poleceniem ip access-group [numer] in na interfejsie źródłowym.
7. Testuj działanie: ping z podsieci Administracji (dozwolonej) i ze podsieci Studentów (odmówione) - wyniki porównaj.
8. Sprawdź liczniki dopasowań poleceniem show access-lists [numer] - pokaże hits dla każdej reguły.
9. Utwórz nazwany standardową listę ACL: ip access-list standard [nazwa], np. ip access-list standard ADMIN_ACCESS.
10. Dodaj komentarz do listy ACL poleceniem access-list [numer] remark [komentarz], np. access-list 10 remark ## Zezwolenie dla ADMIN do serwerów ##.
11. Zaobserwuj komunikaty ICMP Destination Unreachable (typ 3, kod 13) przy odrzuceniu pakietu przez ACL.
12. Przeanalizuj kolejność przetwarzania: reguły są sprawdzane od góry do dołu, pierwsze dopasowanie wygrywa (first-match).
13. Testuj edycję: możesz usuwać pojedyncze wpisy używając numerów sekwencyjnych (np. no access-list 10 permit...).
14. Pamiętaj: Standardowe ACL filtrują TYLKO na podstawie źródłowego adresu IP - nie potrafią rozróżnić portów ani protokołów.
15. Umieść standardowe ACL jak najbliżej celu (destination) - jeśli umieścisz je blisko źródła, możesz przypadkowo zablokować dostęp do całej reszty sieci.
16. Jeśli lista zawiera same deny, żaden ruch nie przejdzie (pamiętaj o niejawnej "deny any" na końcu).

Na podstawie przeprowadzonych ćwiczeń laboratoryjnych należy opracować następujące wnioski:

1. Standardowe listy ACL należy umieszczać jak najbliżej celu (destination), ponieważ filtrują wyłącznie na podstawie adresu źródłowego – umieszczenie blisko źródła może przypadkowo zablokować dostęp do wielu sieci docelowych.
2. Implicit Deny (niejawne odrzucenie) na końcu każdej listy ACL jest fundamentalną zasadą bezpieczeństwa – jeśli żadna reguła nie pasuje, pakiet jest odrzucany, co domyślnie blokuje cały nieautoryzowany ruch.
3. Lista ACL z samymi wpisami "deny" spowoduje zablokowanie całego ruchu – każdy pakiet będzie pasował do reguły deny i zostanie odrzucony przez niejawną "deny any" na końcu listy.
4. Kolejność reguł ma kluczowe znaczenie – pierwsze dopasowanie wygrywa (first-match), więc reguły bardziej szczegółowe muszą być umieszczane przed regułami ogólnymi.
5. Wildcard mask w standardowych listach ACL odwraca bity maski – 0 oznacza "dopasuj", 1 oznacza "ignoreruj", np. 0.0.0.255 dla /24 pozwala na całą podsieć.
6. Słowo kluczowe "host" zastępuje maskę 0.0.0.0 – upraszcza składnię dla pojedynczych adresów IP.
7. Komentarze (remark) w listach ACL poprawiają czytelność dokumentacji – pozwalają zrozumieć cel każdej reguły bez analizy konfiguracji.
8. Liczniki dopasowań (match counters) pozwalają monitorować wykorzystanie reguł – reguły z zerowym licznikiem mogą być zbędne lub błędnie skonfigurowane.
9. Nazwane listy ACL (Standard Named ACL) są preferowane w nowoczesnych sieciach – łatwiej nimi zarządzać (można dodawać/usuwać reguły po numerach sekwencyjnych) niż numerowanymi.
10. ICMP Destination Unreachable (typ 3) jest wysyłany przez router przy odrzuceniu pakietu przez ACL – informuje nadawcę, że dostęp jest zabroniony, ale sam pakiet jest odrzucany.

Wykład 10 Extended ACLs, Protocol numbers, TCP/UDP port numbers, Layer 4 filtering.

Prosta blokada podsieci to za mało dla nowoczesnego kampusu. Musisz wdrożyć precyzyjną kontrolę aplikacji. Studenci powinni mieć możliwość przeglądania stron WWW (port 80 i 443) oraz wysyłania plików przez FTP, ale ich dostęp do serwerów infrastrukturalnych poprzez protokół SSH (port 22) czy Telnet musi zostać całkowicie zablokowany. Dodatkowo, serwery DNS w sieci muszą przyjmować zapytania tylko z autoryzowanych adresów. Twoim zadaniem jest stworzenie rozszerzonej listy ACL, która przeanalizuje porty warstwy czwartej (TCP/UDP) i dopuści tylko niezbędne usługi, zwiększając ogólny poziom bezpieczeństwa aplikacji sieciowych.

• Stworzenie nazwanej rozszerzonej listy ACL (np. ACL_STUDENT_RESTRICT).
• Zezwolenie podsieci studenckiej na ruch HTTP (tcp 80) i HTTPS (tcp 443) do dowolnego celu.
• Zezwolenie na zapytania DNS (udp 53) do konkretnego serwera DNS.
• Blokada ruchu SSH i Telnet z sieci studentów do wszystkich urządzeń Core/Distribution.
• Zezwolenie na ruch powrotny przy użyciu słowa kluczowego 'established' (symulacja firewalling-u).
• Przypisanie listy ACL jak najbliżej źródła ruchu (inbound interfejs dostępowy).
• Weryfikacja działania przy użyciu prób połączeń na różne porty (np. 'telnet 443' vs 'telnet 22').
• Użycie słowa kluczowego 'log' przy regułach blokujących w celu monitorowania prób włamań.
• Analiza błędu 'Administrative Prohibited' wysyłanego przez router.
• Konfiguracja reguły ICMP pozwalającej tylko na 'echo' i 'echo-reply'.
• Zastosowanie maski wszystkich jedynek (host) dla filtrowania pojedynczych urządzeń.
• Udokumentowanie dopasowań (hits) dla każdej reguły w liście.

1. Utwórz nazw rozszerzoną listę ACL poleceniem ip access-list extended [nazwa], np. ip access-list extended STUDENT_POLICIES.
2. Zezwól na ruch HTTP (port 80) z podsieci studenckiej: permit tcp 192.168.20.0 0.0.0.255 any eq 80.
3. Zezwól na ruch HTTPS (port 443): permit tcp 192.168.20.0 0.0.0.255 any eq 443.
4. Zezwól na zapytania DNS (UDP port 53): permit udp 192.168.20.0 0.0.0.255 host [IP_DNS_SERVER] eq 53.
5. Zablokuj SSH (port 22) z sieci studentów do infrastruktury: deny tcp 192.168.20.0 0.0.0.255 10.0.0.0 0.255.255.255 eq 22.
6. Dodaj słowo kluczowe log przy regułach blokujących, aby monitorować próby włamań: deny ... log.
7. Zezwól na ruch powrotny (established connections) dla TCP: permit tcp any any established - symuluje działanie firewallu.
8. Na końcu dodaj permit ip any any - aby zezwolić pozostały ruch (nie zapomnij o niejawnej "deny any").
9. Przypisz ACL do interfejsu źródłowego w kierunku in (jak najbliżej źródła): ip access-group STUDENT_POLICIES in.
10. Alternatywnie: przypisz na interfejsie VLAN w kierunku in na przełączniku lub routerze.
11. Testuj różne połączenia: Telnet na port 22 (blokowane), Telnet na port 80/443 (dozwolone), HTTP/HTTPS.
12. Użyj polecenia telnet [IP] [port] w GNS3 lub netcat do testowania łączności TCP na różne porty.
13. Sprawdź logi routera po próbach połączeń - powinny pokazywać "deny" z adresem IP i portem docelowym.
14. Skonfiguruj regułę ICMP pozwalającą tylko na echo (ping request) i echo-reply (ping reply), blokując pozostałe komunikaty.
15. Użyj słowa kluczowego host dla pojedynczego adresu IP lub any dla dowolnego adresu: np. permit ip any any.
16. Sprawdź liczniki dopasowań poleceniem show access-lists nazwa - pokaże hits dla każdej reguły.
17. Ważne: Rozszerzone ACL umieszczaj jak najbliżej źródła - router nie traci mocy na przesyłanie pakietów, które i tak zostaną odrzucone.
18. Kolejność reguł ma znaczenie: najpierw reguły szczegółowe (np. blokada SSH do serwerów), potem reguły ogólne (permit HTTP/HTTPS).

Na podstawie przeprowadzonych ćwiczeń laboratoryjnych należy opracować następujące wnioski:

1. Umieszczanie ACL na wejściu (inbound) interfejsu jest preferowane, ponieważ pakiety są odrzucane wcześniej, oszczędzając pasmo i zasoby routera – router nie траati ресурси на передачу pakietów, które będą odrzucone.
2. Umieszczanie ACL na wyjściu (outbound) interfejsu powoduje, że pakiety są najpierw przesyłane przez routera, a dopiero potem filtrowane – generuje to niepotrzebne obciążenie sieci i procesora.
3. Filtrowanie w warstwie 4 (TCP/UDP) jest skuteczniejsze niż proste blokowanie adresów IP, ponieważ pozwala na kontrolę konkretnych usług (portów), a nie tylko źródłowych lub docelowych adresów.
4. Słowo kluczowe "established" w regule TCP pozwala na ruch powrotny dla ustanowionych połączeń – pakiety z ustawionym bitem ACK przechodzą, co symuluje działanie stanowego firewalla.
5. Słowo kluczowe "log" przy regułach blokujących generuje komunikaty Syslog przy każdym dopasowaniu – umożliwia monitorowanie prób ataku i jest nieocenione przy rozwiązywaniu problemów z bezpieczeństwem.
6. Analiza błędu "Administrative Prohibited" (ICMP typ 3, kod 13) wskazuje, że pakiet został odrzucony przez listę ACL – pomaga zidentyfikować źródło problemów z łącznością.
7. Kolejność reguł ma kluczowe znaczenie w rozszerzonych ACL – reguły szczegółowe (np. blokada SSH do infrastruktury) muszą być umieszczane przed regułami ogólnymi (np. permit HTTP).
8. Reguła ICMP pozwala na echo (ping request) i echo-reply (ping reply), ale blokuje pozostałe komunikaty ICMP – umożliwia diagnozowanie łączności bez narażania sieci na ataki ICMP-based.
9. Użycie "any" dla adresu docelowego lub źródłowego upraszcza konfigurację, ale może prowadzić do zbyt szerokiego filtrowania – należy unikać zbyt ogólnych reguł.
10. Rozszerzone ACL umieszczane blisko źródła oszczędzają zasoby – router nie traci mocy na przesyłanie pakietów, które i tak zostaną odrzucone w pobliżu źródła.

Wykład 10 Network Management, SNMP (v2c vs v3), Syslog messages, Severity levels.

Zarządzanie siecią kampusową bez centralnego monitoringu to proszenie się o kłopoty – administratorzy dowiadują się o awariach dopiero z telefonów od zdenerwowanych pracowników. Musisz wdrożyć nowoczesny system monitorowania (NMS) oparty na protokole SNMP. Twoim zadaniem jest skonfigurowanie routerów i przełączników tak, aby bezpiecznie przesyłały informacje o swoim stanie (obciążenie CPU, status portów) do centralnego serwera. Dodatkowo, wszystkie komunikaty diagnostyczne (logi) muszą być automatycznie wysyłane do serwera Syslog, co pozwoli na późniejszą analizę przyczyn awarii i prób włamań. Postaw na bezpieczeństwo – użyj SNMPv3 z szyfrowaniem i uwierzytelnianiem.

• Konfiguracja serwera Syslog (może to być maszyna Linux z rsyslog lub dedykowany soft).
• Włączenie wysyłania logów na routerze poleceniem 'logging '.
• Ustawienie poziomu logowania na 'informational' (level 6) lub 'debugging' (level 7).
• Konfiguracja synchronicznego wyświetlania logów (logging synchronous) na konsoli.
• Konfiguracja SNMPv3: zdefiniowanie widoku (view), grupy (group) i użytkownika (user).
• Zastosowanie algorytmu uwierzytelniania (SHA) oraz szyfrowania (AES/DES).
• Włączenie wysyłania powiadomień SNMP traps do menedżera.
• Testowanie odczytu parametrów (np. hostname, uptime) z poziomu serwera NMS.
• Symulacja zdarzenia (np. shutdown interfejsu) i weryfikacja pojawienia się wpisu na serwerze Syslog.
• Konfiguracja poprawnego czasu systemowego poprzez NTP (kluczowe dla znacznika czasu w logach).
• Zabezpieczenie dostępu SNMP przy użyciu listy ACL (tylko IP serwera NMS).
• Interpretacja poziomów powagi logów (Emergency do Debugging).

1. Skonfiguruj serwer Syslog: możesz użyć maszyny z Linux (rsyslogd), Windows (np. SyslogWatch, Kiwi Syslog), lub kontenera Docker.
2. Skonfiguruj router/przełącznik do wysyłania logów: logging host [adres_IP_serwera], np. logging host 192.168.100.254.
3. Ustaw poziom logowania poleceniem logging trap [poziom] - levels: 0=Emergency, 1=Alert, 2=Critical, 3=Error, 4=Warning, 5=Notice (domyślny), 6=Informational, 7=Debugging.
4. Włącz logowanie synchroniczne na konsoli poleceniem logging synchronous - logi nie przerywają wpisywania poleceń.
5. Skonfiguruj SNMPv3: najpierw utwórz widok poleceniem snmp-server view [nazwa] [OID] included, np. snmp-server view READ iso included.
6. Utwórz grupę SNMPv3 poleceniem snmp-server group [nazwa_grupy] v3 [priv|auth|noauth].
7. Zalecane: użyj "priv" dla pełnego bezpieczeństwa (SHA uwierzytelnianie + AES szyfrowanie).
8. Utwórz użytkownika SNMP poleceniem snmp-server user [nazwa_użytkownika] [nazwa_grupy] v3 auth sha [hasło] priv aes 128 [klucz_szyfrujący].
9. Przykład: snmp-server user ADMIN ADMIN v3 auth sha MyPass123 priv aes 128 MyPriv456.
10. Włącz wysyłanie pułapek (traps) poleceniem snmp-server enable traps i skonfiguruj hosta traps poleceniem snmp-server host [IP] version 3 priv [użytkownik].
11. Przetestuj odczyt: użyj snmpwalk lub SNMP tools z serwera NMS do odczytu parametrów (hostname, uptime, CPU, interfejsy).
12. Zasymuluj zdarzenie: wykonaj shutdown na interfejsie i sprawdź wpis na serwerze Syslog (powinien pojawić się komunikat %LINKS-5...).
13. Skonfiguruj NTP do synchronizacji czasu: ntp server [adres_IP] - kluczowe dla korelacji zdarzeń w logach z wielu urządzeń.
14. Zabezpiecz dostęp SNMP listą ACL: najpierw utwórz ACL, np. access-list 99 permit host [IP_NMS], następnie snmp-server community [community] 99.
15. Interpretuj poziomy powagi: Emergency (0) - najkrytyczniejsze, Debugging (7) - najmniej krytyczne, używane do diagnozowania.
16. Uwaga: SNMP v1/v2c przesyła hasło (community string) otwartym tekstem - w środowisku akademickim każdy ze Wiresharkiem je przejmie. ZAWSZE używaj SNMPv3 (authPriv).
17. Uwaga: Bez synchronizacji NTP logi z różnych urządzeń będą bezużyteczne przy analizie korelacji zdarzeń (data bez sensu).

Na podstawie przeprowadzonych ćwiczeń laboratoryjnych należy opracować następujące wnioski:

1. Polling (zapytanie) to model, w którym serwer NMS regularnie odpytuje urządzenia o ich stan – wymaga konfiguracji na urządzeniach i generuje ruch sieciowy, ale zapewnia prewencyjny monitoring stanu.
2. Trap (pułapka) to model, w którym urządzenie aktywnie powiadamia serwer NMS o zdarzeniu – generuje mniej ruchu, ale wymaga, aby urządzenie wiedziało o adresie serwera i było skonfigurowane do wysyłania pułapek.
3. Centralizacja logów Syslog jest kluczowa dla bezpieczeństwa IT, ponieważ logi z wielu urządzeń w jednym miejscu umożliwiają korelację zdarzeń i wykrywanie skoordynowanych ataków – pojedyncze logi na urządzeniach są łatwe do manipulacji przez atakujących.
4. SNMPv3 oferuje znaczące zalety nad v2c – zapewnia uwierzytelnianie (SHA/MD5), szyfrowanie (AES/DES) iintegralność wiadomości, co chroni przed podsłuchiwaniem i manipulacją danymi monitoringu.
5. SNMPv1/v2c przesyła hasło (community string) otwart tekstem – w środowisku akademickim każdy z Wireshark może je przejąć, co stanowi poważne zagrożenie bezpieczeństwa, dlatego ZAWSZE należy używać SNMPv3.
6. Poziomy logów: Emergency (0) – najkrytyczniejsze, system nie działa; Alert (1) – wymagana natychmiastowa akcja; Critical (2) – krytyczne warunki; Error (3) – błędy; Warning (4) – ostrzeżenia; Notice (5) – normalne, ale znaczące zdarzenia; Informational (6) – informacje; Debugging (7) – debugowanie.
7. Synchronizacja czasu przez NTP jest kluczowa dla korelacji zdarzeń – logi z różnych urządzeń bez wspólnego czasu są bezużyteczne przy próbie odtworzenia sekwencji zdarzeń prowadzących do awarii.
8. Zabezpieczenie dostępu SNMP listą ACL (access-list) jest najlepszą praktyką – tylko autoryzowany serwer NMS może odpytać urządzenia, co eliminuje nieautoryzowany dostęp do informacji o stanie sieci.
9. Wykorzystanie widoku (view) w SNMPv3 pozwala na ograniczenie dostępu do określonych OID – można zdefiniować widok tylko do odczytu i oddzielny do zapisu.
10. Konfiguracja hosta traps (snmp-server host) jest niezbędna do aktywnego powiadamiania – bez niej pułapki nie będą wysyłane, nawet jeśli skonfigurowano "enable traps".

Wykład 1 Rodzaje sieci, WiFi implementation, WLC (Wireless LAN Controller), Lightweight APs.

Nowoczesny kampus nie może istnieć bez WiFi. Musisz zaprojektować system bezprzewodowy oparty na architekturze scentralizowanej. Zamiast konfigurować każdy punkt dostępowy z osobna, użyjesz kontrolera WLC (Wireless LAN Controller) oraz lekkich punktów dostępowych (LWAPP/CAPWAP). Twoim zadaniem jest stworzenie dwóch sieci bezprzewodowych (SSID): "AHE-STUDENT" z uwierzytelnianiem WPA2-PSK (lub 802.1X) oraz "AHE-GUEST" z otwartym dostępem lub portalem przechwytującym. Musisz zapewnić, by ruch z różnych SSID był mapowany do odpowiednich VLANów w sieci przewodowej, gwarantując separację ruchu gości od zasobów uniwersyteckich.

• Konfiguracja interfejsu zarządzającego na kontrolerze WLC.
• Stworzenie dwóch sieci WLAN (SSID) o nazwach AHE-STUDENT i AHE-GUEST.
• Konfiguracja zabezpieczeń WPA2-Personal (AES) dla sieci studenckiej.
• Mapowanie SSID do odpowiednich interfejsów VLAN na kontrolerze.
• Zapewnienie komunikacji L3 między punktami AP a kontrolerem (tunel CAPWAP).
• Konfiguracja portu przełącznika, do którego wpięty jest AP, jako trunk lub access (zależnie od trybu AP).
• Sprawdzenie statusu rejestracji punktów dostępowych na kontrolerze.
• Testowanie roamingu – przemieszczanie się hosta między dwoma punktami AP.
• Konfiguracja DHCP dla klientów bezprzewodowych (pula na WLC lub zewnętrznym serwerze).
• Weryfikacja parametrów sygnału (RSSI) i prędkości połączenia na kliencie.
• Ograniczenie pasma (Bandwidth limiting) dla sieci gościnnej.
• Udokumentowanie listy podłączonych klientów bezprzewodowych.

1. Skonfiguruj interfejs zarządzający (Management Interface) na kontrolerze WLC - przypisz adres IP, maskę, bramę domyślną.
2. W interfejsie webowym WLC lub CLI utwórz sieć WLAN poleceniem config wlan create [WLAN_ID] [nazwa_profilu] [SSID], np. config wlan create 1 STUDENT ahe-student.
3. Utwórz drugą sieć WLAN dla gości: config wlan create 2 GUEST ahe-guest.
4. Wyłącz WLAN podczas konfiguracji poleceniem config wlan disable [WLAN_ID] - konfiguruj gdy wyłączone.
5. Skonfiguruj zabezpieczenia WPA2-PSK dla sieci studenckiej: w config wlan security wpa2 [WLAN_ID] enable, następnie config wlan security wpa2 psk enable [WLAN_ID], i config wlan security wpa2 psk set-key ascii [hasło] [WLAN_ID].
6. Mapuj SSID do interfejsu VLAN: config wlan interface [WLAN_ID] [nazwa_interfejsu], np. config wlan interface 1 management-vlan.
7. Włącz WLAN poleceniem config wlan enable [WLAN_ID].
8. Upewnij się, że AP mogą komunikować się z kontrolerem (L3) - tunel CAPWAP wymaga łączności IP (UDP ports 5246/5247).
9. Skonfiguruj port przełącznika, do którego wpięty jest punkt AP: tryb trunk (jeśli wiele VLANów WiFi) lub access z odpowiednim VLANem.
10. Upewnij się, że AP otrzymuje adres IP z DHCP (opcja 43 może wskazywać adres kontrolera, jeśli automatyczne wykrywanie nie działa).
11. Sprawdź status punktów dostępowych poleceniem show ap summary - powinny widnieć jako Joined/Register.
12. Testuj roamingu: przemieszczaj klienta między dwoma punktami AP - połączenie powinno przełączyć się bez utraty pakietów.
13. Skonfiguruj DHCP dla klientów WiFi: pula na WLC (ip dhcp pool) lub na zewnętrznym serwerze, przypisz interfejs VLAN dla WiFi.
14. Zweryfikuj parametry połączenia na kliencie: siła sygnału (RSSI powyżej -70dBm), prędkość (np. 72 Mbps dla 802.11n na 20MHz).
15. Opcjonalnie: skonfiguruj pasmo dla gości (bandwidth select) ograniczając prędkość np. do 1 Mbps.
16. Wyświetl listę klientów bezprzewodowych poleceniem show wlan summary lub show client summary.
17. Pamiętaj: W architekturze WLC-AP, cała inteligencja i polityki są na kontrolerze - AP to tylko radiowe przedłużenia.
18. Uwaga: Polecenia WLC różnią się w zależności od wersji oprogramowania - sprawdź czy używasz AireOS klasyczny czy Catalyst 9800 (IOS XE).

Na podstawie przeprowadzonych ćwiczeń laboratoryjnych należy opracować następujące wnioski:

1. Architektura z kontrolerem (Controller-based) jest lepsza dla kampusu niż autonomiczne punkty dostępowe (Standalone AP), ponieważ wszystkie polityki bezpieczeństwa, zarządzanie ruchem i konfiguracja są scentralizowane na kontrolerze.
2. Tunel CAPWAP (Control And Provisioning of Wireless Access Points) przenosi ruch kontrolny (UDP 5246) i danych (UDP 5247) między kontrolerem a punktami AP – umożliwia zarządzanie AP przez sieć IP i eliminuje potrzebę lokalnej konfiguracji AP.
3. W architekturze WLC-AP, punkty dostępowe są "lekkie" – pełnią tylko funkcję radiowe, a cała inteligencja (uwierzytelnianie, QoS, polityki bezpieczeństwa) jest na kontrolerze.
4. Ponieważ kontroler zarządza wszystkimi punktami AP, tworzenie wielu SSID jest proste – każdy SSID może być mapowany do innego VLANu w sieci przewodowej.
5. Roaming między punktami AP jest płynny w architekturze z kontrolerem, ponieważ kontroler zarządza przekazaniem sesji – klient nie traci połączenia przy przejściu między strefami pokrycia.
6. Planowanie rozmieszczenia AP w budynkach o grubych ścianach jest wyzwaniem – grube ściany (beton, metal) tłumią sygnał, wymagając gęstszego rozmieszczenia punktów dostępowych.
7. Opcja 43 w DHCP może wskazywać adres kontrolera WLC – punkty AP używają jej do automatycznego wykrywania kontrolera, jeśli funkcja Discovery nie działa w sieci.
8. DHCP dla klientów bezprzewodowych może być realizowane przez kontroler WLC lub zewnętrzny serwer – w obu przypadkach interfejs VLAN musi być poprawnie skonfigurowany.
9. Ograniczenie pasma (bandwidth limiting) dla sieci gościnnych jest najlepszą praktyką – zapobiega nadmiernemu obciążeniu sieci przez gości i zapewnia sprawiedliwy przydział zasobów.
10. WPA2-PSK (Pre-Shared Key) jest odpowiedni dla małych wdrożeń, ale w środowisku akademickim zaleca się WPA2-Enterprise z uwierzytelnianiem 802.1X – każdy użytkownik ma osobne poświadczenia.

Wykład 1-10 Synteza całej wiedzy z przedmiotu.

To jest Twój egzamin końcowy. Otrzymujesz rzut architektoniczny trzykondygnacyjnego budynku nowej filii uczelni. Musisz zaprojektować i zaimplementować od zera kompletną infrastrukturę sieciową, która połączy w sobie wszystkie poznane dotąd technologie. Projekt musi zawierać redundancję w warstwie rdzenia, segmentację logiczną (VLAN), dynamiczny routing (OSPF), systemy bezpieczeństwa (ACL, Port Security), mobilność (WiFi) oraz pełny monitoring. Twoim zadaniem jest nie tylko "podpięcie kabli", ale przede wszystkim poprawne zwymiarowanie łączy, dobranie odpowiednich urządzeń i rzetelne uzasadnienie każdego wyboru projektowego w obszernym sprawozdaniu końcowym.

• Kompletny schemat fizyczny i logiczny w GNS3/EVE-NG (minimum 10 urządzeń aktywnych).
• Implementacja modelu hierarchicznego (Core-Dist-Access) z pełną redundancją.
• Konfiguracja EtherChannel (LACP) na wszystkich łączach dosyłowych.
• Wdrożenie RSTP z optymalizacją Root Bridge dla różnych grup VLANów.
• Segmentacja: VLAN Administracja, Studenci, Serwery, WiFi, Management.
• Routing: OSPF Multi-Area jako główny protokół IGP.
• Routing statyczny dla wyjścia do Internetu (Primary/Backup).
• Pełna adresacja Dual-Stack (IPv4 i IPv6) realizowana przez DHCP.
• Bezpieczeństwo: Port Security na portach dostępowych i restrykcyjne ACL na routerach.
• Wdrożenie WiFi z centralnym zarządzaniem SSID.
• Konfiguracja monitoringu SNMP i Syslog dla wszystkich węzłów sieci.
• Testy obciążeniowe i weryfikacja scenariuszy awaryjnych (failover).

1. ZAPLANUJ projekt przed implementacją: narysuj schemat fizyczny i logiczny na papierze lub w edytorze graficznym.
2. Określ liczbę urządzeń: minimum 10 urządzeń aktywnych (2×Core L3, 2×Distribution, 3×Access, 1×Router-BRANCH, 1×Server, 1×WLC/AP).
3. Opracuj plan adresacji IPv4 i IPv6 dla wszystkich podsieci: ADMIN (10.1.10.0/24), STUDENTS (10.1.20.0/24), SERVERS (10.1.30.0/24), WIFI (10.1.40.0/24), MGMT (10.1.99.0/24), UPLINKS (point-to-point /30).
4. Zaimplementuj warstwę fizyczną: podłącz wszystkie kable zgodnie ze schematem wtytek "full-mesh" Core-Distribution.
5. Skonfiguruj hostname i hasła na wszystkich urządzeniach: enable secret, banner motd, line vty z ACL.
6. Skonfiguruj VLANy: 10 (ADMIN), 20 (STUDENTS), 30 (SERVERS), 40 (WIFI), 99 (MGMT) na wszystkich przełącznikach.
7. Skonfiguruj EtherChannel (LACP) na wszystkich łączach Core-Distribution i Distribution-Access: channel-group 1 mode active na obu końcach.
8. Skonfiguruj RSTP: spanning-tree mode rapid-pvst, Root Bridge na Distribution (primary/secondary), PortFast na portach Access.
9. Skonfiguruj Inter-VLAN Routing: SVI na przełącznikach Distribution L3 (ip routing, interface Vlan X z adresami IP).
10. Skonfiguruj OSPF Multi-Area: Area 0 dlaCore/Distribution, Area 1 dla Access floors, ABR na Distribution - network z wildcard mask.
11. Skonfiguruj routing statyczny: trasa domyślna do ISP (Main), floating route z AD=200 do Backup ISP.
12. Skonfiguruj DHCP: pule dla ADMIN, STUDENTS, WIFI na centralnym routerze, ip helper-address na SVI.
13. Skonfiguruj IPv6 GUA i SLAAC na interfejsach: ipv6 unicast-routing, ipv6 address 2001:db8:X::1/64.
14. Skonfiguruj Port Security na portach Access: switchport port-security maximum 1, mac-address sticky, violation shutdown.
15. Skonfiguruj ACL: standardowe na routerze dla serwerów (tylko ADMIN), rozszerzone dla studentów (blokada SSH, permit HTTP/HTTPS/DNS).
16. Skonfiguruj WiFi: WLC z dwoma SSID (AHE-STUDENT WPA2-PSK, AHE-GUEST otwarty), mapowanie do VLANów.
17. Skonfiguruj monitoring: SNMPv3 z użytkownikiem, logging do serwera Syslog, NTP dla synchronizacji czasu.
18. Wykonaj testy obciążeniowe: uruchom iperf/ping-test między VLANami, sprawdź przepustowość EtherChannel.
19. Przetestuj scenariusze awaryjne: odłącz kable Core-Distribution, wyłącz Core router - sprawdź failover.
20. Zweryfikuj zbieżność po resecie: wyłącz/włącz główny router Core - mierz czas zbieżności OSPF/RSTP.
21. Wykonaj dokumentację: zrzuty ekranu wszystkich konfiguracji, show ip route, show spanning-tree, show vlan brief.
22. Pamiętaj: Implementuj warstwami - najpierw fizyczne połączenia, potem VLANy i STP, następnie EtherChannel, routing i bezpieczeństwo na końcu.
23. Monitoring włącz na bieżąco - pomoże wykryć błędy w trakcie budowy, nie zostawiaj na koniec.

Na podstawie przeprowadzonych ćwiczeń laboratoryjnych należy opracować następujące wnioski:

1. Integracja wielu technologii (VLAN, STP, EtherChannel, OSPF, ACL, Port Security, WiFi, monitoring) jest największym wyzwaniem projektu zintegrowanego – wymaga zrozumienia wzajemnych zależności między protokołami.
2. Model hierarchiczny jest uzasadniony w kontekście długofalowych kosztów utrzymania (TCO) sieci kampusowej, ponieważ umożliwia niezależną modernizację warstw bez przebudowy całej infrastruktury.
3. Całkowita zbieżność domeny po gruntownym resecie głównego routera Core zależy od czasu zbieżności wszystkich protokołów – OSPF (~30 sekund), RSTP (~5 sekund), ARP (~60 sekund) – łączny czas może przekroczyć 2 minuty.
4. Redundancja w warstwie Core (podwójne routery) jest wymagana dla zapewnienia ciągłości działania – pojedynczy punkt awarii (Single Point of Failure) jest nieakceptowalny w środowisku produkcyjnym.
5. EtherChannel i RSTP muszą być skonfigurowane razem – EtherChannel jest widziany przez STP jako pojedyncze łącze, co eliminuje pętle, ale wymaga poprawnej konfiguracji obu protokołów.
6. ACL i Port Security muszą być skoordynowane – zbyt restrykcyjne ACL mogą blokować ruch dozwolony przez Port Security i odwrotnie.
7. Monitoring powinien być konfigurowany na bieżąco, nie na końcu – pozwala wykrywać błędy w trakcie budowy sieci i skraca czas rozwiązywania problemów.
8. Dokumentacja konfiguracji (show ip route, show spanning-tree, show vlan brief, show etherchannel summary) jest niezbędna dla przyszłego rozwiązywania problemów i audytu bezpieczeństwa.
9. Testy obciążeniowe (iperf, ping-test) weryfikują, czy sieć przenosi przewidywane obciążenie – sieć zaprojektowana teoretycznie może nie działać pod obciążeniem.
10. Scenariusze awaryjne (failover test) potwierdzają, że redundancja działa – symulacja awarii jest jedynym sposobem weryfikacji, czy system przetrwa rzeczywistą awarię.