Fizyczny sprzęt czy symulator sieci: kiedy co wystarczy?

Do egzaminu wystarczy symulator sieci, do pracy potrzebny jest prawdziwy sprzęt — taką odpowiedź znajdziesz na każdym forum i trudno się z nią kłócić. Problem w tym, że niewiele z niej wynika: nie mówi, czego w symulatorze nie przećwiczysz wcale, a gdzie zobaczysz zachowanie odbiegające od tego, co robi prawdziwe urządzenie. Pomija też rzecz najważniejszą: certyfikat zdobyty „na symulatorze” przeprowadzi Cię przez sito rekrutacji, ale czy przygotuje Cię na pierwszy dzień w serwerowni? Dlatego zamiast ogólników przechodzę przez program CCNA temat po temacie i pokazuję konkretnie, gdzie symulator wystarczy, a gdzie potrzebny jest fizyczny sprzęt.

Co symulator sieci robi naprawdę dobrze

Zacznijmy uczciwie: symulatory to dziś rozbudowane narzędzia i nie ma sensu ich bagatelizować.

Packet Tracer jest darmowy — do pobrania wystarczy założyć konto w NetAcad, a ćwiczenia w nim są integralną częścią materiałów CCNA. Topologię budujesz w kilka minut i równie szybko przeskakujesz między kilkoma otwartymi naraz. Nic przy tym nie szumi, nie grzeje się i nie pobiera prądu. Jest jednak symulatorem, więc zachowanie urządzeń jest w nim zaprogramowane. Gdy coś nie działa, przyczyną może być błąd w Twojej konfiguracji albo niedokładnie odwzorowane zachowanie urządzenia. Trzeba uczciwie przyznać: to drugie zdarza się rzadko (częściej danej funkcji po prostu nie ma), ale Ty, ucząc się od zera, bez kontaktu z fizycznym sprzętem, nie masz jak rozstrzygnąć, po której stronie leży problem.

CML (Cisco Modeling Labs) to emulator: urządzenia nie są tu uproszczonymi modelami, lecz uruchamiają prawdziwe oprogramowanie urządzeń sieciowych Cisco. Może ono działać jako proces w Linuksie (IOL, czyli IOS on Linux — najlżejszy i najczęściej używany typ węzła) albo jako maszyna wirtualna z IOS-XE. Polecenie wpisane w CML zachowuje się tak samo jak na fizycznym urządzeniu, a parser daje dostęp do pełnego zestawu komend. Dzięki temu przetestujesz w nim konfigurację, którą planujesz wdrożyć na produkcji. Cisco udostępnia bezpłatną wersję CML-Free, z ograniczeniem liczby urządzeń uruchomionych jednocześnie w topologii.

Program CCNA temat po temacie: co działa, a co nie

Poniższa tabela przechodzi przez sześć domen egzaminu CCNA 200-301 i przy każdym temacie odpowiada na pytanie, czy Packet Tracer wystarczy. Trzy możliwe oceny:

• TAK — przećwiczysz to samo, co na fizycznym sprzęcie,
• OGRANICZONE — skonfigurujesz, ale nie zobaczysz części tego, co może Cię później zaskoczyć w pracy na fizycznym sprzęcie,
• NIE — tematu nie przerobisz albo zobaczysz zachowanie mocno odbiegające od rzeczywistego.

Uwagi do tabeli:

1. Opisuje Packet Tracer 9.0.x — kolejne wersje mogą nadrobić część braków.
2. Dotyczy wyłącznie zakresu materiału CCNA. Na poziomie CCNP i wyżej braki są nieporównanie większe: routing między VLAN-ami przy CCNA to TAK, ale ten sam temat przy CCNP — już NIE.
3. Wskazuje tylko główne ograniczenia — w rzeczywistości jest ich zwykle więcej.
4. Nie powtarza przy prawie każdym temacie braku Wiresharka, choć dotyczy on niemal każdego wiersza. To sprawa na tyle ważna, że poświęcam jej osobną sekcję.

Wiersze z oceną „TAK” nie wymagają komentarza. Pozostałe mają wspólny mianownik: symulator to świat zamknięty. Nie ma w nim internetu, prawdziwych systemów operacyjnych, prawdziwego ruchu ani prawdziwego czasu. I właśnie to zamknięcie ukrywa przed uczącym się całą klasę zjawisk, które w realnej sieci są codziennością.

Wireshark: najpoważniejszy brak symulatora

