Termin „prędkość” jest w języku potocznym skrótem myślowym, który w technice sieciowej obejmuje co najmniej trzy różne wielkości fizyczne. Są one liczone w różnych punktach ścieżki komunikacyjnej, dotyczą różnych obiektów i mają różne jednostki.

Bandwidth jest wielkością z definicji standardu: wynika z modulacji, częstotliwości zegara i konstrukcji nadajnika. Nie da się go zwiększyć lepszym oprogramowaniem ani mocniejszym procesorem, można jedynie zmienić standard (przełączyć port na 2,5 Gbit/s zamiast 1 Gbit/s).

Throughput jest wynikiem pomiaru rzeczywistego strumienia bitów na wybranym interfejsie, zwykle liczonego jako różnica dwóch odczytów licznika bajtów podzielona przez czas między nimi. Wartość zależy od obciążenia, dlatego zmienia się w czasie.

Goodput jest tym, co widzi aplikacja: liczbą bajtów pliku albo treści, które dotarły do odbiorcy w całości i we właściwej kolejności. To najbliższe użytkownikowi pojęcie, ale również najtrudniejsze do pomiaru w sieci, bo wymaga znajomości treści ruchu albo współpracy aplikacji.

Przykład praktyczny, na którym oparto treść prezentacji, opisuje Igor Brzeżek w wpisie Zrozumienie „szybkości” sieci LAN: abonament 450/50 Mbit/s daje w teście prędkości wynik niższy od deklarowanego, a sieć 1 Gbit/s mierzona narzędziem iperf3 daje około 941 Mbit/s.

Różnica między tymi trzema liczbami nie wynika z błędu pomiaru, lecz z miejsca, w którym pomiar jest wykonywany. Oznaczenie portu opisuje zdolność odczytaną ze standardu, wynik testu aktywnego opisuje wydajność konkretnej ścieżki w konkretnym momencie, a odczucie użytkownika jest wynikiem działania aplikacji, która może nie wykorzystywać całej przepustowości z powodu własnego protokołu, limitów serwera albo opóźnień.

Przykład z praktyki operatora: światłowód z abonamentem 450/50 Mbit/s pokazuje w teście prędkości mniej niż 450 Mbit/s w kierunku pobierania. Nie oznacza to awarii łącza. Oznacza, że deklarowana przez operatora wartość to bandwidth, a zmierzona w teście - goodput. Różnica kilkunastu procent mieści się w granicach normy dla tego typu łącza.

Różnica między metrykami nie jest sztuczna. Każda z nich odpowiada na inne pytanie i jest liczona w innym miejscu, dlatego uzyskane wartości mogą się różnić nawet wtedy, gdy sieć działa prawidłowo.

Nazwy pochodzą z angielskiego i bywają używane zamiennie, co jest głównym źródłem nieporozumień. W literaturze technicznej przyjęto jednak dość jednoznaczny podział zakresów, warto go respektować w dokumentacji projektowej i w rozmowach z klientem.

Bandwidth bywa też używany w znaczeniu „pasma przenoszenia” wyrażonego w hercach, na przykład dla kanałów radiowych. W kontekście sieci LAN warto rozróżniać dwie wielkości: szerokość kanału w megahercach, która jest właściwością pasma fizycznego, oraz przepustowość w bitach na sekundę, która jest właściwością warstwy transmisyjnej.

Throughput liczy się najczęściej z dwóch odczytów licznika bajtów: jeśli w chwili t1 odczytano wartość B1, a w chwili t2 wartość B2, to szybkość wynosi (B2 − B1) × 8 / (t2 − t1). Licznik interfejsu zlicza bajty na łączu, dlatego wynik obejmuje wszystkie ramki, także te niosące pakiety sterujące.

Goodput wymaga odniesienia do konkretnego strumienia danych. Najprostszy sposób to porównanie rozmiaru pliku, który wysłano, z rozmiarem pliku, który dotarł do odbiorcy, z uwzględnieniem retransmisji, jeśli aplikacja je raportuje. Alternatywą jest przechwycenie ruchu i policzenie bajtów ładunku w obrębie konkretnej sesji TCP.

Zakresy każdej metryki są więc różne: przepustowość teoretyczna uwzględnia wyłącznie limit standardu, przepustowość rzeczywista zawiera wszystkie bity, które przeszły przez interfejs (łącznie z nagłówkami i retransmitowanymi danymi), a przepustowość użyteczna pomija potwierdzenia ACK, retransmisje, pakiety kontrolne i dane odrzucone z powodu błędnej sumy kontrolnej.

Ułożenie tematów w takiej kolejności ma cel dydaktyczny. Początkowe slajdy o budowie ramki odpowiadają na pytanie, dlaczego z 1 Gbit/s nie da się wycisnąć 1 Gbit/s danych aplikacji. Slajdy o metrykach porządkują język, w którym opisuje się wyniki. Slajdy o czynnikach wyjaśniają typowe obserwacje z pola. Ostatnia część łączy teorię z praktyką administracyjną: jak surowe liczniki urządzeń zamienić na wykres przepływu, na którym administrator zobaczy wąskie gardło.

Warto zaznaczyć, że prezentacja dotyczy warstwy lokalnej. Różnice między metrykami mają takie samo źródło również w sieciach rozległych, ale tam dochodzi jeszcze opóźnienie propagacji, które dla odległości międzykontynentalnych jest rzędu setek milisekund i całkowicie zmienia sposób wykorzystania przepustowości.

Enkapsulacja jest opisana w normie IEEE 802.3 dla warstwy łącznej oraz w dokumentacji RFC dla warstwy sieciowej i transportowej. Warto pamiętać, że nazwy jednostek zmieniają się zależnie od warstwy: w warstwie łącznej mówimy o ramce, w warstwie sieciowej o pakiecie, w warstwie transportowej o segmencie, a w warstwie fizycznej o symbolach.

W drugą stronę działa dekapsulacja: odbiorca zdejmuje kolejne warstwy, sprawdzając przy okazji sumy kontrolne. Dopiero po zdjęciu wszystkich nagłówków aplikacja otrzymuje swoje bajty. Każda dodatkowa warstwa jest więc kosztem dla obu kierunków transmisji, a nie tylko dla nadawania.

Policzony przykład nie uwzględnia jeszcze dwóch elementów: odstępu między ramkami (interframe gap) oraz ewentualnych potwierdzeń TCP. W praktyce na łączu 1 Gbit/s z ruchem o rozmiarze MSS 1460 B jeden segment danych zajmuje na kablu 1460 + 40 + 26 + 12 = 1538 B, co daje efektywność 94,9 procent jeszcze przed uwzględnieniem potwierdzeń.

Ten sam plik, przesłany w wielu małych pakietach, daje wynik znacznie gorszy. Przykładowo pakiet ICMP o ładunku 64 B zajmuje na kablu 64 + 20 + 26 + 12 = 122 B, ale z punktu widzenia aplikacji niesie tylko 64 B danych, czyli efektywność 52 procent. Dlatego w środowiskach sieciowych regularnie wykorzystuje się duże pakiety, a komunikacja oparta na małych pakietach (telefonia IP, DNS, komunikacja sterująca) wymaga osobnego podejścia do planowania przepustowości.

Norma IEEE 802.3 opisuje dwa warianty pola oznaczonego jako „typ lub długość”. W formacie IEEE 802.3 (z nagłówkiem LLC/SNAP) wartości mniejsze lub równe 1500 (0x05DC) oznaczają długość pola danych. W formacie Ethernet II (DIX), dominującym we współczesnych sieciach LAN, wartości większe lub równe 1536 (0x0600) reprezentują kod protokołu warstwy wyższej (EtherType). Zakres 1501–1535 (0x05DD–0x05FF) pozostaje niezdefiniowany.

Preambuła i znacznik SFD nie są wliczane do długości ramki w dokumentacji ani do wartości liczników SNMP. Są jednak obecne na medium i zajmują czas, dlatego w obliczeniach efektywności transmisji warto je uwzględniać.

