Qos na ISR dla Voice

[drake]

Hej
krisiasty wyjasnil tak ze lepiej sie nie da - generalnie tak jest w 99,9% przypadkow - czy to SDSL czy ADSL, rozne sa pasma i czesto firmy nie dostaja 100M lacza zeby pasowalo do predkosci interfejsu routera
Stad nalezy stosowac shaping, a nie policing - o ciecie ruchu (policing) martwi sie raczej provider, o ile w ogole.... (widzialem lacza 10M na umowie a latajace 100M....)
Tez mam w firmie dla lacza 10M i smiga wysmienicie, przy czym ciekawostka - np. gdy provider gwarantuje 80% lacza "zawsze", to shaping robi sie do tych 8MB, a reszte ewent. jako burst. Bez LLQ jitter byl na poziomie 11, po skonfigurowaniu QoS w LAN i dodatkowo LLQ + shaping na WAN jitter spadl do 0-1. Dodatkowo zero pakietow RxLOSS, czyli tak jak powinno byc.

Pozdrawiam!!

[Deidara]

nie zrozumieliśmy się chyba. załóżmy że masz łącze symetryczne 4Mbps podpięte przez fastethernet i na tym łączu chcesz puszczać ruch voice, korporacyjny oraz internet.
robisz nadrzędną politykę w której dajesz shaping do 4Mbps (dla class-default) oraz obsługę kolejki zgodnie z podrzędną polityką w której definiujesz sobie LLQ dla voice-a, jakąś rezerwację dla ruchu korporacyjnego a reszta (class-default) zostaje dla ruchu do internetu. dopóki ruch sumaryczny nie przekroczy 4Mbps shaping się wogóle nie aktywuje, a jak przekroczysz - zaczyna się kolejkowanie z tym że LLQ zapewni ci priorytetową obsługę ruchu voice.

nie mam pod ręką routera żeby kawałek konfiga pokazać, ale na cisco.com znajdziesz pewnie trochę przykładów.

mam taką konfigurację zaimplementowaną w firmie i działa perfekcyjnie.

To nie jest coś, co nie jest mi znane. Nie przeczytałeś tego co napisałem. Shaping szkodzi. Taki szablon jak opisałeś jest w książce Oddoma, tylko on go nigdy do voice nie zastosował. Przechwalanie się na temat co kto gdzie wdrożył nie ma sensu dla tej dyskusji.
Jeżeli aktywuje się shaping wzrosną opóźnienia, a chodzi o to aby ruch voice był nie do ruszenia. Ma mieć zawsze priorytet i nie ma prawa być blokowany przez inny ruch. Jeśli planuje się QoS z głową to trzeba przewidzieć ile ruchu voice będzie, a to co mogłoby ten ruch zakłócić (cała reszta) należy ograniczyć.

Zresztą róbta co chceta . Nikogo do niczego namawiać nie będę bo mi się nie chce. Miłego dnia .

[Slomek.]

Przechwalanie się na temat co kto gdzie wdrożył nie ma sensu dla tej dyskusji.

IMO trochę nie fair ponieważ to własnie osoby które coś wdrożyły mają własnie coś do powiedzenia a nie ci co bazują na ksiazce Odoma czy kawałkach konfiguracji z DOCDC i coś im się wydaje. Jeśli ktoś ma doświadczenie i napisał, że rozwiąznie takie a takie wdrozył i działa to jak najbardizej jest to istotne i uczące.

[Deidara]

IMO trochę nie fair ponieważ to własnie osoby które coś wdrożyły mają własnie coś do powiedzenia a nie ci co bazują na ksiazce Odoma czy kawałkach konfiguracji z DOCDC i coś im się wydaje. Jeśli ktoś ma doświadczenie i napisał, że rozwiąznie takie a takie wdrozył i działa to jak najbardizej jest to istotne i uczące.

Why so serious .
Nio ale mi się wydaje . Po za tym życie jest nie fair .

[krisiasty]

Shaping szkodzi.

nie generalizuj. nie mówimy tu o samym shapingu.

