QoS jak o tym myśleć w kontekście L2 i L3 Piotr Wojciechowski (CCIE #25543) Architekt Rozwiązań Sieciowych Kraków, 28 września 2011
O mnie Architekt Rozwiązań ds. Sieci w ATM Systemy Informatyczne CCIE #25543 (Routing&Switching) Operator NOC a ATMAN -> inżynier w dziale integracji ATM -> konsultant i architekt w ATM SI Główni klienci: ISP, Mobile, Enterprise Administrator forum CCIE.PL CCIE Playground http://ccieplayground.wordpress.com 2
Agenda Ewolucja modelu QoS Architektura sprzętowa a przepływ danych przez urządzenie i możliwości konfigurowania polityk Zaufanie znacznikom i remarkowanie Kolejki sprzętowe i software owe i zapobieganie przepełnieniom kolejek Dobre zasady tworzenia polityk QoS 3
QoS sukces wdrożenia Odpowiednia ochrona transmisji Voice i Video Ochrona krytycznych aplikacji i protokołów routingu Spełnienie oczekiwań użytkownika końcowego Optymalne wykorzystanie posiadanych zasobów Stworzenie elastycznej konfiguracji Uwarunkowania specyficzne dla prowadzonego biznesu 4
QoS problemy, z którymi musimy się zmierzyć Opóźnienia Jitter Zapewnienie spełnienia SLA kontraktów Poprawne działanie usług (VoIP, IPTV, dostęp do Internetu) Zaawansowane wymagania użytkowników (przenoszenie markerów, QoS Hierarchiczny) Odpowiedź na problemy i nie zawsze słuszne z naszego punktu widzenia narzekania użytkowników 5
QoS wymagania współczesne Różne aplikacje różne wymagania Określenie strategicznych celów biznesowych wdrożenia QoS w sieci Analiza wymagań dla ruchu w określonych klasach i usługach Projektowanie i testowanie polityk QoS Wdrożenie i zarządzanie politykami QoS to nie jednorazowe zadanie a ciągły proces 6
Ewolucja modelu QoS 7
Miejsce aplikacji polityk Port-based QoS Polityka aplikowana jest bezpośrednio na fizycznym interfejsie Odnosi się do całości ruchu obsługiwanego przez interfejs VLAN-base QoS Polityka odnosi się do całości ruchu w obrębie VLANu niezależnie od portów do niego przypisanych Aktywowana jest na logicznym interfejsie 8
Miejsce aplikacji polityk Per-Port/per-VLAN-based QoS Polityka nakładana na port działający w trybie trunk Działa na ruch z określonego VLANu przesyłanego na danym porcie 9
Dobre zasady projektowania QoS Zawsze wykonuj QoS w hardware Klasyfikacja i markowanie powinna odbywać się możliwie najbliżej źródła kryterium techniczne i polityczne Używaj DSCP wszędzie gdzie jest to możliwe Wdrażaj policery dla śmieciowego ruchu możliwie najbliżej źródła Włącz kolejkowanie na każdym węźle, gdzie potencjalnie mogą powstać zatory Stosuj spójną politykę w L2 i L3 we wszystkich fragmentach sieci Zabezpieczaj zarówno control plane jak i data plane 10
Flow danych Wiele czynności do wykonania dla ruchu przychodzącego i wychodzącego Sposób przepływu danych oraz miejsce wykonywania czynności (kolejkowanie, policing, shaping) zależy od modelu urządzenia 11
Flow danych 12
QoS a możliwości hardware Bardzo wiele zależności między wspieranymi mechanizmami QoS a hardware routerów i switchy. Przykłady: Cisco 12000 Engine 4 i 4+ nie wspierają klasyfikacji po DSCP w kierunku egress oraz przy kryterium więcej niż jednego parametru. Engine 3 i 5 nie mają takich ograniczeń. Różne typy kart liniowych dla ASR9000 13
QoS a możliwości hardware Ograniczenia Three-Color-Marker dla Juniperów: 14
Layer 2 QoS CoS (Class of Service) 3 bity zaszyte w nagłówku otagowanej ramki (IEEE 802.1Q lub ISL) Tracimy je gdy zmienia się medium transmisyjne 15
Layer 3 QoS RFC 791-7 bitów (3 bity IP Precedence i 4 bity Type of Service) DiffServ 6 bitów DSCP (Differentiated Services Code Point) i 2 bity ECN (Explicit Congestion Notification) 16
Layer 3 QoS 17
DSCP/IPP/ToS 18
Klasyfikacja ruchu Metody klasyfikacji pakietów do poszczególnych kolejek (przykłady): ACLki na podstawie danych zawartych w nagłówkach IP, TCP i UDP Na podstawie już naniesionych znaczników Port, na którym dane zostały odebrane VLAN, z którego dane pochodzą Rozmiar pakietu Zaawansowane protokoły rozróżniające aplikacje (np. Cisco NBAR) 19
Kryteria zaufania znacznikom Wyznaczamy granice podjęcia decyzji, czy ufamy nałożonym markerom Czy możemy przenieść znaczniki klienta przez naszą sieć Czy na zarządzanych przez nas urządzeniach CE będziemy dokonywać remarkowania pakietów Czy musimy wykonać remarkowania na brzegu sieci 20
Zaufanie znacznikom 21
Traffic Policing vs. Traffic Shaping Traffic Policing Działa w kierunku inpu i output Pakiety niespełniające kryterium są odrzucane Dropowanie powoduje tworzenie się retransmisji dla połączeń TCP Policing współdziała z markowaniem i remarkowaniem Traffic shaping Tylko w kierunku output Pakiety niespełniające kryterium są buforowane do czasu wyczerpania buforu Zmniejsza ilość retransmisji dla połączeń TCP Markowanie i remarkowanie nie są wspierane 22
Traffic shaping Historycznie wywodzą się z łączy WANowskich (ATM, FR) gdzie często spotyka się różnicę prędkości Shaper czasowo buforuje nadmiarowe dane (ograniczeniem rozmiar buforów) 23
Remarkowanie ruchu 24
Kolejki sprzętowe Kolejki sprzętowe są zawsze typu FIFO Są niezależne od kolejek software owych Kiedy porcja danych zostanie wysłana kolejna porcja jest pobierana z kolejki sprzętowej bez zużywania zasobów CPU Im krótsza kolejka sprzętowa tym więcej pola do działania oddajemy kolejkom software owym Jedyna rzecz którą możemy konfigurować to rozmiar kolejki sprzętowej 25
Hardware queues Tx-Ring jest ostatnim buforem wyjściowym dla interfejsów 26
Kolejkowanie na wyjściu SRR/WRR/MDRR WRR (Weighted Round Robin) Ruch priorytetowy nie zawłaszczy sobie łącza Wagi (weight) przypisane do każdej z kolejek i określają priorytet ważności danej kolejki W przypadku wysycenia switch musi opróżniać kolejki stosownie do wag (minimalna ilość ramek z każdej z kolejek zostanie wysłana) stosując WRED Wiele odmian i modyfikacji w zależności od urządzenia i vendora 27
Kolejkowanie na wyjściu SRR/WRR/MDRR SRR (Shaped Round Robin) Dwa typy pracy: Shaped Tylko dla kolejek wyjściowych Gwarantuje maksymalne pasmo dla każdej z kolejek i nie pozwala przekroczyć wyznaczonego limitu, nawet gdy łącze jest wolne Shared Dla kolejek wejściowych i wyjściowych Pasmo współdzielone stosownie do skonfigurowanych wag, pasmo jest gwarantowane do pewnego poziomu, ale dane mogą być wysyłane z większą prędkością gdy łącze jest wolne Kolejki priorytetowe, jeżeli zdefiniowane, są obsługiwane w pierwszej kolejności 28
Kolejkowanie na wyjściu SRR/WRR/MDRR MDRR (Modified Deficit Round Robin) Kolejki zwykłe i priorytetowe Kolejki obsługiwane w schemacie round-robin jednorazowo w każdym cyklu Jeżeli z danej kolejki w danym przebiegu zostało wysłanych więcej danych niż wskazywałaby na to waga kolejki to w kolejnym przebiegu zostanie wysłane odpowiednio mniej danych Kolejka priorytetowa może być obsługiwana na dwa sposoby: Strict zawsze gdy dane znajdują się w kolejce priorytetowej są wysyłane może to prowadzić do zagłodzenia innych kolejek Alternate kolejka priorytetowa jest każdorazowo obsługiwana pomiędzy zmianą obsługiwanej kolejki zwykłej 29
Zapobieganie przepełnieniom kolejek WRED/WTD Mechanizmy te zaczynają działać w momencie, gdy kolejki wyjściowe zaczynają się przepełniać Są dopełnieniem mechanizmy kolejkowania i działają na końcu kolejki Mechanizmy te stosuje się zarówno do kolejek na interfejsach jak i kolejek wewnętrznych Najlepiej sprawdzają się dla ruchu TCP, który wykrywając straty automatycznie zwalnia prędkość nadawania 30
Zapobieganie przepełnieniom kolejek WRED/WTD WTD (Weighted Tail Drop) Ustawiony próg dla kolejki, po przekroczeniu którego pakiety są odrzucane WRED (Weighted Random Early Detection) Pakiety są selektywnie usuwane z kolejki i tracone Wybór pakietu do odrzucenia opiera się na zdefiniowanych przez użytkownika wagach, przypisanych do danej kolejki Bazuje na dwóch znacznikach: IP Precedence domyślne działanie, pakiety oznaczone jako IPP1 będą odrzucane częściej niż oznaczone jako IPP 6 DSCP bazuje na parametrach AF, w których w dane grupie istnieją trzy progi prawdopodobieństwa. Pakiety oznaczone jako AF23 będą odrzucane częściej niż AF21. 31
Kolejkowanie sprzętowe 1P3Q8T 1 Priority Queue 3 Queues 8 Thresholds Kolejkowanie per port lub grupa portów zawsze sprawdzać w dokumentacji 32
Tworzenie właściwych polityk ważne zasady 33
Tworzenie właściwych polityk ważne zasady Prawidłowe przypisanie ramek do kolejki na podstawie wartości CoS Switch#show mls qos maps cos-input-q Cos-inputq-threshold map: cos: 0 1 2 3 4 5 6 7 ------------------------------------ queue-threshold: 1-1 1-1 1-1 1-1 1-1 2-1 1-1 1-1 Ważne w szczególności dla kolejek priorytetowych jeżeli zostały zdefiniowane 34
Tworzenie właściwych polityk ważne zasady Prawidłowe przypisanie ramek do kolejki na podstawie wartości DSCP PWO-206#show mls qos maps dscp-input-q Dscp-inputq-threshold map: d1 :d2 0 1 2 3 4 5 6 7 8 9 ------------------------------------------------------------ 0 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 1 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 2 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 3 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 4 : 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 01-01 01-01 5 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 6 : 01-01 01-01 01-01 01-01 Ważne w szczególności dla kolejek priorytetowych jeżeli zostały zdefiniowane 35
Tworzenie właściwych polityk ważne zasady Właściwe przemarkowanie ramek i pakietów, jeżeli nie ufamy wchodzącym danym lub chcemy dokonać zmiany markera Przykład: markowanie wartości DSCP na CoS Switch#show mls qos maps dscp-cos Dscp-cos map: d1 : d2 0 1 2 3 4 5 6 7 8 9 --------------------------------------- 0 : 00 00 00 00 00 00 00 00 01 01 1 : 01 01 01 01 01 01 02 02 02 02 2 : 02 02 02 02 03 03 03 03 03 03 3 : 03 03 04 04 04 04 04 04 04 04 4 : 05 05 05 05 05 05 05 05 06 06 5 : 06 06 06 06 06 06 07 07 07 07 6 : 07 07 07 07 36
Tworzenie właściwych polityk ważne zasady Przykład: zmiana wartości DSCP na wejściu Switch#show mls qos maps dscp-mutation Dscp-dscp mutation map: Default DSCP Mutation Map: d1 : d2 0 1 2 3 4 5 6 7 8 9 --------------------------------------- 0 : 00 01 02 03 04 05 06 07 08 09 1 : 10 11 12 13 14 15 16 17 18 19 2 : 20 21 22 23 24 25 26 27 28 29 3 : 30 31 32 33 34 35 36 37 38 39 4 : 40 41 42 43 44 45 46 47 48 49 5 : 50 51 52 53 54 55 56 57 58 59 6 : 60 61 62 63 37
Zawsze pamiętajmy o zależności od sprzętu Domyślne reguły markowania, remarkowania i obsługi ruchu Zależności między komponentami urządzenia Przepływ danych przez urządzenie i możliwe punkty zatoru Wąskie gardła w systemach multi-chassis 38
DZIĘKUJĘ ZA UWAGĘ 39