Razem, bez preambuły i SFD, minimalna ramka ma 64 B, a maksymalna 1518 B. Z preambułą i SFD długość na kablu wynosi odpowiednio 72 B i 1526 B. Wartość ta nie jest jedynie konwencją dokumentacyjną: karta sieciowa rozpoznaje początek ramki właśnie po wzorze preambuły i znaczniku SFD.

Rozmiar 1518 B jest maksimum dla ramki bez znacznika VLAN. Po wprowadzeniu IEEE 802.1Q norma IEEE 802.3ac rozszerzyła ten limit o cztery bajty opisujące znacznik VLAN, czyli do 1522 B. W praktyce oznacza to, że ramka z ładunkiem 1500 B i znacznikiem VLAN ma długość 1522 B, ale nadal jest przenoszona przez interfejs o MTU 1500 B.

Wartość 1500 B dla MTU nie jest przypadkowa. Wywodzi się z ograniczeń historycznych: większe ramki zwiększały prawdopodobieństwo błędu odczytu całej ramki na niedoskonałych łączach, a w sieciach współdzielonych wydłużały czas wykrywania kolizji. Standard IEEE 802.3 zachował ten limit, dopóki nie pojawiły się aplikacje wymagające mniejszej liczby ramek na sekundę przy tej samej przepustowości.

Minimalna długość ramki wywodzi się z mechanizmu wykrywania kolizji CSMA/CD. Nadawca musi nadawać przez co najmniej 512 czasów bitowych, aby sygnał kolizji zdążył powrócić z najdalszego węzła sieci współdzielonej. 512 bitów to dokładnie 64 bajty licząc od adresu odbiorcy do końca sumy kontrolnej. Warto ta jest dziś w znacznej mierze formalnością, ponieważ współczesne przełączniki pracują wyłącznie w trybie pełnego dupleksu, w którym kolizje nie występują. Pozostała jednak w normie, bo stanowi podstawę formatu ramek rozpoznawanego przez wszystkie karty sieciowe.

Wartość MTU dotyczy warstwy sieciowej, a długość ramki dotyczy warstwy łącznej. Różnica 18 B to nagłówek Ethernet (6 + 6 + 2) oraz 4 B sumy kontrolnej. Dlatego pakiet IP o rozmiarze 1500 B jest przenoszony w ramce o długości 1518 B. W praktyce administracyjnej warto rozróżniać trzy pojęcia: rozmiar ramki widziany na medium, rozmiar pola danych ramki oraz rozmiar datagramu IP. Analizatory pokazują najczęściej pierwsze, systemy operacyjne konfigurują trzecie, a wartość 1500 B odnosi się do dwóch ostatnich.

Na poziomie kabla dochodzi do narzutu wymagany przez normę odstęp między ramkami, wynoszący 96 czasów bitowych. Dla łączy 10, 100 i 1000 Mbit/s jest to odpowiednio 12 bajtów, ponieważ czas bitu wynosi w nich odpowiednio 100 ns, 10 ns i 1 ns. Ten odstęp nie jest częścią ramki, ale zajmuje medium przez czas, w którym nadajnik nie może rozpocząć kolejnej ramki. Nie jest to pauza w pełnym rozumieniu: ścieżka bitowa pozostaje w tym czasie nieużywana.

Wartość 26 B narzutu jest prawidłowa dla ramki bez znacznika VLAN i bez ochrony MACsec. Po dodaniu znacznika IEEE 802.1Q narzut rośnie o cztery bajty do 30 B, a po włączeniu MACsec (IEEE 802.1AE) dochodzi kolejne 32 B, czyli 16 B znacznika bezpieczeństwa SecTAG i 16 B kodu uwierzytelniającego ICV. Łączny narzut dla ramki z VLAN i MACsec wynosi więc 62 B zamiast 26 B. Wartość 32 B jest typowa dla konfiguracji z AES-GCM i identyfikatorem SCI; z szyfrem bez identyfikatora SCI oraz z AES-CMAC narzut bywa mniejszy.

W praktyce to właśnie ochrona MACsec, tunele i znaczniki VLAN sprawiają, że efektywność spada znacznie bardziej niż sugeruje „goły” Ethernet. Ramka o danych 1500 B z MACsec i dwoma znacznikami VLAN zajmuje na kablu 1526 + 12 + 32 + 4 = 1574 B, a efektywność wynosi 1500 / 1574 = 95,3 procent. Wartości podane w tabeli liczą efektywność bez odstępu między ramkami, czyli według wzoru dane / (dane + 26).

Warto podkreślić, że powyższe obliczenia dotyczą wyłącznie ścieżki bitowej na warstwie łącznej. Na wynik końcowy wpływają jeszcze nagłówki warstwy sieciowej i transportowej, potwierdzenia oraz retransmisje, o czym mowa w kolejnych częściach prezentacji.

Standard IEEE 802.1Q został opublikowany w 1998 roku i obowiązuje w praktyce wszystkich instalacji wielkoskalowych. Zasada jest prosta: w polu typu protokołu umieszcza się wartość 0x8100, a właściwy kod protokołu przesuwa się o cztery bajty dalej. Odbiorca po rozpoznaniu 0x8100 odczytuje informację sterującą i traktuje kolejne cztery bajty jako kod protokołu.

Standard IEEE 802.1ad (Q-in-Q) umożliwia przenoszenie znacznika VLAN w ramce, która już zawiera taki znacznik, czyli dwa znaczniki po cztery bajty. Długość ramki rośnie wtedy do 1526 B. Standard ten opracowano z myślą o operatorach sieci telekomunikacyjnych, którzy muszą przenosić VLAN klientów we własnym VLAN operatora. W praktyce enterprise stosuje ten mechanizm rzadko, ale warto znać go z perspektywy diagnostyki: ramka z dwoma znacznikami VLAN pojawia się wtedy, gdy punkt końcowy jest VLAN-iem dostawcy usługowego połączonym z siecią klienta.

Znaczniki VLAN mają też skutek uboczny, o którym rzadko się myśli: zwiększają liczbę ramek potrzebną do przeniesienia tej samej ilości danych. Przy dużym ruchu i małych pakietach każda dodatkowa ramka to dodatkowe potwierdzenie TCP oraz dodatkowy wpis w licznikach interfejsu, co zauważalnie obciąża procesor przełącznika.

Poziom uwierzytelniania w VLAN (protokół 802.1X) i dynamiczna rekonfiguracja VLAN (GVRP lub MVRP) to mechanizmy niezwiązane z rozmiarem ramek, ale istotne operacyjnie: błędnie skonfigurowane VLAN powodują ciche gubienie ruchu, które objawia się w monitoringu jako znikający przepływ.

Dane z ramki nie są przesyłane jako ciąg bitów. Warstwa fizyczna (PHY) koduje je, grupując w symbole, a następnie moduluje amplitudę, fazę lub częstotliwość sygnału nośnego. Każda rodzina standardów Ethernet na skrętce wykorzystuje inny zestaw technik, dobrany do możliwości przewodu.

Podstawowa zasada: przepustowość teoretyczna nie wynika z szerokości pasma przewodu, lecz z ilości informacji niesionej przez jeden symbol oraz z liczby równoległych par. Gigabit Ethernet osiągnął 1000 Mbit/s na przewodzie kategorii 5e, który w prostych zastosowaniach nie nadawał się do 100 Mbit/s, dzięki zastosowaniu modulacji PAM-5 na czterech parach jednocześnie.

Kodowanie służy dwóm celom: wprowadza niewielki narzut, ale przede wszystkim zapobiega pojawianiu się długich serii jednakowych bitów, które utrudniałyby odbiornikowi odzyskanie synchronizacji zegarowej. Stąd w standardach o większej przepustowości stosuje się kody o coraz mniejszym narzucie: 4B/5B w 100BASE-TX daje około 20 procent, 8B/10B w 1000BASE-X na światłowodzie 25 procent, a 64B/65B w rodzinie GBASE-T zaledwie 1,5625 procent. Kodowanie 8B/10B w wersji Gigabit pojawia się wyłącznie w 1000BASE-X, a nie w 1000BASE-T na kablu miedzianym.