Taki szablon jak opisałeś jest w książce Oddoma, tylko on go nigdy do voice nie zastosował.

i niby czego ma to dowodzić?

Przechwalanie się na temat co kto gdzie wdrożył nie ma sensu dla tej dyskusji.

nie przechwalam się, tylko dzielę się wiedzą sprawdzoną w praktyce. jeśli masz wątpliwości zawsze możesz sam to wdrożyć i przetestować.

Jeżeli aktywuje się shaping wzrosną opóźnienia, a chodzi o to aby ruch voice był nie do ruszenia. Ma mieć zawsze priorytet i nie ma prawa być blokowany przez inny ruch. Jeśli planuje się QoS z głową to trzeba przewidzieć ile ruchu voice będzie, a to co mogłoby ten ruch zakłócić (cała reszta) należy ograniczyć.

przeczytaj jeszcze raz to co napisałem i zastanów się DOKŁADNIE jak i kiedy zadziała shaping i kolejkowanie w opisywanej sytuacji.
shaping powoduje KOLEJKOWANIE pakietów tylko wtedy, gdy ruch sumaryczny jest większy niż dozwolony. normalnie, kiedy chodzi o sam shaping, jest tylko jedna kolejka obsługiwana wg algorytmu fifo lub wfq, ale tutaj mamy LLQ które GWARANTUJE priorytetową obsługę pakietów voice (w ramach określonego limutu). dlatego taka konfiguracja nie powoduje opóźniania ani pakietów voice. czy teraz już rozumiesz?

[ambde]

a mialo byc wszystko "auto" ;P

Spróbuj na interfejsie wydac komende auto discovery qos. Dobrze by bylo aby bylo troche standardowego ruchu na routerze aby mial on na podstawie czego zaplanowac odpowiednio QOS. Nalezalo by poczekac x minut aby router zebral sobie statyki (wiadomo im dluzszy pomiar tym probka bardziej statystyczna).

Co router sobie wymyslił mozna zobaczyc wydajac polecenie show auto discovery qos. Jesli chcemy aby router wdrozyl poponowany przez niego QOS wydajemy komende auto qos na interfejsie.

[Deidara]

przeczytaj jeszcze raz to co napisałem i zastanów się DOKŁADNIE jak i kiedy zadziała shaping i kolejkowanie w opisywanej sytuacji.
shaping powoduje KOLEJKOWANIE pakietów tylko wtedy, gdy ruch sumaryczny jest większy niż dozwolony. normalnie, kiedy chodzi o sam shaping, jest tylko jedna kolejka obsługiwana wg algorytmu fifo lub wfq, ale tutaj mamy LLQ które GWARANTUJE priorytetową obsługę pakietów voice (w ramach określonego limutu). dlatego taka konfiguracja nie powoduje opóźniania ani pakietów voice. czy teraz już rozumiesz?

O rany rozumiem, że masz na myśli zagnieżdżoną policemapę z LLQ w Shaping. Jeżeli transmisja na interfejsie sięgnie wartości ustawionej shapingu zaczyna się buforowanie pakietów. Zgodzisz się ze mną że coś co jest buforowane nie jest wysyłane w czasie rzeczywistym, tylko z opóźnieniem. Jeżeli bufor się przepełni nastąpi utrata pakietów, również tych voice. LLQ porusza się w obrębie shapingu, w związku z tym fajnie, że pakiety voice z bufora będą miały pierwszeństwo (jeśli w ogóle będą miały), ale to nie zmienia faktu że będą podlegać opóźnieniu. Rozpatruje tutaj skrajny przypadek kiedy zaskoczy shaping. Nie rozważam tego co się dzieje kiedy on nie jest zmuszony do działania bo wtedy nie ma takiego zagrożenia.
Jeśli to działa w inny sposób to opisz w jaki. Chętnie się czegoś nauczę.

