FRTS

Wiadomość

manius · #1

zadanie z GS :
R2 is the hub connected to R5 and R7
AR is 128kbps
PVC 205 (R2--R5) has Carrier CIR 64kbps
PVC 207 (R2--R7) has Carrier CIR 64kbps

R2 should detect that one PVC is not using bandwidth and transmit up to AR on the other PVC. For example, if there is no traffic on PVC 205, transmit up to 128kbps on PVC 207.

ciekaw jestem waszych pomyslow

daras9191 · #2

manius mam nadzieje ze tym razem bardziej sie wstrzele z "proba" odpowiedzi

a moze tak

map-class frame-relay PVC205
frame-relay cir 128000 <- bedzie to predkosc fizyczna interface'u
frame-relay bc 1000
frame-relay be 0
frame-relay mincir 64000 <- prawdziwy cir wg wolniejszego konca
frame-relay adaptive-shaping becn <- opcja
! service-policy out <nazwa> <- jesli chcemy dopiac do pvc jakis qos

int s0/0
frame traffic-sh
int ser0/0.205
frame int dlci 205
class PVC205

analogicznie dla pvc 207
bedzie to dzialalo tak jak w pytaniu czyli jak jedno pvc stoi to drugie korzysta z pelnego lacza nalezy tylko pamietac ze jak mamy wiecej pvc to w powyzszy sposob jesli zalozymy t-s tylko na int glowny i jeden z wielu pvc to automatycznie ograniczymy pozostale pvc do cir=56k

pjeter · #3

daras9191 pisze: map-class frame-relay PVC205
frame-relay cir 128000 <- bedzie to predkosc fizyczna interface'u
frame-relay bc 1000
frame-relay be 0
frame-relay mincir 64000 <- prawdziwy cir wg wolniejszego konca
frame-relay adaptive-shaping becn <- opcja

Ejj daras pospieszyles sie...
BC ustawiony na 1000 bitow, daje TC ponizej 10 ms, a min. TC to 10 ms
skusilem sie nawet sprawdzic jak sie zachowa IOS z blednie podanym BC
i musze pochwalic ze jest na to odporny:

--------------
map-class frame-relay fr
frame-relay cir 128000
frame-relay bc 1000
frame-relay be 0
--------------

Kod: Zaznacz cały

Interface   Se0/0
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
102           128000    160    1280      0         10        160       -
104           128000    160    1280      0         10        160       -
113           128000    160    1280      0         10        160       -
103           128000    160    1280      0         10        160       -

Interface   Se0/0.15
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
105           128000    160    1280      0         10        160       -
--------------

Jak juz widzisz z powyzszego max ilosc przedzialow to 100/sek
stosuje sie je jednak tylko w przypadku przesylania voice-a lub duzych predkosci lacza
W przypadku podanym wyzej wystarczy standartowo 8 przedzialow / sek.
ze standartowym TC = 125 ms (tylko dla predkosci < 256kbps !)
Czyli BC = 128000 / 8, badz jak kto woli BC = 128000 * 0.125
=============

Im dluzej nad tym mysle, to zadanie wydaje mi sie mniej proste ;)
Watpie w powyzsza konfiguracje z tego wzgledu ze lacze jest
jedno z AR 128kbps. Natomiast propozycja zaklada 128kbps per PVC.

Raczej w zadaniu chodzi o cos takiego (tworze z pamieci):

Kod: Zaznacz cały

class-map PVC205
 match fr-dlci 205
class-map PVC207
 match fr-dlci 207

policy-map FR
 class class-default
  shape average 128000
  service-policy FRDLCI
policy-map FRDLCI
  class PVC205
   band 64
  class PVC207
   band 64

shape average bedzie potrzebny do aktywowania traffic shapingu (przy mniejszym
ruchu active=no, no chyba ze odniesie sie do bandwidth na interfejsie - hmm, musze to sprawdzic).

Natomiast bandwidth w policy zagwarantuje pasmo, ale takze pozwoli na skorzystanie z calej rury. Policy FR oczywiscie na output.
Z wczesniejszego FRTS bym zrezygnowal zakladajac, ze beda tylko te dwa PVC na multipointowym interfejscie.

Hmm,
lub druga wariacja:

Kod: Zaznacz cały

class-map PVC205
 match fr-dlci 205
class-map PVC207
 match fr-dlci 207

policy-map FR
  class PVC205
   shape peak 128000 8000 8000
   shape adaptive 64000                 ! Jako dodatek - FRTS - nie wymagane w zadaniu
   band 64
  class PVC207
   shape peak 128000 8000 8000
   shape adaptive 64000                 ! Jako dodatek - FRTS - nie wymagane w zadaniu
   band 64