Standardy 2,5GBASE-T i 5GBASE-T wykorzystują modulację PAM-16, kodowanie 64B/65B o narzucie zaledwie 1,5625 procent oraz korekcję błędów LDPC. Dwuwymiarową konstelację 128 punktów (DSQ128) stosuje dopiero 10GBASE-T z normy IEEE 802.3an. Różnica przepustowości między 1 Gbit/s a 10 Gbit/s wynika więc przede wszystkim z gęstości symboli na przewodzie: 125 MBd dla 1000BASE-T i 800 MBd dla 10GBASE-T.

Standardy 2,5GBASE-T i 5GBASE-T powstały jako praktyczny kompromis między kosztami okablowania a szybkością. Pozwalają obsłużyć punkty dostępowe bez wymiany istniejącej kategoryzacji 5e, która w większości instalacji biurowych jest już poprowadzona. Korekcja LDPC występuje w całej rodzinie GBASE-T i pozwala pracować blisko granicy wydajności kanału.

Największy rozmiar danych przenoszony w jednym segmencie warstwy transportowej nazywamy MSS. Jest on wyznaczany przez MTU ścieżki pomniejszony o rozmiary nagłówków wszystkich warstw leżących poniżej oraz o nagłówek warstwy transportowej.

Rozmiary nagłówków, które wchodzą w te obliczenia, są następujące: nagłówek TCP ma 20 B w konfiguracji podstawowej, a opcje rozszerzone (znaczniki czasu, okna, selektywne potwierdzanie) zwiększają ten rozmiar do 40 B lub więcej. Nagłówek IPv6 ma 40 B bez rozszerzeń, a nagłówki rozszerzeń zwiększają ten rozmiar. Nagłówek UDP ma 8 B i nie zmienia się.

Wartość MSS jest negocjowana między nadawcą a odbiorcą podczas nawiązywania połączenia TCP: obie strony ogłaszają maksymalny rozmiar danych, jakiego są w stanie przyjąć, a przyjęta zostaje mniejsza z nich. Dzięki temu połączenie może działać poprawnie także wtedy, gdy jedna ze ścieżek ma mniejsze MTU.

W praktyce administracyjnej MSS pojawia się głównie w konfiguracji tuneli i sieci wirtualnych. Każda warstwa enkapsulacji zmniejsza ilość miejsca dostępnego dla danych, dlatego po włączeniu tunelu GRE, VXLAN lub IPsec warto jawnie ustawić MSS na urządzeniu końcowym tunelu albo skorzystać z trybu dopasowującego do wykrytego MTU.

Warto odróżnić MSS od MTU. MTU to limit rozmiaru datagramu narzucony przez warstwę łączną i trasę. MSS to limit rozmiaru danych narzucony przez warstwę transportową i możliwości odbiorcy. Pomylenie tych pojęć prowadzi do konfiguracji, w której MTU ustawiono na wartość MSS, a pakiet i tak nie mieści się w ramce.

Polecenie ping z flagą -M do ustawia bit „nie fragmentuj”, dzięki czemu wynik testu jest jednoznaczny. Warto korzystać z niego przy każdej zmianie tunelu lub konfiguracji MTU, ponieważ pozwala wskazać dokładnie największy rozmiar danych, który przejdzie przez całą ścieżkę.

Wartości w tabeli dotyczą warstwy łącznej lub wyższej. Narzuty transportowe, takie jak 20 B nagłówka IPv4 i 8 B nagłówka UDP, są uwzględnione w definicji MTU, dlatego wartość 1500 B oznacza maksymalny rozmiar datagramu IP, a nie maksymalny rozmiar pakietu na kablu.

Przy obliczaniu dostępnej przepustowości w tunelowanej ścieżce należy pomnożyć liczbę ramek przez pełny narzut, a nie tylko przez wartość z kolumny „Narzut”. Każda kolejna warstwa zwiększa liczbę ramek potrzebną do przesłania tej samej ilości danych, co w konsekwencji obniża efektywność transmisji.

Wartości MTU podłoża podane dla poszczególnych mechanizmów są wartościami minimalnymi, przy których tunel działa poprawnie. W praktyce warto ustawić MTU na całej ścieżce jednakowo, aby uniknąć konieczności fragmentacji pakietów przez routery pośrednie.

Mechanizm PMTUD jest opisany w dokumentach RFC 1191 (IPv4) i RFC 1981 (IPv6). Działa na poziomie hosta i wymaga, aby routery zwracały odpowiednie komunikaty ICMP. Komunikat „fragmentation needed” zawiera w polu nagłówka ICMP wartość MTU, której nadawca może użyć bez fragmentacji.

Blokowanie komunikatów ICMP jest częstym błędem, zwłaszcza na brzegach sieci, gdzie filtry upraszczają reguły do „zabronić ICMP”. Tymczasem bez komunikatów ICMP typu 3 kod 4 oraz ICMPv6 typu 2 mechanizm PMTUD przestaje działać, a zamiast niego potrzebna jest statyczna konfiguracja MTU na każdym routerze wzdłuż ścieżki.

Efekt czarnej dziury jest szczególnie zdradliwy, ponieważ objawia się dopiero dla dużych pakietów. Sesje HTTP o małych żądaniach i odpowiedziach działają poprawnie, a przesyłanie dużego pliku zatrzymuje się. Diagnosta, który zaczyna od testu przeglądarką, może dojść do wniosku, że problem leży w aplikacji.

Skutecznym środkiem zaradczym pozostaje automatyczne korygowanie wartości MSS pakietów SYN na routerze brzegowym (np. reguła mangle action=change-mss new-mss=clamp-to-pmtu w RouterOS). Mechanizm ten działa po stronie sieci i zabezpiecza klientów nawet przy braku poprawnej obsługi ICMP przez serwery pośrednie.

Przepustowość zmierzona na interfejsie rzadko odpowiada przepustowości użytecznej aplikacji. Kluczowe jest pytanie, na jakim poziomie pomiaru wykonano odczyt. Odczyt z licznika interfejsu pokazuje ruch na łączu. Odczyt na karcie sieciowej hosta pokazuje ruch, jaki dotarł do hosta, po odjęciu odrzuceń w buforze odbiorczym. Pomiar aplikacji pokazuje dane, które dotarły do procesu i zostały przetworzone.

Różnica między tymi trzema wartościami jest informacją diagnostyczną. Jeżeli licznik interfejsu pokazuje 990 Mbit/s, a iperf3 940 Mbit/s, to 50 Mbit/s zatrzymało się gdzieś pomiędzy medium a procesem. Jeżeli iperf3 pokazuje 940 Mbit/s, a przesyłanie pliku 700 Mbit/s, to problem leży w aplikacji, a nie w sieci.

Warto zwrócić uwagę na sposób raportowania błędów przez przełączniki. Licznik błędów odbioru (CRC, FCS, alignment) wskazuje problem fizyczny lub elektromagnetyczny. Licznik odrzuceń z powodu braku pamięci wskazuje, że urządzenie jest przeciążone liczbą tablic lub prędkością zmian adresów MAC. Te dwie przyczyny wymagają zupełnie różnych reakcji.

Rekomendowana praktyka polega na gromadzeniu liczników przez dłuższy okres, na przykład przez całą dobę, a nie jednorazowym odczycie. Problemy występujące w godzinach szczytu, na przykład wiele małych pakietów od klientów Wi-Fi, są niewidoczne w pomiarze wykonanym w weekend.

Zjawisko opóźnienia na żądanie (bufferbloat) zostało szczegółowo opisane w publikacji z 2011 roku. Kluczowa obserwacja dotyczy asymetrii: zwiększenie bufora poprawia widoczny wynik testu prędkości, ponieważ pozwala pochłonąć krótkotrwały szczyt ruchu, ale jednocześnie dramatycznie pogarsza czas reakcji systemu na zmianę obciążenia.