Packet Tracer ma tryb symulacji, w którym obejrzysz wędrówkę pakietu przez topologię i zajrzysz w jego nagłówki. Jako narzędzie dydaktyczne sprawdza się bardzo dobrze. Ale to nie jest Wireshark. Prawdziwy analizator podpięty do prawdziwego interfejsu pokazuje wszystko, także ruch tła, którego jest mnóstwo. Wyłowienie z tego natłoku tych kilku pakietów, które akurat mają znaczenie, jest osobną umiejętnością i ćwiczy się ją wyłącznie na prawdziwym ruchu.

Kilka sekund realnego ruchu: ARP, UDP, TCP i ICMP naraz. Takiego tła symulator nie wygeneruje.

Wireshark towarzyszy praktycznie całemu materiałowi CCNA. Przy TCP pokazuje numery sekwencyjne i potwierdzenia w prawdziwym ruchu, przy IPv4 i IPv6 budowę nagłówka, przy STP, CDP i LLDP enkapsulację ramek, przy OSPF zawartość pakietu Hello, przy DHCP kolejne komunikaty procedury DORA razem z adresacją i numerami portów, a w wersji dla IPv6 analogiczną wymianę, tyle że z innymi nazwami komunikatów i innymi portami. Podczas przełączania ramek odpowiada na pytanie, dokąd ramka faktycznie trafiła, a dokąd nie. Przy NAT pokazuje podmianę adresów i numerów portów.

Druga rola tego narzędzia to weryfikacja. Zanim napiszesz regułę ACL, sprawdzasz nim, jak wygląda pakiet, który chcesz dopasować; po wdrożeniu reguły sprawdzasz, czy odrzucany ruch rzeczywiście nie dochodzi tam, gdzie nie powinien. Sesja SSH jest w podglądzie nieczytelna, a SNMP w wersji 2c i syslog przeciwnie: przesyłane są otwartym tekstem, razem z community string. W tunelu IPsec zobaczysz nagłówek ESP (Encapsulating Security Payload) i nic poza nim, co jest najlepszym dowodem, że szyfrowanie faktycznie działa. W symulatorze wszystkie te rzeczy musisz przyjąć na wiarę.

To tylko wybrane przykłady, bo w praktyce Wireshark wraca przy niemal każdym temacie ćwiczonym na sprzęcie. Na naszych szkoleniach stawiamy przede wszystkim na praktykę, a sprawne posługiwanie się Wiresharkiem traktujemy jako jedną z podstawowych umiejętności inżyniera sieci, nie jako dodatek do materiału.

NAT, NTP i DNS bez dostępu do internetu

Zamknięcie symulatora najlepiej widać na NAT (Network Address Translation). W Packet Tracerze translację testujesz pingiem albo otwarciem jednej strony w symulowanej przeglądarce: w tablicy translacji przybywa kilka wpisów, każdy czytelny i łatwy do prześledzenia. Tyle że NAT w produkcji nie obsługuje trzech wpisów, lecz tysiące, i dopiero przy takiej skali widać, czym naprawdę jest PAT (Port Address Translation): jak szybko rośnie tablica translacji, dlaczego pula portów potrafi się wyczerpać i co psują źle dobrane timeouty.

NTP (Network Time Protocol) w Packet Tracerze „po prostu ustawia czas”. Na sprzęcie podłączonym do internetu synchronizujesz się z prawdziwymi serwerami i oglądasz to, o czym mówi teoria: stratum, offset, jitter. Możesz wskazać kilka źródeł czasu i zobaczyć, które z nich jest stabilniejsze i dlaczego router akurat je wybrał.

DNS w Packet Tracerze sprowadza się do statycznej tablicy nazw: rekordy wpisujesz ręcznie na symulowanym serwerze, bez TTL (Time To Live), bez cache’owania, bez zachowań prawdziwego resolvera. Na prawdziwym kliencie zobaczysz, jak system buforuje odpowiedzi (ipconfig /displaydns) i kiedy je odświeża.

Nawet tak podstawowe narzędzie jak traceroute wygląda w Packet Tracerze zupełnie inaczej niż w prawdziwej sieci. W symulatorze dostaniesz trzy skoki o niemal identycznych czasach. W prawdziwym internecie zobaczysz różne czasy odpowiedzi, węzły, które nie odpowiadają wcale albo pozostają niewidoczne.

Symulator stara się jedynie imitować działanie tracert.

Host w Packet Tracerze tylko udaje komputer