Co wygralem ? ;)

PJ

manius · #4

ooops daras - chyba nie tedy droga

Powody stosowania MinCir wedlug mojej wiedzy:
1. reagowanie na fecn/becn's i obnizanie ruchu do poziomu MinCir
2. ustawienie "reference point" dla rezerwacji CBWFQ/LLQ - domyslnie 1/2 CIR

Ktos zna inne ?

pomijajac bledne Bc

twoje rozwiazanie ma sie tak:
pruj z predkoscia 128kpbs , zjedz do 64kbps w przypadku otrzymania fecn/becn z chmury.
co w porownaniu z zadaniem :
pruj z predkoscia 64kbps , jezeli na drugim pvc nic sie nie dzieje - pruj z predkoscia 128kpbs (tutaj bym pewnie zapytal proktora czy "up to 128kpbs" to ma byc chwilowe - wtedy moim zdaniem Be zalatwialo by sprawe do wyczerpania tokenow , czy tez do momentu pojawienia sie ruchu na tym nieuzywanym pvc)
daje obraz sytuacji, moim zdaniem nie tedy droga - ale fajnie ze odpowiedziales

manius · #5

Dzieki Piotr za odpowiedz

1.

Kod: Zaznacz cały

class-map PVC205 
 match fr-dlci 205 
class-map PVC207 
 match fr-dlci 207 

policy-map FR 
 class class-default 
  shape average 128000 
  service-policy FRDLCI 
policy-map FRDLCI 
  class PVC205 
   band 64 
  class PVC207 
   band 64

z tego co powyzej wnioskuje nastepujaco :
pruj z predkoscia max 128kbps jednakze w przypadku tloku na interf , masz zagwarantowane 64kbps/VC - right ?
jednakze poniewaz rezerwujemy max bandwidth , wypadaloby ustawic moim zdaniem - max-reservable-bandwidth 100 , oraz mincir na 128000
Jak dla mnie to rozwiazanie pasuje najbardziej - any comments ?

2.
tutaj moim zdaniem reagowanie na fecn/becn nie wchodzi w gre bo zadanie mowi ze router ma decydowac na podstawie obciazenia interf , a nie na znaczniki plynace z chmury - nice try though

Oprocz tego shape peak 128000 8000 8000 powoduje ze kazdy z pvc bedzie w kazdym Tc bral Bc+Be ruchu , wiec tak naprawde zrobiloby by sie 256kpbs w shaperze

co przy CIRach 64+64 u ISP daloby niezla kapuste

Co o tym myslisz ?

ja sklanialem sie ku czemus takiemu :

Kod: Zaznacz cały

Map-class frame-relay main_frts
Frame cir 64000
Frame bc  640
Frame be  640

R2 --> interface  s0/0
Frame traffic-shaping
Frame class main_frts

to daloby 64kpbs/VC oraz w momencie posiadania wystarczajacej ilosci tokenow , burst "up to" 128kpbs. Jednakze to byloby chwilowe bo tokeny szybko by sie wyczerpaly - co sadzisz o tym rozwiazaniu ?

pjeter · #6

manius pisze: 1.
Kod: Zaznacz cały
class-map PVC205 
 match fr-dlci 205 
class-map PVC207 
 match fr-dlci 207 

policy-map FR 
 class class-default 
  shape average 128000 
  service-policy FRDLCI 
policy-map FRDLCI 
  class PVC205 
   band 64 
  class PVC207 
   band 64 
z tego co powyzej wnioskuje nastepujaco :
pruj z predkoscia max 128kbps jednakze w przypadku tloku na interf , masz zagwarantowane 64kbps/VC - right ?
jednakze poniewaz rezerwujemy max bandwidth , wypadaloby ustawic moim zdaniem - max-reservable-bandwidth 100 , oraz mincir na 128000
Jak dla mnie to rozwiazanie pasuje najbardziej - any comments ?

Dokladnie tak. Bandwidth zagwarantuje "timesloty" czyli zapewni gwarancje
a w wolnych chwilach pozwla na skorzystanie z calej rury.

Ups - calkowicie sie zgadzam z max-res i mincir - ale AFAIR nie zaloze takiego service-policy
bo bedzie wyskakiwal blad rezerwacji.

2.
tutaj moim zdaniem reagowanie na fecn/becn nie wchodzi w gre bo zadanie mowi ze router ma decydowac na podstawie obciazenia interf , a nie na znaczniki plynace z chmury - nice try though :)