Dla mnie nie jest ważne czy coś działa czy nie tylko czy działa poprawnie. Moim zdaniem w przykładzie, który podałeś w skrajnym przypadku może posypać się voice. To wszystko.
Nigdzie nie napisałem, że twierdzę coś kategorycznie tak jak niektórzy przedmówcy. Bierze się to z tego że część mechanizmów działania QoS nigdy nie została upubliczniona w związku z tym pewności mieć nie mogę, ale nie wynika to na pewno z braku wiedzy......

Chyba .

Więc drogi kolego nie irytuj się. Ja też znam z wdrożenia przykład, który podałem wcześniej i też wiem że bardzo dobrze działa, ale nigdy nie powiem że coś wiem na 100%, bo praca z Cisco zaskakuje mnie na każdym kroku.

[krisiasty]

O rany rozumiem, że masz na myśli zagnieżdżoną policemapę z LLQ w Shaping. Jeżeli transmisja na interfejsie sięgnie wartości ustawionej shapingu zaczyna się buforowanie pakietów.

kolejkowanie...

Zgodzisz się ze mną że coś co jest buforowane nie jest wysyłane w czasie rzeczywistym, tylko z opóźnieniem.

ile wg ciebie wynosi opóźnienie dla pierwszego obsługiwanego pakietu z kolejki?

Jeżeli bufor się przepełni nastąpi utrata pakietów, również tych voice.

nie używaj proszę słowa "bufor". hierarhiczna polityka która robi shaping (llq + cbwfq) tworzy kilka kolejek o sumarycznej przepływności określonej przez parametry shapera, z czego jedna z nich jest kolejką priorytetową. utrata pakietów voice może wystąpić jedynie w przypadku kiedy pakiety te przekroczą pasmo gwarantowane w kolejce priorytetowej (które oczywiście musi być mniejsze niż pasmo całkowite określone dla shapera).

Jeśli to działa w inny sposób to opisz w jaki. Chętnie się czegoś nauczę.

już prościej nie potrafię tego napisać. jeśli nadal masz wątpliwości odsyłam do literetury. pomocne może być także rozrysowanie sobie zawartości kolejek w funkcji czasu w zależności od typu i prędkości przesyłanych pakietów i zastanowienie się które pakiety, z jakiej kolejki i kiedy zostaną wyemitowane na interfejs wyjściowy.

Dla mnie nie jest ważne czy coś działa czy nie tylko czy działa poprawnie. Moim zdaniem w przykładzie, który podałeś w skrajnym przypadku może posypać się voice. To wszystko.

ok, opisz w takim razie jaki to przypadek?

[Deidara]

kolejkowanie...

Hmm LLQ ma kolejkę, tak zwany "pozostały ruch ma kolejkę" (cbwfq), a ja mówię o buforze shapingu. Bufor to nie jest zła nazwa bo, jeśli zajrzysz sobie do dokumentacji Cisco, to jest stosowana w odniesieniu do shapingu zamiennie z kolejkowaniem. Jest takie cuś co się zwie "shaping buffer".

ile wg ciebie wynosi opóźnienie dla pierwszego obsługiwanego pakietu z kolejki?

Ty mówisz prawdopodobnie o wyciągnięciu czegoś z kolejki LLQ, a ja mówię wyciągnięciu czegoś z "bufora" shapingu w momencie kiedy pakiety muszą być "buforowane" bo transmisja jest większa niż skonfigurowany shaping. Ile wnosi to zależy od jego głębokości, zapełnienia, wielkości przesyłanych pakietów i czasu trwania ruchu ponad prędkość ustawioną dla shaping.
Jeżeli stosuje się shaping a następnie umieszcza się w nim CBWFQ z opcją LLQ to kolejność przejścia pakietu jest taka:
pakiet -> Shaper -> CBWFQ z opcją LLQ.
W przypadku głosu nie powinno się też zapominać o "wielkości" okna Tc w przypadku użycia shapingu.

hierarhiczna polityka która robi shaping (llq + cbwfq) tworzy kilka kolejek o sumarycznej przepływności określonej przez parametry shapera, z czego jedna z nich jest kolejką priorytetową. utrata pakietów voice może wystąpić jedynie w przypadku kiedy pakiety te przekroczą pasmo gwarantowane w kolejce priorytetowej (które oczywiście musi być mniejsze niż pasmo całkowite określone dla shapera).