Dokument RFC 7567 (oraz wcześniejszy RFC 2309) formułuje kluczowe rekomendacje IETF w zakresie aktywnego zarządzania kolejkami (AQM). Kluczowa zasada jest taka, że bufor powinien być dostatecznie mały, aby opóźnienie pozostawało przewidywalne, a niedobór przepustowości sygnalizować szybko.

W praktyce administracyjnej zaleca się stosowanie buforów możliwie małych, dobranych do charakterystyki łącza, oraz włączanie aktywnego zarządzania kolejkami. W systemie Linux mechanizm fq_codel realizuje aktywne odrzucanie (AQM) i harmonogramowanie przepływów, ale nie kształtuje ruchu, czyli nie limituje przepustowości. Do ograniczenia pasma trzeba dołączyć osobny qdisc, na przykład HTB, HFSC albo tbf.

W środowiskach, w których liczy się przewidywalność opóźnienia, stosuje się dwa uzupełniające mechanizmy: ECN (Explicit Congestion Notification, RFC 3168), który pozwala routerowi powiadomić nadawcę bez odrzucania pakietu, oraz DSCP, który umożliwia oznaczenie ważności pakietu, tak aby przełącznik mógł zarezerwować przepustowość dla ruchu interaktywnego.

Pomiar opóźnienia wymaga dwóch punktów końcowych. Wartość ping na obu końcach obejmuje trasę w obie strony. Jeżeli problem dotyczy tylko jednego kierunku, pomiar jednostronny jest niewystarczający i należy go powtarzać osobno dla każdego kierunku i każdego przepływu.

Wybór protokołu transportowego wpływa na wynik pomiaru tak wyraźnie, że porównanie testów wykonanych różnymi protokołami bez podania warunków jest pozbawione znaczenia.

Mechanizm regulacji przepływu zdefiniowany w RFC 5681 składa się z czterech algorytmów: wolnego startu, unikania przepełnienia, szybkiego odtwarzania oraz zachowania ostrożności. Ich zadaniem jest znalezienie największego okna, przy którym nadawca nie powoduje utraty pakietów. W sieciach o małym opóźnieniu i dużej przepustowości okno osiąga wartość kilkudziesięciu kilobajtów w ułamku sekundy.

Przy dużej przepustowości i dużym opóźnieniu, typowym dla łącz WAN o przepustowości gigabitowej, ograniczeniem staje się nie przepustowość, lecz ilość danych, które zdążą dotrzeć do odbiorcy w czasie podróży w obie strony. Stąd konieczność skalowania okna, aby utrzymać łącze w pełni zajęte. Rozmiar okna odbiorczego i wysyłkowego jest przedmiotem automatycznej negocjacji w Linuksie, więc administrator zwykle nie musi go ustawiać ręcznie. Interwencja jest jednak uzasadniona przy łączach o bardzo dużym opóźnieniu.

Warto zaznaczyć, że UDP nie jest „szybszym TCP”. UDP pozwala uniknąć kosztu mechanizmu niezawodności, ale nie gwarantuje dostarczenia ani kolejności danych. Zastosowanie, w którym utrata pojedynczego pakietu jest akceptowalna, nie potrzebuje tej gwarancji i dlatego wykorzystuje prostotę protokołu. Zastosowanie wymagające pełnej integralności danych nie może z niego korzystać.

Protokół ARP jest bardzo prosty i właśnie dlatego podatny na nadużycia. Żądanie ARP jest wysyłane jako ramka rozgłoszeniowa z adresem docelowym ff:ff:ff:ff:ff:ff, więc dociera do wszystkich portów w obrębie VLAN, niezależnie od tego, do jakiego adresu IP się odnosi. Przy dużej liczbie hostów w jednym VLAN, szczególnie przy dużej liczbie urządzeń wirtualnych, udział tego ruchu w obciążeniu domeny rozgłoszeniowej staje się zauważalny.

• Żądanie ARP jest ramką rozgłoszeniową wysyłaną na porty w obrębie VLAN
• Odpowiedź ARP jest ramką unicastową kierowaną do hosta, który zapytał
• Żywot wpisu w tablicy sąsiedztwa wynosi od kilkudziesięciu sekund do kilku minut
• Wpisy są niezawodne: arp -n w Linuksie lub show ip arp na przełączniku

Standardowy mechanizm ochrony przed nieautoryzowanym wysyłaniem odpowiedzi ARP to uwierzytelnianie 802.1X w połączeniu z funkcją DHCP snooping. Funkcja ta pozwala przełącznikowi wiązać adresy IP przydzielone przez serwer DHCP z fizycznym portem, z którego przyszło żądanie, i odrzucać odpowiedzi ARP z innych portów.

Duże domeny rozgłoszeniowe mają jeszcze jedną cechę, o której warto pamiętać: rozmiar tablicy MAC przełącznika. Jeżeli w jednym VLAN pracuje więcej unikalnych adresów MAC, niż mieści tablica przełącznika, ramki będą rozsyłane jako nieznane (flooding), co dramatycznie zwiększa obciążenie każdego portu. Podzielenie sieci na mniejsze VLAN rozwiązuje ten problem.

Przepustowość jest wielkością, którą trzeba zmierzyć w konkretnym miejscu sieci i w określonym przedziale czasu. Pomiar pomiędzy dwoma punktami końcowymi (z aplikacji do aplikacji) daje wynik o wiele bardziej wartościowy niż odczyt licznika interfejsu, bo obejmuje całą ścieżkę.

Artykuł źródłowy podaje wynik pomiaru narzędziem iperf3 równy 941 Mbit/s dla sieci o przepustowości teoretycznej 1000 Mbit/s i opisuje tę wartość jako typową. Wartość 941 Mbit/s odpowiada 94,1 procent przepustowości teoretycznej, co dla łącza lokalnego jest wynikiem bardzo dobrym.

Warto zwrócić uwagę na dokładność arytmetyczną: 1500 B danych IP na 1538 B na kablu daje maksimum 975 Mbit/s, a nie 1000 Mbit/s. Różnica 25 Mbit/s, czyli 2,5 procent, jest narzutem ramkowym i odstępem między ramkami, a nie stratą. Kolejne 34 Mbit/s różnicy między 975 a 941 wynika z potwierdzeń i z ograniczeń wydajnościowych sprzętu.

Niezależnie od metody, wynik pomiaru jest wartościowy tylko wtedy, gdy wiadomo, w jakich warunkach został uzyskany. Dlatego raport pomiaru powinien zawierać: datę i godzinę, topologię odcinka, modele urządzeń, wersje oprogramowania, protokół testowy, czas trwania, liczbę powtórzeń oraz opis ruchu współistniejącego.

Nieporozumienia w interpretacji pomiarów wynikają w dużej mierze z mieszania dwóch systemów jednostek. W telekomunikacji prędkość transmisji podaje się w bitach na sekundę z przedrostkami dziesiętnymi (system SI), natomiast systemy operacyjne podają objętość danych w bajtach z przedrostkami binarnymi.

System SI definiuje przedrostki dziesiętne, w których kilo oznacza tysiąc, mega oznacza milion, a giga oznacza miliard. Zgodnie z tym zapisem 1 Gbit/s to miliard bitów na sekundę, czyli 125 000 000 bajtów na sekundę, a w zapisie binarnym około 119,2 MiB/s. Analogicznie 100 Mbit/s to 12 500 000 B/s, czyli około 11,9 MiB/s.

Standardy IEC 80000-13 oraz ISO/IEC 80000-13 wprowadzają przedrostki binarne, aby uniknąć niejednoznaczności: kibibajt (KiB) to 1024 bajty, mebibajt (MiB) to 1 048 576 bajtów, a gibibajt (GiB) to 1 073 741 824 bajtów. Wartość 1 TiB/s odpowiada 8796,093022 Gbit/s (czyli 8,796093022 Tbit/s), a 1 GiB/s odpowiada 8,589934592 Gbit/s. Różnica rośnie wraz z rzędem wielkości.