Dokladnie to mnie zastanowilo.
Jeszcze temat... FRTS ;). No ale tutaj pozostaje kwestja
czy to ma byc ciagle 128 czy w peaku.

Oprocz tego shape peak 128000 8000 8000 powoduje ze kazdy z pvc bedzie w kazdym Tc bral Bc+Be ruchu , wiec tak naprawde zrobiloby by sie 256kpbs w shaperze :) co przy CIRach 64+64 u ISP daloby niezla kapuste :)
Co o tym myslisz ?

Grrr no wlasnie. Of coz zamierzeniem autora ;) bylo
shape peak 64000 8000 8000
Co mozna wywnioskowac po BC i BE.

http://tinyurl.com/8rezd
Tak BTW: To ten przyklad z command reference'a jest dosc lipny i przeczy zaprezentowanym wczesniej zalozeniom:
The following example uses peak rate shaping to ensure a bandwidth of 300 kbps but allow throughput up to 512 kbps if enough bandwidth is available on the interface:
bandwidth 300
shape peak 512000

Uwazam ze gdy Be = Bc (default jesli nie podane) wtedy aktualny staly peak bedzie 1024kbps.

ja sklanialem sie ku czemus takiemu :
Kod: Zaznacz cały
Map-class frame-relay main_frts
Frame cir 64000
Frame bc  640
Frame be  640

R2 --> interface  s0/0
Frame traffic-shaping
Frame class main_frts
to daloby 64kpbs/VC oraz w momencie posiadania wystarczajacej ilosci tokenow , burst "up to" 128kpbs. Jednakze to byloby chwilowe bo tokeny szybko by sie wyczerpaly - co sadzisz o tym rozwiazaniu ?

No to jest drugie poprawne rozwiazanie w przypadku gdyby chodzilo o FRTS i chwilowy burst.

PJ

pjeter · #7

manius pisze: Powody stosowania MinCir wedlug mojej wiedzy:
...
2. ustawienie "reference point" dla rezerwacji CBWFQ/LLQ - domyslnie 1/2 CIR

No tutaj bym sie nie zgodzil. (co do tego 1/2 cir'a)
W przypadku robienia gwaracji/shapingu/policeingu na CBWFQ
ustawiasz na poziomie frame'a AFAIK: predkosc lacza = CIR = mincir
(znakomita wiekszosc rozwiazan z IEWB).
Ale znowu dales mi do zastanowienia - dlaczego - pierwsza odpowiedz ktora mi sie nasuwa to taka, ze robiac gwarancje/shaping... itd. na wyzszym poziome - pakiety ktore juz sa prawidlowo skolejkowane nie powinny doswiadczac dodatkowych opoznien tylko zostac od razu zserializowane.
Jesli znasz dokladniejsze wyjasnienie - dawaj.

PJ

manius · #8

Kod: Zaznacz cały

bandwidth 300 
shape peak 512000

no moim zdaniem a i pewnie Odom'a to co pisza o powyzszym to pomylka , zreszta przypiecie tego do int daje target rate 1024000/average rage 1024000 wiec sie rypneli.

co do MinCir'a - IEWB zongluje nim wtedy kiedy granica rezerwacji w klasach przekracza domyslna jego wartosc czyli 1/2 CIR'a - nie moge znalezc doglebnego wyjasnienia mechanizmu jego dzialania ale widac z tego ze jest to dolna wartosc graniczna , gorna oczywiscie jest CIR.

ciekawa sprawa z shape peak.

Kod: Zaznacz cały

 policy-map vc_shape
  class dlci_402
   bandwidth 16
  class dlci_403
   bandwidth 16
 policy-map shape
  class class-default
   shape peak 16000
   service-policy vc_shape

na pierwszy rzut oka powinno byc ok (w kazdym Tc pobierze Bc+Be czyli tak naprawde bedzie prul z predkoscia 32000) jednak dla routera jest to bledna konfiguracja - nie pozwala na dopiecie policy child poniewaz twierdzi ze zarezerwowal juz na pvc 402 16kb i zostalo mu 0

Pytanie do peak'owych GURU's

- czym rozni sie (teoretycznie i praktycznie):
shape average 32000
od
shape peak 32000 8000 0
?

moje testy wykazuja ze ... niczym

ale moze cos moje oczy pomijaja - komentarze mile widziane

BTW2 :piotrek - przetestowalem pierwszy konfig z zadania i dziala bez zarzutu - po prostu pytanie do ojca prowadzacego czy "up to" ma byc chwilowe czy tez ciagle

Thnx - nareszcie cos sie dzieje w tym dziale

pjeter · #9

manius pisze:
ciekawa sprawa z shape peak.
Kod: Zaznacz cały
 policy-map vc_shape
  class dlci_402
   bandwidth 16
  class dlci_403
   bandwidth 16
 policy-map shape
  class class-default
   shape peak 16000
   service-policy vc_shape
na pierwszy rzut oka powinno byc ok (w kazdym Tc pobierze Bc+Be czyli tak naprawde bedzie prul z predkoscia 32000) jednak dla routera jest to bledna konfiguracja - nie pozwala na dopiecie policy child poniewaz twierdzi ze zarezerwowal juz na pvc 402 16kb i zostalo mu 0 :)