No dobrze. Rozpatrzmy taki przypadek. Mamy Shaper 256Kb, a w nim mamy police-map Voice, klasę Glosik z LLQ która ma 64Kb oraz klasę default na pozostały ruch. Router otrzymuje 2Mb nie-"voicowego" ruchu przez 5 minut. W między czasie po 2 minutach klient decyduje się wykonać telefon przy użyciu IP Phone. Zakładamy że max-reserved-bandwidth jest 100. Bandwidth na interfejsie 256Kb. A sam interfejs powiedzmy FE.
Pytania:
1. Gdzie powędrują pakiety nadmiarowe z przesyłane przez pierwsze 2 minuty. Co dokładnie się z nimi stanie? Jak się zachowa Shaper w przypadku nadmiaru?
2. Co się stanie gdy klient zdecyduje się zadzwonić. W jaki sposób pakiet powędruje.

I proszę nie odsyłaj mnie do literatury, bo równie dobrze ja mógłbym powiedzieć, abyś podparł to co piszesz czymś więcej.

[krisiasty]

Hmm LLQ ma kolejkę, tak zwany "pozostały ruch ma kolejkę" (cbwfq), a ja mówię o buforze shapingu. Bufor to nie jest zła nazwa bo, jeśli zajrzysz sobie do dokumentacji Cisco, to jest stosowana w odniesieniu do shapingu zamiennie z kolejkowaniem. Jest takie cuś co się zwie "shaping buffer".

imho termin kolejka jest zdecydowanie bardziej precyzyjny, ale jak chcesz - załóżmy że bufor i kolejka to to samo.
zastanów się teraz z czego składa się taki bufor/kolejka w przypadku omawianej polityki qos: z dwóch lub więcej buforów/kolejek, w tym jedna priorytetowa. dla uproszczenia powiedzmy że mamy tylko dwie klasy ruchu - voice i reszta (class-default).

Ty mówisz prawdopodobnie o wyciągnięciu czegoś z kolejki LLQ, a ja mówię wyciągnięciu czegoś z "bufora" shapingu w momencie kiedy pakiety muszą być "buforowane" bo transmisja jest większa niż skonfigurowany shaping. Ile wnosi to zależy od jego głębokości, zapełnienia, wielkości przesyłanych pakietów i czasu trwania ruchu ponad prędkość ustawioną dla shaping.

byłoby tak jak opisujesz gdyby był tylko shaping z jedną kolejką/buforem. ale jest kilka kolejek i jeśli przychodzący pakiet musi być zakolejkowany, to trafia od razu do właściwej kolejki - jeśli jest to voice to trafia do LLQ. teraz jeśli w kolejnej jednostce czasu trzeba wysłać kolejny pakiet, to shaper NAJPIERW będzie pobierał pakiety z kolejki LLQ.

Jeżeli stosuje się shaping a następnie umieszcza się w nim CBWFQ z opcją LLQ to kolejność przejścia pakietu jest taka:
pakiet -> Shaper -> CBWFQ z opcją LLQ.
W przypadku głosu nie powinno się też zapominać o "wielkości" okna Tc w przypadku użycia shapingu.

prawda, ale musisz pamiętać że w tym przypadku nie ma dodatkowego bufora/kolejki dla shapera - są tylko bufory/kolejki dla LLQ i pozostałych klas które są opróżniane z prękością kontrolowaną przez shaper. twoje wątpliwości wynikają prawdopodobnie z tego, że wydaje ci się iż shaper ma swój osobny bufor i wtedy faktycznie cała ta konstrukcja nie miałaby w sensu, bo pakiety voice byłyby podwójnie kolejkowane.

zgadzamy się co do tego?

[Deidara]