Host w Packet Tracerze wygląda jak komputer, ma m.in. pulpit i wiersz poleceń, ale jego zachowanie ma niewiele wspólnego z prawdziwym systemem operacyjnym.

Najjaskrawszy przykład to IPv6. Prawdziwy Windows potrafi mieć na jednym interfejsie kilka adresów IPv6: link-local, adres ze SLAAC (Stateless Address Autoconfiguration), adres tymczasowy (tzw. privacy extensions), adres z DHCPv6 i adres ustawiony statycznie — wszystkie mogą być jednocześnie używane. Reaguje przy tym na flagi M, O i A w komunikatach ICMPv6 RA (Router Advertisement), które mówią mu, skąd brać konfigurację. Host w Packet Tracerze ma jeden adres globalny i link-local, adresów tymczasowych nie zna, flagami się nie przejmuje, a narzędzia netsh nie ma wcale. Ucząc się IPv6 wyłącznie na symulatorze, uczysz się zachowania klienta, które w rzeczywistości nie występuje.

U góry jeden adres IPv6 w Packet Tracerze, na dole prawdziwy Windows: statyczny, DHCPv6, SLAAC, tymczasowy i link-local jednocześnie.

Podobnie z podstawową diagnostyką hosta. ipconfig /all w Packet Tracerze nie pokaże Ci, kiedy dzierżawa DHCP została przydzielona i kiedy wygasa. Tablica routingu z netstat -r ma metrykę 1 dla wszystkich tras i nie zawiera wpisów, które na prawdziwym Windowsie zajmują pół ekranu: tras multicastowych, loopbacka, tras „on-link”.

Narzędzia, których do symulatora nie podłączysz

Do Packet Tracera nie podłączysz żadnych zewnętrznych narzędzi. Nie połączysz się z urządzeniem przez SSH, czy to programem PuTTY, czy skryptem w Pythonie. Nie odczytasz ani nie zmienisz konfiguracji przez REST API, czy to z Postmana, czy choćby ze zwykłej przeglądarki. Dlatego język modelowania danych YANG oraz formaty XML, JSON i YAML pozostaną dla Ciebie suchą teorią. Dostęp po SNMP (Simple Network Management Protocol) i wysyłanie logów przez syslog wprawdzie skonfigurujesz na urządzeniu, ale nie połączysz się z nim z zewnętrznego systemu zarządzania (NMS, Network Management System), a logi trafią tylko do wewnętrznego, symulowanego serwera syslog. Żadnego z tych typów ruchu nie obejrzysz też w Wiresharku.

Port security, DHCP snooping i DAI (Dynamic ARP Inspection) skonfigurujesz w Packet Tracerze, ale nie przeprowadzisz ataków, którymi sprawdziłbyś, czy ta obrona działa — choćby popularnymi narzędziami z Kali Linux. Uczysz się obrony, nie widząc, jak wygląda atak. Na naszym szkoleniu pokazujemy obie strony: najpierw atak na żywo, potem mechanizm, który go zatrzymuje.

W Packet Tracerze wszystko działa idealnie — i to jest problem

W Packet Tracerze jeśli coś działa, działa idealnie. W rzeczywistej sieci tak nie jest. Pakiet szybko dociera do celu, ale jest długo przetwarzany lokalnie. Co któryś pakiet danej komunikacji doświadcza nadmiernego opóźnienia albo wręcz nie dociera do celu. Takich zjawisk w Packet Tracerze nie doświadczysz, a one realnie wpływają na mechanizmy, które konfigurujesz.

Skrajnym przypadkiem jest tutaj działanie mechanizmów QoS. Pakiet nie może nie zmieścić się w kolejce interfejsu fizycznego, bo nie ma interfejsu fizycznego i związanej z nim kolejki. Przeciążony CPU routera nie może nie nadążać z obsługą ruchu kontrolnego, bo nie ma CPU. Skoro nie ma zdarzeń czasu rzeczywistego, nie ma też czego analizować: lista dostępnych poleceń debug jest szczątkowa, a te, które działają, pokazują wyłącznie wyidealizowane sytuacje, jakich w praktyce prawie się nie spotyka.

CML: bliżej rzeczywistości, ale nie na start

