I agree with victor. I think llq is the right answer. As per wendell
odom CCIE R & S Guide, LLQ polices the priority queue, allowing just
the traffic that is configured and dropping anything that goes beyond
the configured value.




On Feb 17, 2008 7:05 PM, Derek Winchester <[EMAIL PROTECTED]> wrote:
> Vic,
>   Thanks for waking me up today. I do not know if your test is really
> valid. If you were originating traffic on a host behind router 1 i
> think the results would be different. I have to think it out as I
> don't have access to anything else. But here is a snippet off a white
> paper on cisco.com.
>
> "Both the shape and police commands restrict the output rate to a
> maximum kbps value. Importantly, neither mechanism provides a minimum
> bandwidth guarantee during periods of congestion. Use the bandwidth or
> priority  command to provide such guarantees."
>
> -Derek
>
>
> On 2/17/08, Victor Cappuccio <[EMAIL PROTECTED]> wrote:
> > LLQ when the traffic exceed the configured Priority it gets dropped
> >
> >  R1#conf ter
> >  Enter configuration commands, one per line.  End with CNTL/Z.
> >  R1(config)#access-list 101 permit ip any any pre 3
> >  R1(config)#class-map TEST
> >  R1(config-cmap)#ma access-gr 101
> >  R1(config-cmap)#exit
> >  R1(config)#policy-map TEST
> >  R1(config-pmap)#class TEST
> >  R1(config-pmap-c)#prio 250
> >  R1(config-pmap-c)#exit
> >  R1(config-pmap)#int s1/1
> >  R1(config-if)#serv out TEST
> >  R1(config-if)#do show policy-map int s1/1
> >   Serial1/1
> >
> >    Service-policy output: TEST
> >
> >      Class-map: TEST (match-all)
> >        0 packets, 0 bytes
> >        5 minute offered rate 0 bps, drop rate 0 bps
> >        Match: access-group 101
> >        Queueing
> >          Strict Priority
> >          Output Queue: Conversation 264
> >          Bandwidth 250 (kbps) Burst 6250 (Bytes)
> >          (pkts matched/bytes matched) 0/0
> >          (total drops/bytes drops) 0/0
> >
> >      Class-map: class-default (match-any)
> >        1 packets, 84 bytes
> >        5 minute offered rate 0 bps, drop rate 0 bps
> >        Match: any
> >  R1(config-if)#
> >
> >  R1#ping
> >  Protocol [ip]:
> >  Target IP address: 3.3.3.3
> >  Repeat count [5]: 10
> >  Datagram size [100]: 1000
> >  Timeout in seconds [2]: 0
> >  Extended commands [n]: y
> >  Source address or interface:
> >  Type of service [0]: 0x60
> >  Set DF bit in IP header? [no]:
> >  Validate reply data? [no]:
> >  Data pattern [0xABCD]:
> >  Loose, Strict, Record, Timestamp, Verbose[none]:
> >  Sweep range of sizes [n]:
> >  Type escape sequence to abort.
> >  Sending 10, 1000-byte ICMP Echos to 3.3.3.3, timeout is 0 seconds:
> >  ..........
> >  Success rate is 0 percent (0/10)
> >  R1#show policy-map int s1/1
> >   Serial1/1
> >
> >    Service-policy output: TEST
> >
> >      Class-map: TEST (match-all)
> >        10 packets, 10040 bytes
> >        5 minute offered rate 2000 bps, drop rate 2000 bps
> >        Match: access-group 101
> >        Queueing
> >          Strict Priority
> >          Output Queue: Conversation 264
> >          Bandwidth 250 (kbps) Burst 6250 (Bytes)
> >          (pkts matched/bytes matched) 10/10040
> >          (total rops/bytes drops) 4/4016
> >
> >      Class-map: class-default (match-any)
> >        15 packets, 1092 bytes
> >        5 minute offered rate 0 bps, drop rate 0 bps
> >        Match: any
> >  R1#
> >
> > Thanks
> >
> > --
> > Victor Cappuccio
> > www.vcappuccio.wordpress.com
> >
> >
> > On Feb 18, 2008 12:44 AM, Derek Winchester <[EMAIL PROTECTED]>
> > wrote:
> > > In regards to llq I believe that it wont limit but guarantee the
> > > bandwidth so you can spike above the configured amount if available.
> > >
> > >
> > >
> > >
> > > On 2/17/08, Victor Cappuccio <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi Derek,
> > > >
> > > > I heard this question before, I would agree on your answer, but what
> > about
> > > > also using, LLQ within a CBWFQ, in addition of that priority queue is
> > > > serviced with a strict priority scheduler in which I do not see any ,
> > and in
> > > > the event of congestion, if the priority queue traffic exceeds the
> > bandwidth
> > > > guarantee, a congestion-aware policer is used to drop the exceeding
> > traffic.
> > > >
> > > > Just a thought
> > > > Thank
> > > >
> > > > --
> > > > Victor Cappuccio
> > > > www.vcappuccio.wordpress.com
> > > >
> > > >
> > > > On Feb 18, 2008 12:23 AM, Derek Winchester
> > <[EMAIL PROTECTED]>
> > > > wrote:
> > > > > Someone asked me a very good question yesterday and I am still
> > > > > confused if I gave him the correct answer. He gave me a scenario that
> > > > > states that he has to limit all IP Precedence 3 traffic out of an
> > > > > interface to 256k, but he cannot use policing or rate-limiting. My
> > > > > answer was to use shaping. But from my experience, doesn't the word
> > > > > "limit" negates that as a possible answer? Even though you can use
> > > > > shaping to limit, I was always under the impression when studying for
> > > > > the CCIE that if they use the word limit that means no shaping. Can
> > > > > someone help ease my conscience?
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Derek S. Winchester
> > > www.myprofessorvoip.com
> > > www.winchester1.com
> > > www.derekspeaks.org
> > >
> >
> >
> >
> >
> >
>
>
> --
>
> Derek S. Winchester
> www.myprofessorvoip.com
> www.winchester1.com
> www.derekspeaks.org
>

Reply via email to