prawda, ale musisz pamiętać że w tym przypadku nie ma dodatkowego bufora/kolejki dla shapera - są tylko bufory/kolejki dla LLQ i pozostałych klas które są opróżniane z prękością kontrolowaną przez shaper. twoje wątpliwości wynikają prawdopodobnie z tego, że wydaje ci się iż shaper ma swój osobny bufor i wtedy faktycznie cała ta konstrukcja nie miałaby w sensu, bo pakiety voice byłyby podwójnie kolejkowane.

zgadzamy się co do tego?

No mniej więcej to miałem na myśli .
Może nie tyle że coś jest podwójnie kolejkowane tylko cały ruch przechodzi najpierw przez Shaper, który ma CIR w naszym wypadku 256Kb. W uproszczeniu jeżeli ruch jest >256Kb przechodzi przez Shaper i wpada do kolejek priorytetowej w przypadku voice lub innej przypadku ruchu pozostałego (tak naprawdę Cisco nigdy nie opublikowało mechanizmów z CBWFQ tylko WFQ więc trudno powiedzieć jak to wygląda w środku). I jest zarządzany z poziomu CBWFQ z LLQ.
Natomiast jeśli ruch jest <256Kb następuje "aktywacja" Shapera. Nadmiar niezależnie czy jest to voice czy zwykłe dane jest kolejkowany w "shaper buffer". Z defaulta ma z tego co pamiętam pojemność 2048 pakietów. Nadmiar według mnie buforuje/kolejkuje się "shaper buffer" i stąd jest wrzucany w kolejki CBWFQ z LLQ. Ponieważ Shaper nie ma możliwości rozpoznania czy pakiet jest voice czy nie to traktuje wszystkie przy użyciu FIFO przy opróżnianiu bufora/kolejki.

I rzeczywiście to budzi moje wątpliwości ponieważ sam Shaper działa poprzez buforowanie/kolejkowanie nadmiaru ruchu. Jeśli ruch jest na tyle duży i trwa na tyle długo żeby wypełnić swój bufor/kolejkę następuje drop. Natomiast jeśli nie to pakiety z bufora/kolejki słane są z opóźnieniem tak aby sprostać wymaganiom shapera. Myślę że co do tego nie ma wątpliwości?

I dokładnie tutaj jest moja wątpliwość. Skoro sam shaper wykorzystuje bufor/kolejkę to czemu miałby go nie wykorzystywać w przypadku kiedy zagnieździmy w nim CBWFQ z LLQ. Być może jest tak jak mówisz, ale nigdzie niestety nie spotkałem się z opisem takiego działania. Widziałem na GroupStudy dyskusję na ten temat, ale wnioski były podobne do moich. Jeśli jest prawdą to co napisałeś to rzeczywiście działanie tego "mixa" byłoby dla mnie zaskoczeniem.

[krisiasty]

Może nie tyle że coś jest podwójnie kolejkowane tylko cały ruch przechodzi najpierw przez Shaper, który ma CIR w naszym wypadku 256Kb. W uproszczeniu jeżeli ruch jest >256Kb przechodzi przez Shaper i wpada do kolejek priorytetowej w przypadku voice lub innej przypadku ruchu pozostałego (tak naprawdę Cisco nigdy nie opublikowało mechanizmów z CBWFQ tylko WFQ więc trudno powiedzieć jak to wygląda w środku). I jest zarządzany z poziomu CBWFQ z LLQ.
Natomiast jeśli ruch jest <256Kb następuje "aktywacja" Shapera. Nadmiar niezależnie czy jest to voice czy zwykłe dane jest kolejkowany w "shaper buffer". Z defaulta ma z tego co pamiętam pojemność 2048 pakietów. Nadmiar według mnie buforuje/kolejkuje się "shaper buffer" i stąd jest wrzucany w kolejki CBWFQ z LLQ. Ponieważ Shaper nie ma możliwości rozpoznania czy pakiet jest voice czy nie to traktuje wszystkie przy użyciu FIFO przy opróżnianiu bufora/kolejki.