Ta rozbieżność jest w pełni przewidywalna i nie stanowi błędu po żadnej stronie. Błąd popełnia się dopiero wtedy, gdy porównuje się dwie wielkości podane w różnych systemach jednostek, na przykład prędkość łącza podaną w Mbit/s z prędkością zapisu na dysk podaną w MB/s zgodnie z konwencją systemu plików.

Przykład z artykułu źródłowego: abonament na łącze światłowodowe to 450/50 Mbit/s (450 Mbit/s na pobieranie, 50 Mbit/s na wysyłanie). Różnica między oczekiwaniem a pomiarem częściowo wynika właśnie z jednostek - użytkownik porównuje prędkość podaną w bitach na sekundę z prędkością zapisywania pliku podaną w bajtach na sekundę.

W systemach Linux warto rozróżnić dwie warstwy. Jednostki zapisane przez jądro (na przykład w free -h) są zazwyczaj binarne, natomiast jednostki użyte przez aplikacje do raportowania prędkości sieciowej bywają różne zależnie od implementacji. Narzędzia takie jak nload lub vnstat pozwalają jawnie wybrać sposób raportowania, co eliminuje nieporozumienia.

Monitorowanie w paśmie jest rozwiązaniem naturalnym: telemetria dociera tymi samymi urządzeniami, które przesyłają ruch biznesowy, więc automatycznie obejmuje całą sieć. Koszt początkowy jest najniższy, a wdrożenie nie wymaga okablowania ani dodatkowego sprzętu.

Problem pojawia się w sytuacji, gdy sieć jest przeciążona lub uszkodzona. Telemetria wtedy potrzebuje tej samej przepustowości, której brakuje, i tej samej drożności ścieżki, która właśnie zawiodła. System monitoringu staje się w tym momencie bezużyteczny, czyli traci swoją jedyną wartość: możliwość szybkiego rozpoznania problemu.

W praktyce rozwiązanie polega na wydzieleniu ruchu zarządzania do osobnego VLAN, a następnie na ograniczeniu jego przepustowości. Dzięki temu telemetria nigdy nie zajmie więcej niż zadany udział pasma, a pozostała przepustowość pozostaje dostępna dla ruchu biznesowego. Dodatkowo warto skonfigurować priorytetyzację, aby pakiety zarządzania były obsługiwane przed ruchem o niższym priorytecie.

Ważne jest również zabezpieczenie ścieżki zarządzania. Jeżeli agenty SNMP pracują w tej samej sieci VLAN co stanowiska robocze użytkowników, atakujący może przechwycić lub zmodyfikować telemetrię. Użycie SNMPv3 z uwierzytelnianiem i szyfrowaniem (USM) oraz umieszczenie zarządzania w osobnej domenie rozgłoszeniowej ogranicza to ryzyko.

Monitorowanie poza pasmem jest jedynym sposobem, aby mieć pewność, że telemetria dotrze do systemu monitoringu w sytuacji, w której sieć biznesowa jest przeciążona lub uszkodzona. Koszt tego rozwiązania jest wyraźnie wyższy, ponieważ wymaga podwójnego okablowania, osobnej adresacji i utrzymywania dodatkowego sprzętu.

W praktyce administratorzy stosują rozwiązanie hybrydowe: urządzenia krytyczne otrzymują pełne wyposażenie out-of-band z portem konsolowym i osobnym portem zarządzania, natomiast pozostałe urządzenia są monitorowane w paśmie, ale w wydzielonym VLAN zarządzania z ograniczoną przepustowością.

Konsola szeregowa pozostaje najbardziej niezawodnym kanałem dostępu. Nie zależy od konfiguracji sieci, od działania stosu TCP/IP ani od systemu operacyjnego urządzenia. Jej wadą jest prędkość transmisji, ale w sytuacji awaryjnej nie ma to znaczenia - liczy się możliwość wydania polecenia i odzyskania dostępu.

Ważnym szczegółem organizacyjnym jest zapewnienie dostępu do konsol wszystkich urządzeń, również tych, które nie mają dedykowanego portu zarządzania. Konsola serwisowa (console server) obsługująca wiele portów jest w tym celu standardowym wyposażeniem szaf serwerowych i szaf telekomunikacyjnych.

Protokół SNMP jest opisany w dokumentach RFC 1157 (wersja 1) oraz RFC 3411 do RFC 3418 (wersje 2c i 3). Umożliwia agentowi urządzenia udostępnienie liczników i wartości, a stacji zarządzającej ich cykliczne odpytywanie. Agent działa na urządzeniu sieciowym i utrzymuje hierarchię obiektów opisanych w bazie MIB. Stacja zarządzająca odpytuje agenta cyklicznie, najczęściej co 30 lub 60 sekund, i na tej podstawie buduje wykresy oraz alarmy.

Kwestią bezpieczeństwa nie należy bagatelizować. Wersje SNMPv1 i SNMPv2c przesyłają wspólną frazę (community) w postaci jawnej, co oznacza, że każdy, kto ma dostęp do sieci, może odczytać ją prostym zapytaniem. W praktyce napastnicy wykorzystują tę własność do odczytu tablicy adresów MAC i tablicy routingu, co ułatwia rozpoznanie topologii przed atakiem.

SNMPv3 wprowadza model bezpieczeństwa oparty na mechanizmie USM (User-based Security Model), który zapewnia uwierzytelnianie i szyfrowanie każdej komunikacji osobno dla każdego użytkownika. Wdrożenie jest bardziej pracochłonne, ponieważ wymaga wygenerowania i bezpiecznego rozdzielenia kluczy, ale jest jedynym właściwym rozwiązaniem w nowych instalacjach.

Warto wiedzieć, że nowoczesne systemy NMS, takie jak LibreNMS, obsługują wszystkie trzy wersje, ale domyślnie korzystają z SNMPv3, jeśli agent na to pozwala.

Liczniki bajtów są licznikami monotonicznymi, co oznacza, że ich wartość jedynie rośnie aż do momentu restartu urządzenia. Nie uwzględniają preambuły, znacznika SFD ani odstępu między ramkami, ale obejmują wszystko, co mieści się w ramce, wraz z nagłówkami i sumą kontrolną. Licznik ifOutOctets zawiera również ramki rozgłoszeniowe generowane przez interfejs.

Ponieważ liczniki są wartościami skumulowanymi od ostatniego restartu urządzenia, ich przyrost pomiędzy odczytami należy zapamiętać wraz z znacznikiem czasu. Systemy monitorujące wykonują dwa odczyty w odstępie kilkudziesięciu sekund i różnicę dzielą przez faktyczny upływ czasu, nie przez wartość nominalną interwału.

Wzór na przepustowość jest prosty, ale jego poprawne zastosowanie wymaga dwóch warunków: odczyty muszą dotyczyć tego samego interfejsu, a między nimi nie może nastąpić restart urządzenia, który wyzerowałby licznik.

Drugi warunek warto egzekwować w praktyce. Licznik sysUpTime pozwala wykryć restart: jeżeli jego wartość przy drugim odczycie jest mniejsza niż przy pierwszym, urządzenie uruchomiło się ponownie. W takiej sytuacji wynik jest bezwartościowy i należy go odrzucić, zamiast raportować fałszywie wysoką przepustowość.

W praktyce problem zawijania najlepiej rozwiązać, korzystając z liczników 64-bitowych, które są dostępne w każdym urządzeniu spełniającym RFC 2863, czyli praktycznie w każdym urządzeniu produkowanym po 2005 roku.

Przepustowość sama w sobie niewiele mówi. Informacją jest dopiero wykorzystanie łącza, czyli stosunek zmierzonej przepustowości do przepustowości nominalnej portu.