Hmm pewnie to dlatego ze Be nie jest gwarantowane, nie ?
BE jako excess - nadmiarowy ... i moze zostac pominiety przez becny na przyklad.
Dobrze mowie ... czy bardzo dobrze ? :)

manius pisze: czym rozni sie (teoretycznie i praktycznie):
shape average 32000
od
shape peak 32000 8000 0
?
moje testy wykazuja ze ... niczym :) ale moze cos moje oczy pomijaja - komentarze mile widziane :)

Mnie sie od razu w oczy rzucilo - moze nie jest to cos super waznego a jednk roznica jest -
- dla average'a nie podales be - defaultowo be = bc wiec:

Kod: Zaznacz cały

Rack3R1(config-pmap-c)#shape average 32000
Rack3R1(config-pmap-c)#do sh poli int e0/0
 Ethernet0/0

  Service-policy output: test2

    Class-map: class-default (match-any)
      162 packets, 47033 bytes
      5 minute offered rate 1000 bps, drop rate 0 bps
      Match: any
      Traffic Shaping
           Target/Average   Byte   Sustain   Excess    Interval  Increment
             Rate           Limit  bits/int  bits/int  (ms)      (bytes)
            32000/32000     2000   8000      8000      250       1000

        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping
        Active Depth                         Delayed   Delayed   Active
        -      0         162       47033     1         60        no
Rack3R1(config-pmap-c)#shape peak 32000 8000 0
Rack3R1(config-pmap-c)#do sh poli int e0/0
 Ethernet0/0

  Service-policy output: test2

    Class-map: class-default (match-any)
      488 packets, 140099 bytes
      5 minute offered rate 1000 bps, drop rate 0 bps
      Match: any
      Traffic Shaping
           Target/Average   Byte   Sustain   Excess    Interval  Increment
             Rate           Limit  bits/int  bits/int  (ms)      (bytes)
            32000/32000     1000   8000      0         250       1000

        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping
        Active Depth                         Delayed   Delayed   Active
        -      0         488       140099    1         60        no

Roznica bedzie w jednym przedziale Tc - dla average'a wypuszczony zostanie dodatkowo Be.

Natomiast podzielam Twoje zdanie ze nie ma roznicy pomiedzy:
shape average 32000 8000 0
a
shape peak 32000 8000 0

Pozdrawiam!
PJ

manius · #10

qrcze, zle klepnalem

oczywiscie chodzilo mi o :
shape average 32000 8000 0
a
shape peak 32000 8000 0

co do shape peak - dobrze prawisz

, co dwie glowy to nie jedna

pozdro

#11

Hej

Specjalnie piszę tutaj żeby nie zakładać nowego wątku
Czytałem tą rozmowę wielokrotnie, wytłumaczenia waszę w niej sa naprawdę świetne ale teraz jak przeczytałem w DoITach wytłumaczenie różnic pomiedzy peak a average to uważam wypowiedź pjetera za niepełną:

Roznica bedzie w jednym przedziale Tc - dla average'a wypuszczony zostanie dodatkowo Be.

dla AVERAGE jest to prawda ale tylko wtedy gdy ilość tokenów Bc z jakiegoś poprzedniego Tc jest pełne

Brak różnic przy takiej konfiguracji:

Kod: Zaznacz cały

shape average 32000 8000 0
a
shape peak 32000 8000 0

---------------------------------------------

Natomiast w takiej już jest:

Kod: Zaznacz cały

shape average 32000 8000 8000
a
shape peak 32000 8000 8000

Różnica taka że dla peak w każdym okresie Tc wyjdzie 16000 a w przypadku average normalnie wyjdzie 8000 chyba że w jakimś poprzednim Tc tokeny w puli Bc nie zostały ruszone a wtedy w kolejnym Tc można wypchnąć 16000 i póxniej w kolejnym znowu 8000

Nie czepiam się oczywiście ale chciałbym się upewnić czy dobrze myślę

CCIE.pl

FRTS

FRTS

odpo?

Re: odpo?