wymyślasz jakieś cuda. jest tak jak opisałem - jeśli ruch sumaryczny jest mniejszy niż limit shapera, to wogóle nie jest kolejkowany, jeśli zaś większy - wpada do odpowiedniej kolejki (voice do llq, reszta do innych zdefiniowanych lub do class-default). kolejki są opróżniane z prędkością regulowaną przez shaper z zachowaniem priorytetu dla llq.
czyli de-facto shaper nie ma własnej kolejki tylko reguluje prędkość opróżniana kolejek zdefiniowanych w podklasach.

Być może jest tak jak mówisz, ale nigdzie niestety nie spotkałem się z opisem takiego działania.

zajrzyj np. tu: link i tu: link

drugi z linków zawiera m.in. opis działania shapera w hierarchicznej polityce.

[Deidara]

wymyślasz jakieś cuda. jest tak jak opisałem - jeśli ruch sumaryczny jest mniejszy niż limit shapera, to wogóle nie jest kolejkowany, jeśli zaś większy - wpada do odpowiedniej kolejki (voice do llq, reszta do innych zdefiniowanych lub do class-default). kolejki są opróżniane z prędkością regulowaną przez shaper z zachowaniem priorytetu dla llq.
czyli de-facto shaper nie ma własnej kolejki tylko reguluje prędkość opróżniana kolejek zdefiniowanych w podklasach.

Bardzo możliwe . Znam ten drugi link ale z niego nie wynika wprost, że nie ma takiej kolejki. Nie zamierzam się też upierać przy swoim .
Nie mniej na wszelki wypadek sprawdziłem jak się zachowuje konfiguracja o której wspomniałem, wcześniej. Umieściłem poniżej wynik po aktywacji shaping. Jak widać bufor/kolejka dla shapera istnieje i ma się dobrze. Zapełnia (Queue Depth) się też powodując wysłanie pakietów z opóźnieniem (Packets Delayed).

Kod: Zaznacz cały

R1#sh policy-map int f2/0
 FastEthernet2/0 

  Service-policy output: SHAPER

    Class-map: class-default (match-any)
      19559 packets, 24440971 bytes
      30 second offered rate 115000 bps, drop rate 0 bps
      Match: any 
      Traffic Shaping
           Target/Average   Byte   Sustain   Excess    Interval  Increment
             Rate           Limit  bits/int  bits/int  (ms)      (bytes)  
           256000/256000    1984   7936      7936      31        992      

        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping
        Active Depth                         Delayed   Delayed   Active
        -      8         19511     24373335  15247     19933554  yes

      Service-policy : GLOSIK

        Class-map: VOICE (match-all)
          2414 packets, 286056 bytes
          30 second offered rate 1000 bps, drop rate 0 bps
          Match: access-group 100
          Queueing
            Strict Priority
            Output Queue: Conversation 40 
            Bandwidth 64 (kbps) Burst 1600 (Bytes)
            (pkts matched/bytes matched) 1570/190460
            (total drops/bytes drops) 40/56760

        Class-map: DATA (match-all)
          16474 packets, 24087064 bytes
          30 second offered rate 112000 bps, drop rate 0 bps
          Match: access-group 101
          Queueing
            Output Queue: Conversation 41 
            Bandwidth remaining 90 (%) Max Threshold 64 (packets)
            (pkts matched/bytes matched) 13683/19863546
        (depth/total drops/no-buffer drops) 0/0/0

        Class-map: class-default (match-any)
          671 packets, 67851 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match: any 

[drake]

Hej,

rozdzielmy dyskusje nieco - kwestia co i jak dziala to jedno, a srodowisko produkcyjne i rozwiazanie potrzebne koledze i dzialajace dla VoIP to druga sprawa. Na blogu IE niedawno Petr swietnie wyjasnil tajniki CBWFQ, choc to prawda ze Cisco nigdy nie opublikowalo dokladnych algorytmow dzialania mechanizmow QoS.

@ Deidara - weryfikacja i wynik twojego show faktycznie pokazuje ze tak zagniezdzona policy-map bedzie rowniez opozniala pakiety voip - co sie zgadza, bo jest wewnatrz shapera (zagniezdzenie). Wszytsko oczywiscie jest kwestia implementacji - zeby LLQ poprawnie dzialalo (ZERO dropowanych i opoznianych pakietow dla ruchu z "priority"), nalezy uzywac shapingu dla class-default, zawsze takie konfiguracje w srodowiskach produkcyjnych widzialem i sprawuja sie swietnie. Przyklad:

