QoS – jak o tym myśleć w kontekście L2 i L3 · Sieci w ATM Systemy Informatyczne ! CCIE #25543...

39
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

Transcript of QoS – jak o tym myśleć w kontekście L2 i L3 · Sieci w ATM Systemy Informatyczne ! CCIE #25543...

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

22

¢  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

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

26

Tx-Ring jest ostatnim buforem wyjściowym dla interfejsów

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

35

¢  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

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