Ponadto progi należy ustalać osobno dla ruchu przychodzącego i wychodzącego. W sieci asymetrycznej typowej dla dostępu WAN wyjściowe obciążenie bywa znacznie wyższe niż przychodzące, ponieważ to użytkownik pobiera dane, a dostawca treści znajduje się w sieci szkieletowej.

Wartości progów podane w tabeli mają charakter orientacyjny. W praktyce warto je wyznaczyć na podstawie kilku tygodni obserwacji, aby uniknąć alarmów wynikających z typowych dla danej organizacji godzin szczytu.

Wartości liczników dot3Stats są dostępne tylko na portach, które raportują statystyki warstwy 2, czyli zwykle na portach fizycznych przełączników. Porty wirtualne, mosty i tunele zazwyczaj nie udostępniają tych obiektów, dlatego dla nich należy korzystać z grupy ifInErrors i ifOutErrors.

Liczniki błędów nigdy nie zerują się same z siebie, dlatego warto zapisać ich wartość początkową w chwili wdrożenia systemu monitorowania. Dopiero przyrost względem tej wartości ma znaczenie diagnostyczne; bezwzględna suma pozostawiona od ostatniego restartu urządzenia może wynosić tysiące bez żadnego związku z bieżącym stanem łącza.

Jeżeli licznik dot3StatsFCSErrors rośnie, ale dot3StatsAlignmentErrors pozostaje na poziomie zerowym, problem leży w przesyłanych danych, a nie w synchronizacji zegara. Odwrotna sytuacja sugeruje problem z generatorem zegara lub ustawieniami portu.

Licznik SNMP jest licznikiem monotonicznym, który resetuje się przy restarcie urządzenia, a w niektórych implementacjach również przy zmianie konfiguracji lub przy restarcie modułu. Zdarza się, że zgłoszona prędkość jest nierealistyczna albo w ogóle ujemna.

Prawidłowa logika obliczania przepustowości wymaga trzech kroków. Po pierwsze, system monitorujący musi rozpoznać, czy pomiędzy dwoma odczytami nastąpił reset licznika, korzystając z pola ifCounterDiscontinuityTime. Po drugie, przy liczniku 32-bitowym trzeba sprawdzić, czy przeliczenie nastąpiło między odczytami, i w razie potrzeby dodać wartość 2³² do różnicy. Po trzecie, różnicę dzieli się przez faktyczny czas, jaki upłynął między odczytami, wyrażony w sekundach.

Dopiero po tych trzech krokach wynik można porównać z przepustowością nominalną portu. Jeżeli wynik przekracza tę wartość, przyczyną jest najczęściej błąd mapowania indeksu interfejsu w systemie monitorowania, a nie niedokładność samego odczytu.

Warto pamiętać, że pole ifCounterDiscontinuityTime wskazuje czas ostatniego zerowania licznika, a nie czas ostatniego odczytu. Jeżeli wartość tego pola jest późniejsza niż znacznik czasu pierwszego odczytu, wynik z tego okresu należy odrzucić jako niepoprawny.

Agent działa na urządzeniu, a kolektor odbiera i analizuje próbki. Próbkowanie pakietów odbywa się w sprzęcie, zanim urządzenie wykona jakiekolwiek przetwarzanie. Dzięki temu koszt jest minimalny i nie zależy od obciążenia procesora. Losowy wybór jednego pakietu na 512 pozwala oszacować rozkład ruchu z dokładnością wystarczającą do identyfikacji dominujących przepływów.

• Próbkowanie pakietów: urządzenie losuje jeden pakiet na N (domyślnie 512) i kopiuje jego nagłówek (20 do 64 B) do pamięci podręcznej. Co sekundę wysyła całą paczkę próbek do kolektora przez UDP na porcie 6343.
• Liczniki interfejsów: niezależnie od próbek, raz na około sekundę urządzenie wysyła pełne wartości liczników IF-MIB (pakietów, bajtów, odrzuceń, błędów).

Liczniki interfejsów są przesyłane niezależnie i w komplecie, dzięki czemu dane o przepustowości są dokładne, a nie oszacowane. To ważne rozróżnienie: sFlow daje dokładne dane o wolumenie, ale przybliżone dane o strukturze ruchu. Bieżącą wersję sFlow v5 definiuje specyfikacja konsorcjum sFlow.org (RFC 3176 dokumentował historyczną wersję sFlow v2).

Zalety w porównaniu z NetFlow

• znacznie mniejsze obciążenie procesora urządzenia (sprzętowa tablica próbek)
• reakcja na zmiany w ciągu sekundy, NetFlow odczytuje liczniki co kilka minut
• działa na przełącznikach, routerach, serwerach i w środowiskach wirtualnych jednocześnie
• obsługuje rozróżnianie VLAN, interfejsów i typów ruchu

Wybór technologii zależy od potrzeb. Jeżeli wystarczy rozpoznanie głównych źródeł i odbiorców ruchu oraz wykrywanie anomalii, sFlow jest zwykle prostszy w wdrożeniu. Jeżeli potrzebna jest dokładna księgowość przepływów z podziałem na aplikacje, NetFlow lub IPFIX pozostają właściwszym wyborem, mimo większego obciążenia.

Przepustowość na pojedynczym porcie mówi, że ruch jest, ale nie mówi, co go powoduje. Aby to ustalić, potrzebna jest agregacja na poziomie sesji lub hostów. Narzędzia NetFlow, sFlow z analizą topologii oraz statystyki na ścieżce (conntrack) dają takie zestawienie.

Analiza ruchu powinna przebiegać od ogółu do szczegółu. Pierwszym krokiem jest zawsze ustalenie, który interfejs jest obciążony. Dopiero potem warto pytać, co ten ruch powoduje. Pomijanie tego kroku prowadzi do sytuacji, w której administrator analizuje zawartość pakietów z hosta, który niczego nie wysyła.

Kolejne poziomy szczegółowości wymagają różnych narzędzi. Poziom interfejsu jest obsługiwany przez SNMP i nie wymaga żadnej dodatkowej konfiguracji. Poziom hostów i sesji wymaga włączenia NetFlow lub sFlow. Poziom aplikacji wymaga głębszej inspekcji pakietów, na przykład przez system wykrywania protokołów na podstawie sygnatur.

W praktyce około osiemdziesięciu procent problemów z wydajnością jest rozwiązywalnych na poziomie interfejsu i hostów. Poziom aplikacji jest potrzebny głównie wtedy, gdy trzeba rozróżnić usługi o podobnym wzorcu ruchu, na przykład kilka aplikacji synchronizujących pliki jednocześnie.

Plan wdrożenia przedstawiony na slajdzie ma charakter przyrostowy. Każdy kolejny krok dostarcza informacji, których wcześniej nie było, i nie wymaga zmiany poprzednich. Taki układ pozwala uzyskać wartość już na pierwszym etapie, zamiast czekać na kompletną konfigurację.

NetFlow i IPFIX różnią się od sFlow zasadniczo: nie próbkują zdarzeń, lecz śledzą poszczególne przepływy. Urządzenie utrzymuje tablicę aktywnych sesji, a po spełnieniu warunku (upływ czasu aktywności, przekroczenie progu bajtów lub zakończenie sesji) raportuje jej podsumowanie do kolektora.

Definicja przepływu oparta na pięciokrotce (adres źródłowy, port źródłowy, adres docelowy, port docelowy, protokół) jest prosta, ale ma istotne ograniczenie. Zmiana adresu lub portu w trakcie sesji tworzy nowy przepływ. Dotyczy to szczególnie sieci z translacją adresów (NAT), gdzie jeden przepływ obserwowany wewnątrz sieci będzie się różnił od przepływu widzianego na zewnątrz.

IPFIX, w przeciwieństwie do NetFlow v9, pozwala dodać informacje o warstwie wyższej do raportu, takie jak adresy MAC, wartość DSCP, system operacyjny hosta czy typ aplikacji rozpoznany z sygnatur. Ta rozszerzalność sprawia, że IPFIX jest właściwym wyborem w środowiskach, w których wymagana jest szczegółowa księgowość ruchu.