CML znosi dużą część ograniczeń: urządzenia działają na prawdziwych obrazach i wystawiają API, połączysz się z nimi przez SSH klientem PuTTY lub napisanym skryptem, a wirtualną topologię połączysz z fizycznym sprzętem, w tym z internetem. Analogicznie działają emulatory GNS3 i EVE-NG, z jednym praktycznym zastrzeżeniem: obrazy systemów Cisco trzeba do nich legalnie skądś mieć, a Cisco nie sprzedaje ich osobno. W CML dostajesz je razem z narzędziem.

Niestety nie wszystko działa w CML (i analogicznych emulatorach) tak samo jak na urządzeniach fizycznych. Router realizuje większość zadań programowo, więc emulacja odtwarza go wiernie, uruchamiając po prostu ten sam kod. Operacje przełącznika w większości realizują dedykowane układy scalone (ASIC — Application-Specific Integrated Circuit), zaprojektowane do przełączania ramek z pełną prędkością łącza. Emulator takiego układu nie ma, więc jego zachowanie musi zamodelować programowo — czyli wraca dokładnie do tego, co robi symulator. Dlatego odwzorowanie działania przełączników w emulatorach jest dużo słabsze niż routerów. Dotyczy to również funkcjonalności z zakresu programu CCNA.

CML jest znakomity jako drugi krok, czyli wtedy, gdy znasz już podstawy i chcesz laboratorium wierniejszego niż Packet Tracer. Jako jedyne środowisko nauki od zera sprawdza się słabo.

Uczciwie trzeba też przyznać, że są tematy, które na emulatorze ćwiczy się równie dobrze jak na fizycznym sprzęcie, a bywa, że nawet lepiej. Dobrym przykładem są zaawansowane szkolenia z routingu: BGP, IS-IS, MPLS czy MPLS TE. Ich sedno to logika protokołów — dokładnie ten kod, który emulator uruchamia 1:1 — a do sensownych scenariuszy potrzeba topologii złożonej z kilkunastu routerów. Na emulatorze każdy uczestnik ma taką topologię do własnej dyspozycji i swobodnie przeskakuje między konsolami urządzeń; zestawienie tego samego na fizycznym sprzęcie, osobno dla każdego uczestnika, byłoby co najmniej uciążliwe. Zwróć jednak uwagę, kto siada do takich szkoleń: osoba, która podstawy ma dawno opanowane i nierzadko zawodowo pracuje na fizycznym sprzęcie. Na tym poziomie brak fizycznego laboratorium niczego jej nie odbiera. Na poziomie CCNA — odbiera wszystko.

Co z tego wynika dla Twojej nauki

Pracodawca nie zapyta Cię, jak się uczyłeś, ale sprawdzi, co umiesz, a w pierwszej kolejności będą go interesować twarde umiejętności praktyczne. Osobę, która uczyła się wyłącznie na symulatorze, pierwszy kontakt z urządzeniami w szafie rack może przytłoczyć, a brak „pewności ruchów przy fizycznym sprzęcie” będzie widoczny.

Praktyczny wniosek z całego artykułu jest więc taki, że to nie jest wybór „albo–albo”. Symulator i fizyczny sprzęt uzupełniają się, bo każdy jest dobry w czym innym:

• symulator — nauka konfiguracji i logiki protokołów, powtarzanie ćwiczeń we własnym tempie i poza czasem szkolenia, przygotowanie do pytań egzaminacyjnych;
• fizyczny sprzęt — praca z prawdziwymi narzędziami (Wireshark, PuTTY, klient SNMP, serwer syslog i inne), zachowanie protokołów w realnym czasie i pod realnym ruchem.

Dokładnie na tym podziale opieramy nasze szkolenie CCNA. Warsztaty podczas zajęć odbywają się na fizycznym sprzęcie sieciowym: routerach i przełącznikach Cisco stojących w sali szkoleniowej. Łączysz się zdalnie z komputerem, który jest fizycznie podłączony do urządzeń Ethernetem i kablem konsolowym, więc masz pełne doświadczenie fizycznego laboratorium bez wychodzenia z domu. Packet Tracer i CML zostają na pracę własną po zajęciach — do powtórek są znakomite i to jest dokładnie ich miejsce.

Zdalnie, ale na prawdziwym sprzęcie — VPN łączy Twój komputer z urządzeniami w sali szkoleniowej.

A jeśli wybierasz szkolenie gdziekolwiek indziej, zadaj jedno pytanie: „na czym prowadzone są warsztaty?”. Odpowiedź „na symulatorze” nie dyskwalifikuje kursu, ale po lekturze tego artykułu wiesz już dokładnie, czego w takim kursie nie będzie.