W skrócie TAK. Sieć jest bardzo prosta, tj. 16 kamer IP oraz jeden rejestrator podłączone do przełącznika. Sumaryczny ruch generowany przez kamery, który trafia do rejestratora, nie przekracza 60 Mb/s. Wydawać by się mogło, że taki ruch to drobnostka i każdy przełącznik obsłuży go bez problemu. A tu jednak niespodzianka, bo przełącznik Cisco, ruch niecałe 60 Mb/s i regularne dropy pakietów na poziomie przekraczającym 1% i ponad 60 odrzuconych pakietów na sekundę. Uszkodzony przełącznik?
Ile ruchu przełącza switch?
Kamery generują strumień H.265 nie większy niż 4 Mb/s. Uwzględniając zatem narzut komunikacyjny, ruch przychodzący do przełącznika na porcie kamery nie przekracza 5 Mb/s. Kamer jest 16 i wszystkie wysyłają ruch do rejestratora podłączonego do portu FastEthernet 0/18. Tak, FastEthernet, czyli przełącznik ma interfejsy 100 Mb/s, ale dla kamer i rejestratora jest to w zupełności wystarczające. Gdyby 16 kamer generowało jednocześnie ruch 5 Mb/s każda, to daje nam to 80 Mb/s ruch na porcie rejestratora. W praktyce kamery nie generują stałego strumienia i sumaryczny ruch nigdy nie przekracza 60 Mb/s. Więc porty FastEthernet (100 Mb/s) wydają się w zupełności wystarczające.
Uwaga - istotna jest liczba PPS a nie BPS!
PPS to packets per seconds, a BPS to bits per seconds, czyli odpowiednio liczba pakietów i bitów na sekundę. W większości przypadków ograniczeniem urządzeń jest PPS, a nie BPS, bo liczba BPS wynika ze średniej wielkości pakietu i PPS. W tym przykładzie liczba PPS jest niewielka (ok. 6000 pakietów na sekundę), więc w artykule operuję liczbą BPS (Mb/s) dla większej czytelności.
Jakie problemy generuje ten ruch?
Na interfejsie, do którego podłączony jest rejestrator, odrzucanych jest ponad 60 pakietów na sekundę, co stanowi ponad 1% pakietów wysyłanych tym interfejsem.
S#show interfaces Fa0/18 summary *: interface is up IHQ: pkts in input hold queue IQD: pkts dropped from input queue OHQ: pkts in output hold queue OQD: pkts dropped from output queue RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec) TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec) TRTL: throttle count Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL ------------------------------------------------------------------------- * FastEthernet0/18 0 0 0 4056775 1850000 3153 54678000 6272 0
A po 10 sekundach …
S#show interfaces Fa0/18 summary
...
Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL
-------------------------------------------------------------------------
* FastEthernet0/18 0 0 0 4057440 1850000 3153 54678000 6272 0
Czyli przez 10 sekund mamy ponad 600 dropów, które równomiernie przyrastają, a ruch na interfejsie nie przekracza 60 Mb/s:
S#show interfaces Fa0/18 FastEthernet0/18 is up, line protocol is up (connected) ... Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 5790913 ... 5 minute input rate 1911000 bits/sec, 3144 packets/sec 5 minute output rate 54877000 bits/sec, 6270 packets/sec ...
Liczba 6000 PPS jest śmiesznie niska, a przy ok. 600 dropach na 10 sekund, daje nam to ponad 1% ubitych pakietów!
Domyślnie na przełącznikach Cisco QoS nie jest włączony. Ale wydawać by się mogło, że taki stosunkowo przecież niewielki ruch nie będzie żadnym wyzwaniem i nie powinien generować problemów. Podmiana przełącznika, aktualizacja IOS nie zmienia sytuacji. Wniosek (nie ukrywam, że zaskakujący) jest taki, że to po prostu tak działa.
Jak rozwiązać ten problem?
Podłączenie rejestratora do portu GigabitEthernet być może rozwiązałoby problem, ale przełącznik ma porty GigabitEthernet w formie SFP, a aktualnie mam tylko moduły światłowodowe. Sprawdźmy zatem, jak przełącznik obsługuje ruch na porcie. Ten model przełącznika ma cztery wyjściowe kolejki sprzętowe na każdym interfejsie, ale bez włączonego QoS ewidentnie używa tylko jednej z nich.
S#show mls qos interface Fa0/18 statistics ... output queues enqueued: queue: threshold1 threshold2 threshold3 ----------------------------------------------- queue 0: 2 0 0 queue 1: 0 233 112964 queue 2: 0 0 0 queue 3: 0 0 1029763263 output queues dropped: queue: threshold1 threshold2 threshold3 ----------------------------------------------- queue 0: 0 0 0 queue 1: 0 0 0 queue 2: 0 0 0 queue 3: 0 0 5790685 ------------------------------------------------
Pakiety są kolejkowane i częściowo odrzucane tylko w czwartej kolejce, a pozostałe kolejki nie są w ogóle używane.
Domyślnie każda z kolejek na każdym interfejsie ma przydzielona równą ilość pamięci.
S#show mls qos interface Fa0/18 buffers FastEthernet0/18 The port is mapped to qset : 1 The allocations between the queues are : 25 25 25 25
Dodatkowo każda z kolejek połowę pamięci “oddaje” do tzw. części wspólnej.
S#show mls qos queue-set 1 Queueset: 1 Queue : 1 2 3 4 ---------------------------------------------- buffers : 25 25 25 25 threshold1: 100 200 100 100 threshold2: 100 200 100 100 reserved : 50 50 50 50 maximum : 400 400 400 400
Spróbujmy zwiększyć rozmiar bufora dla kolejki, która wysyła ruch przez port Fa0/18
Implementacja QoS — czy będzie proprawa?
Kamery wysyłają ruch z DSCP równych zero. Po włączeniu QoS ruch ten domyślnie trafia do kolejki nr 1 (licząc od zera). 85% buforów związanych z danym interfejsem przeznaczamy zatem dla kolejki nr 1 oraz rezerwujemy dla niej maksymalna możliwą do zarezerwowania ilość pamięci. W tej sytuacji rozwiązanie to nie będzie miało negatywnych skutków, bo pozostałe interfejsy i kolejki praktycznie nie obsługują żadnego ruchu.
mls qos mls qos queue-set output 2 threshold 2 3200 3200 100 3200 mls qos queue-set output 2 buffers 5 85 5 5 interface FastEthernet0/18 queue-set 2
Efekt — praktycznie brak odrzucanych pakietów na interfejsie. Po 14 dniach na interfejsie mamy 3755 dropów na ponad 5585 mln obsłużonych pakietów, co daje mniej niż 1 odrzucony pakiet na milion.
S#show interfaces Fa0/18 FastEthernet0/18 is up, line protocol is up (connected) ... Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 3755 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 1264000 bits/sec, 2262 packets/sec 5 minute output rate 38232000 bits/sec, 4972 packets/sec ... 5585896936 packets output, 5224299525740 bytes, 0 underruns ...
Szkolenie QoS?
Chcesz poznać różne mechanizmy QoS, nauczyć się analizować takie i podobne problemy? Zapisz się na szkolenie QoS, w trakcie którego zdobędziesz praktyczną wiedzę z zakresu działania, doboru do konkretnych wymagań i założeń projektowych oraz ostatecznie konfiguracji wszystkich aktualnie stosowanych mechanizmów QoS w sieciach IP.
Wnioski
Z artykułu płyną trzy główne wnioski.
- W nawet stosunkowo prostych na pozór sieciach warto implementować QoS, aby uniknąć problemów z transmisją danych.
- Warto używać urządzeń, które dają nam możliwość dogłębnej analizy, w jaki sposób przetwarzany jest na nich ruch. Mając do dyspozycji prosty przełącznik (nie mówiąc już o przełączniku niezarządzalnym) nie byłoby najmniejszych szans, aby się zorientować, że problem gubionych pakietów jest związany z ich obsługą właśnie na przełączniku.
- Możemy istotnie poprawić działanie sieci poprzez zmianę konfiguracji istniejącego przełącznika zamiast kupowania nowego i droższego modelu.