Scenariusze tego typu są tak częste, że warto mieć je przygotowane jako gotowy algorytm postępowania. Kluczowy jest pierwszy krok: potwierdzenie, że problem rzeczywiście dotyczy sieci. Jeżeli ping do aplikacji przechodzi bez utraty pakietów i z niskim opóźnieniem, sieć nie jest przyczyną i dalsze pomiary sieciowe są bezcelowe.

Drugi krok to rozbicie ruchu na źródła. W opisanym scenariuszu jeden host generował 45 procent całego ruchu na porcie brzegowym, co natychmiast wskazało kierunek poszukiwań.

Piąty krok, analiza procesów na hoście, ujawnił rzeczywistą przyczynę: kopia zapasowa intensywnie korzystała z dysku, przez co aplikacja webowa pracująca na tym samym hoście oczekiwała na operacje wejścia-wyjścia. Rozbudowa łącza nie rozwiązałaby problemu - zwiększyłaby jedynie przepustowość, której i tak nie brakowało.

Wniosek ma zastosowanie ogólne: wysoka przepustowość łącza jest objawem, a nie przyczyną większości zgłaszanych problemów z wydajnością. Przed podjęciem decyzji o rozbudowie infrastruktury warto wykonać test end-to-end, który jest najtańszym sposobem wykluczenia sieci jako przyczyny.

Okresowy charakter awarii jest najcenniejszą wskazówką diagnostyczną. Błąd występujący stale sugeruje problem konfiguracyjny lub fizyczny trwały. Błąd występujący o określonej porze dnia wskazuje na czynnik środowiskowy, który pojawia się tylko w określonych warunkach.

Opisany scenariusz jest typowy dla biur, w których wieczorem zmienia się oświetlenie albo włączają się urządzenia o wyższym poborze prądu. Źródła zasilania, zwłaszcza starsze, generują zakłócenia, które mogą wpływać na sąsiednie przewody sieciowe prowadzone w tym samym kanale.

Różnica między licznikiem błędów sumy kontrolnej a licznikiem błędów wyrównania ma znaczenie diagnostyczne. Pierwszy wskazuje na zniekształcenie danych, drugi na problem z synchronizacją zegara. W opisanym przypadku niski poziom drugiego licznika wykluczył problem z zegarem i skierował uwagę na fizyczną integralność danych.

Wymiana przewodu rozwiązała objaw, ale analiza długoterminowa wskazała drugą możliwą przyczynę: funkcję oszczędzania energii EEE, znormalizowaną w IEEE 802.3az. W niektórych urządzeniach jej działanie powoduje mikrozawieszenia portu, które objawiają się jako krótkotrwałe przerwy w transmisji.

Poniższa lista porządkuje telemetrię od najważniejszej do uzupełniającej. Nie każdy punkt jest konieczny w małej instalacji, ale warto wiedzieć, co się pomija i dlaczego.

Lista kontrolna opisuje telemetrię w kolejności priorytetów. Warstwa pierwsza obejmuje dane, bez których system monitorowania nie ma sensu: bez informacji o tym, czy urządzenie odpowiada, nie wiemy, czy pozostałe liczniki są wiarygodne.

Warstwa druga służy diagnostyce. Opóźnienie i utrata pakietów pozwalają wykryć sytuacje, w których przepustowość jest prawidłowa, a użytkownik odczuwa problemy. Rozbicie ruchu wskazuje źródło obciążenia.

Warstwa trzecia jest uzupełniająca, ale w praktyce ratuje sytuacje, w których problem leży poza warstwą sieciową: przegrzewa się szafa, kończy się bateria podtrzymania, wygasa licencja.

Najczęstszą przyczyną porażki systemów monitorowania jest nadmiar alarmów. Gdy administrator otrzymuje kilkadziesiąt powiadomień dziennie, z których większość nie wymaga działania, przestaje je czytać. Dlatego zasadą nadrzędną jest prostota: sześć dobrze zmierzonych wartości z czytelnymi progami jest cenniejsze niż czterdzieści wartości bez progów.

Prezentacja prowadziła od budowy ramki do monitorowania, pokazując, że wszystkie te tematy są ze sobą powiązane. Pierwsze dziesięć slajdów wyjaśniało, dlaczego z 1000 Mbit/s nie da się uzyskać 1000 Mbit/s danych aplikacji. Kolejne definiowały trzy metryki i pokazywały, czym się różnią. Ostatnie omawiały narzędzia pomiarowe i sposób monitorowania.

Łańcuch wartości przedstawiony na slajdzie jest najlepszym podsumowaniem. Przepustowość teoretyczna 1000 Mbit/s jest granicą narzuconą przez standard. Po uwzględnieniu narzutu ramek i odstępu między ramkami maksimum spada do 975 Mbit/s. Pomiar aplikacyjny narzędziem iperf3 daje zwykle około 941 Mbit/s, a dane faktycznie przetworzone przez aplikację stanowią nieco mniej, jeśli uwzględnić retransmisje i potwierdzenia.

W praktyce administrator, który potrafi wyjaśnić te liczby, jest w stanie poprawnie zinterpretować każdy wykres przepustowości i każdy alarm. Wartość 97 procent wykorzystania łącza jest wartością normalną, ale 97 procent przy jednoczesnym wzroście licznika odrzuceń wyjściowych jest sygnałem, że przepustowości zabrakło.

Prezentacja opiera się na dokumentach normalizacyjnych, a nie na materiałach wtórnych. Wszystkie wartości liczbowe dotyczące rozmiarów ramek, rozmiarów nagłówków i zakresów liczników można zweryfikować w dokumentach IETF i normach IEEE.

Dokument RFC 2863 jest szczególnie ważny dla tematu monitorowania, ponieważ wprowadził grupę ifXTable z licznikami 64-bitowymi oraz pole ifHighSpeed, z którego korzystają wszystkie systemy monitorowania do obliczania wykorzystania łącza.

Dokument RFC 7567 (oraz wcześniejszy RFC 2309) formułuje kluczowe rekomendacje IETF w zakresie aktywnego zarządzania kolejkami (AQM) i przeciwdziałania bufferbloat.

Dokumenty RFC 5681 (kontrola przepływu w TCP), RFC 6582 (szybkie odtwarzanie po utracie), RFC 7323 (skalowanie okna TCP Window Scale) oraz RFC 6928 (zwiększone okno początkowe initcwnd) uzupełniają obraz mechanizmów, które decydują o osiągalnej przepustowości w sieciach o dużej propagacji.

W kwestii narzędzi warto podkreślić, że iperf3 służy do pomiaru, a iptraf-ng do obserwacji. Pomieszanie tych dwóch zastosowań prowadzi do błędnych wniosków: iptraf-ng nie nadaje się do benchmarku, ponieważ nie generuje kontrolowanego obciążenia.

W tabeli pominięto dwie wartości efektywności dla ramek o 1500 B i 9000 B danych, aby ograniczyć liczbę wierszy. Dla 1500 B danych efektywność wynosi 1500 / 1526 = 98,3 procent bez odstępu między ramkami, a po uwzględnieniu odstępu 1500 / 1538 = 97,5 procent. Dla 9000 B danych wartości te wynoszą odpowiednio 99,7 i 99,5 procent.

Tabela zbiera wartości, do których prezentacja odwoływała się wielokrotnie. Warto zapamiętać przede wszystkim te cztery: minimalny rozmiar ramki 64 B, maksymalny 1518 B, narzut 26 B i MTU 1500 B. Pozostałe wartości łatwiej jest wyliczyć, gdy te cztery są znane.

Narzut 26 B składa się z ośmiu bajtów preambuły i znacznika SFD, dwunastu bajtów adresów MAC, dwóch bajtów kodu protokołu oraz czterech bajtów sumy kontrolnej. Warto pamiętać, że preambuła i SFD nie są wliczane do długości ramki w dokumentacji ani do wartości liczników SNMP, ale zajmują czas na medium.