Kod: Zaznacz cały

class-map match-any VOICE-SIGNALING
 match ip dscp af31
 match ip dscp cs3
class-map match-any VOICE-BEARER
 match ip dscp ef
 match ip dscp cs5
!
policy-map SHAPING
 class VOICE-BEARER
    priority 1920
 class VOICE-SIGNALING
    bandwidth percent 10
 class class-default
    fair-queue
    shape average 8000000

Dziala sobie juz jakis czas produkcyjnie:

Kod: Zaznacz cały

rtr#show policy-map int fa4
 FastEthernet4

  Service-policy output: SHAPING

    queue stats for all priority classes:
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 702357/150304398

    Class-map: VOICE-BEARER (match-any)
      702357 packets, 150304398 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: ip dscp ef (46)
        702357 packets, 150304398 bytes
        30 second rate 0 bps
      Match: ip dscp cs5 (40)
        0 packets, 0 bytes
        30 second rate 0 bps
      Priority: 1920 kbps, burst bytes 48000, b/w exceed drops: 0


    Class-map: VOICE-SIGNALING (match-any)
      0 packets, 0 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: ip dscp af31 (26)
        0 packets, 0 bytes
        30 second rate 0 bps
      Match: ip dscp cs3 (24)
        0 packets, 0 bytes
        30 second rate 0 bps
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 0/0
      bandwidth 10% (800 kbps)

    Class-map: class-default (match-any)
      12098026 packets, 8184815128 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops/flowdrops) 0/108461/0/108461
      (pkts output/bytes output) 11989564/8041780581
      Fair-queue: per-flow queue limit 16
      shape (average) cir 8000000, bc 32000, be 32000
      target shape rate 8000000

Wydaje mi sie ze wlasnie takie rozwiazanie kolega potrzebuje. W miare potrzeb mozna zapakowac dodatkowe klasy dla ruchu np. citrix etc....

Ogolnie to specjalista od QoS nie jestem, aczkolwiek planuje tu sie poprawic, czekam z niecierpliowscia na niebawem juz majacy sie ukazac workbook 1 v5 w wersji finalnej IE (czesc sekcji QoS dostepna na blogu IE), bo jak wszyscy nadmienialiscie - rzeczywiscie Cisco niezbyt dokladnie/wiele wyjasnia w dokumentacji.

Pozdrawiam!

[Deidara]

Kod: Zaznacz cały

class-map match-any VOICE-SIGNALING
 match ip dscp af31
 match ip dscp cs3
class-map match-any VOICE-BEARER
 match ip dscp ef
 match ip dscp cs5
!
policy-map SHAPING
 class VOICE-BEARER
    priority 1920
 class VOICE-SIGNALING
    bandwidth percent 10
 class class-default
    fair-queue
    shape average 8000000

Do takiego rozwiązania nie mam większych zastrzeżeń . Najlepiej jest wyliczyć ilość ruchu potrzebną dla voice, a następnie na defaulta założyć shaper pomniejszony o tą wartość. Wtedy zawsze będzie pasmo dla Voice i nie będzie problemu. W takim przypadku Shaper jak najbardziej może być. Moje uwagi odnosiły się do zamykania ruchu voice w shaperze. Tutaj tak nie jest.

Ogolnie to specjalista od QoS nie jestem, aczkolwiek planuje tu sie poprawic, czekam z niecierpliowscia na niebawem juz majacy sie ukazac workbook 1 v5 w wersji finalnej IE (czesc sekcji QoS dostepna na blogu IE), bo jak wszyscy nadmienialiscie - rzeczywiscie Cisco niezbyt dokladnie/wiele wyjasnia w dokumentacji.

Każda dyskusja bardzo uczy i jest potrzebna. QoS to dość złożona działka i wymiana poglądów sprzyja poszerzaniu własnej wiedzy .