Po uwzględnieniu odstępu między ramkami wartość 26 B nie wystarcza do obliczenia efektywności. Dla ramek o maksymalnym rozmiarze realna liczba to 1538 B na kablu (1526 B ramki plus 12 B odstępu), co daje efektywność 97,5 procent, a nie 98,3 procent.

Wartość 34,4 sekundy dla zawijania się licznika 32-bitowego wynika z podziału 4 294 967 295 bajtów przez 125 000 000 bajtów na sekundę. W praktyce oznacza to, że dla łącza o przepustowości 1 Gbit/s odpytywanie z interwałem krótszym niż 35 sekund i licznik 32-bitowy dają wynik, którego nie da się poprawnie obliczyć bez obsługi zawijania.

W tabeli pominięto dwa liczniki o podobnym znaczeniu diagnostycznym: dot3StatsAlignmentErrors (1.3.6.1.2.1.10.7.2.1.2) oraz dot3StatsSymbolErrors (1.3.6.1.2.1.10.7.2.1.14), opisane w scenariuszu diagnostycznym na slajdzie 32.

Czas i status opisują trzy obiekty: sysUpTime (1.3.6.1.2.1.1.3.0, czas pracy od restartu w setnych sekundy, typ TimeTicks), sysDescr (1.3.6.1.2.1.1.1.0, opis systemu) oraz sysName (1.3.6.1.2.1.1.5.0, nazwa hosta).

Identyfikatory OID pełnią podobną funkcję jak adresy w sieci: jednoznacznie wskazują obiekt w hierarchii obiektów zarządzanych. Wartość 1.3.6.1 oznacza organizację ISO, 1.3.6.1.2 to obszar zarządzania obiektami, a 1.3.6.1.2.1 to MIB-2, czyli standardową bazę obiektów.

Grupa interfejsów występuje w dwóch wariantach. Podstawowa tabela z dokumentu RFC 1213 zawiera liczniki 32-bitowe i jest oznaczona prefiksem 1.3.6.1.2.1.2.2.1. Tabela rozszerzeń z dokumentu RFC 2863 znajduje się pod prefiksem 1.3.6.1.2.1.31.1.1.1 i zawiera liczniki 64-bitowe oraz pole ifHighSpeed.

W praktyce systemy monitorowania korzystają prawie wyłącznie z tabeli rozszerzeń, ponieważ liczniki 32-bitowe nie nadają się do monitorowania szybkich łączy. Pole ifSpeed, jedyne źródło prędkości nominalnej w starszej tabeli, ma zakres 32-bitowy, co ogranicza je do około 4 Gbit/s.

Ostatnia część OID to indeks interfejsu, czyli ifIndex. Warto pamiętać, że indeksy mogą się zmienić po restarcie urządzenia, dlatego systemy monitorowania przechowują mapowanie między indeksem a nazwą interfejsu i odświeżają je okresowo. Pole ifName, dostępne w tabeli rozszerzeń pod indeksem 1, służy właśnie do tego celu.

Wartość praktyczna prezentacji widoczna jest w zestawieniu poleceń. Diagnosta, który potrafi szybko odczytać licznik SNMP i policzyć przepustowość, rozwiązuje większość zgłoszeń bez potrzeby uruchamiania rozbudowanych narzędzi.

Narządzie iperf3 warto poznać dokładniej, ponieważ oferuje kilka parametrów istotnych diagnostycznie. Parametr -P uruchamia wiele równoległych strumieni, co pozwala sprawdzić, czy wąskim gardłem jest jedno połączenie TCP, czy też cała przepustowość łącza. Parametr -R odwraca kierunek, co pozwala wykryć asymetrię. Parametr -w wymusza okno, a -M maksymalny rozmiar segmentu.

W systemie Linux szczególnie użyteczne jest polecenie tc -s qdisc, które pokazuje liczbę pakietów odrzuconych w kolejkach. Ta wartość jest często jedyną wiarygodną informacją o przeciążeniu, gdyż nie wymaga analizy żadnego logu i jest dostępna natychmiast.

Pozostałe polecenia przydatne w diagnostyce to ss -s (podsumowanie stanu gniazd sieciowych), vnstat --oneline b (zliczony ruch w bajtach), snmpwalk po nazwach interfejsów, snmpbulkget do pobrania 100 wartości naraz oraz w RouterOS /interface ethernet print stats where name="ether1", /ip flow-cache print stats where interface=ether1 i /tool traffic-generator inject interface=ether1 number-of-packets=1000 packet-size=64.

Zalecana kolejność testów ma na celu oszczędność czasu. Sprawdzenie liczników błędów jest natychmiastowe i jednoznaczne. Pomiar iperf3 zajmuje kilkadziesiąt sekund. Test MTU jest szybki, ale wymaga znajomości podejrzanego odcinka. Analiza kolejek jest najdokładniejsza, ale wymaga znajomości konfiguracji mechanizmów zarządzania ruchem.

Większość błędów w interpretacji pomiarów wynika z jednej przyczyny: utożsamiania liczb pochodzących z różnych warstw stosu protokołów. Liczba 1000 na oznaczeniu portu oznacza przepustowość w megabitach na sekundę, liczba 1000 w liczniku bajtów oznacza kilka gigabajtów przetworzonych, a liczba 1000 w raporcie zapisu pliku oznacza kilka megabajtów na sekundę.

Najczęściej spotykany błąd to porównywanie przepustowości łącza podanej w Mbit/s z prędkością zapisu na dysk podaną w MB/s. Różnica jest w tym przypadku ośmiokrotna, co przy interpretacji wartości dosłownej daje wynik, że sieć jest osiem razes wolniejsza, niż jest w rzeczywistości.

Drugi częsty błąd to podwójne ujmowanie narzutu. Liczniki bajtów obejmują już sumy kontrolne ramek, więc dodatkowe odejmowanie 18 B prowadzi do zawyżenia wyniku. Warto wiedzieć, że liczniki nie obejmują preambuły, znacznika SFD i odstępu między ramkami, ale obejmują wszystko, co mieści się w ramce.

Trzeci błąd, równie powszechny, to utożsamianie wysokiej przepustowości z dobrym stanem sieci. Przepustowość na poziomie 95 procent wraz z rosnącym licznikiem odrzuceń wyjściowych jest stanem alarmowym, a nie dowodem wydajności. Podobnie jak droga, która jest pełna, ale sprawna, sieć obciążona do granic jest mniej użyteczna niż sieć obciążona w połowie.

Prezentacja zebrała w jednym miejscu tematy, które w codziennej pracy administratora bywają traktowane jako odrębne. Enkapsulacja i jednostki są sprawą warstwy fizycznej i teorii. Przepustowość i pomiar są sprawą narzędzi. Monitorowanie jest sprawą systemów zarządzania. Tymczasem wszystkie te tematy łączy jedna zasada: różnica między deklarowaną a rzeczywistą wydajnością sieci ma konkretne, mierzalne przyczyny.

Najczęstsze z tych przyczyn to narzut ramek i potwierdzeń, rozmiar pakietów, wydajność urządzeń oraz opóźnienie wynikające z kolejek. Wszystkie są mierzalne i wszystkie można ograniczyć, jeśli zna się narzędzia i interpretuje się ich wyniki właściwie.

Warto zwrócić uwagę na porządek prezentacji. Zaczynała się od pytania, dlaczego łącze 1 Gbit/s nie przenosi 1 Gbit/s danych, a kończyła na zestawieniu narzędzi monitorowania. Taki układ jest celowy - zrozumienie przyczyny ułatwia interpretację objawu, a znajomość narzędzi ułatwia potwierdzenie przyczyny.

Końcowe zalecenie jest proste i warto je zapamiętać: zanim podejmiesz decyzję o rozbudowie sieci, wykonaj pomiar. Różnica między subiektywnym odczuciem wolnej sieci a rzeczywistym wąskim gardłem ujawnia się zwykle w ciągu kilku minut pracy z narzędziami opisanymi w tej prezentacji.