Have a look at the marked up config below.  The config is the result of
running "auto qos voip trust" with just a bit of tweaking afterward.  If
anyone has corrections or comments that would be great.  Hope it helps.

Warren
!
!
mls qos map cos-dscp 0 8 16 26 32 46 48 56  (this maps a COS to DSCP
value)


mls qos srr-queue input bandwidth 90 10    (this is the weighted ratio
not percentage that the queues are serviced to send packets from each
queue)


mls qos srr-queue input threshold 1 8 16   (this is the percentage at
which input/ingress queue 1 will begin tail dropping for thresholds 1
and 2.  Threshold 3 is not configurable and
                                            has a value of 100% assigned
to it so it is not shown)


mls qos srr-queue input threshold 2 34 66   (this is the percentage at
which input/ingress queue 2 will begin tail dropping for thresholds 1
and 2.  Threshold 3 is not configurable and
                                            has a value of 100% assigned
to it so it is not shown)
 
mls qos srr-queue input buffers 67 33     (this is where you define how
the two input/ingress queues will share the buffer space between them
using percentage)


mls qos srr-queue input cos-map queue 1 threshold 2  1   (this is
mapping COS's to either input/ingress queues 1 or 2 and to thresholds
1,2 or 3 where 3 is the highest 
mls qos srr-queue input cos-map queue 1 threshold 3  0    threshhold and
3 has the lowest drop probability)
mls qos srr-queue input cos-map queue 2 threshold 1  2
mls qos srr-queue input cos-map queue 2 threshold 2  4 6 7
mls qos srr-queue input cos-map queue 2 threshold 3  3 5


mls qos srr-queue input dscp-map queue 1 threshold 2  9 10 11 12 13 14
15   (this is mapping DSCP's to either input/ingress queues 1 or 2 and
to thresholds 1,2 or 3 where 3 is the highest
mls qos srr-queue input dscp-map queue 1 threshold 3  0 1 2 3 4 5 6 7
threshold and 3 has the lowest drop probability)
mls qos srr-queue input dscp-map queue 1 threshold 3  32
mls qos srr-queue input dscp-map queue 2 threshold 1  16 17 18 19 20 21
22 23
mls qos srr-queue input dscp-map queue 2 threshold 2  33 34 35 36 37 38
39 48
mls qos srr-queue input dscp-map queue 2 threshold 2  49 50 51 52 53 54
55 56
mls qos srr-queue input dscp-map queue 2 threshold 2  57 58 59 60 61 62
63
mls qos srr-queue input dscp-map queue 2 threshold 3  24 25 26 27 28 29
30 31
mls qos srr-queue input dscp-map queue 2 threshold 3  40 41 42 43 44 45
46 47


mls qos srr-queue output cos-map queue 1 threshold 3  5     (this is
mapping COS's to one of four output/egress queues and to thresholds 1,2
or 3 where 3 is the highest 
mls qos srr-queue output cos-map queue 2 threshold 3  3 6 7  threshhold
and 3 has the lowest drop probability)
mls qos srr-queue output cos-map queue 3 threshold 3  2 4
mls qos srr-queue output cos-map queue 4 threshold 2  1
mls qos srr-queue output cos-map queue 4 threshold 3  0


mls qos srr-queue output dscp-map queue 1 threshold 3  40 41 42 43 44 45
46 47   (this is mapping DSCP's to one of four output/egress queues and
to thresholds 1,2 or 3 where 3 is the highest
mls qos srr-queue output dscp-map queue 2 threshold 3  24 25 26 27 28 29
30 31    threshhold and 3 has the lowest drop probability)
mls qos srr-queue output dscp-map queue 2 threshold 3  48 49 50 51 52 53
54 55
mls qos srr-queue output dscp-map queue 2 threshold 3  56 57 58 59 60 61
62 63
mls qos srr-queue output dscp-map queue 3 threshold 3  16 17 18 19 20 21
22 23
mls qos srr-queue output dscp-map queue 3 threshold 3  32 33 34 35 36 37
38 39
mls qos srr-queue output dscp-map queue 4 threshold 1  8
mls qos srr-queue output dscp-map queue 4 threshold 2  9 10 11 12 13 14
15
mls qos srr-queue output dscp-map queue 4 threshold 3  0 1 2 3 4 5 6 7



mls qos queue-set output 1 threshold 1 138 138 92 138  
mls qos queue-set output 1 threshold 2 138 138 92 400
mls qos queue-set output 1 threshold 3 36 77 100 318
mls qos queue-set output 1 threshold 4 20 50 67 400


mls qos queue-set output 2 threshold 1 149 149 100 149
mls qos queue-set output 2 threshold 2 118 118 100 235
mls qos queue-set output 2 threshold 3 41 68 100 272
mls qos queue-set output 2 threshold 4 42 72 100 242


mls qos queue-set output 1 buffers 10 10 26 54  (this is the percent
amount of buffer space for "queue set 1" allocated to to each of the
four queues
                                                 so in this case the
expedite queue 1 is getting 10%)


mls qos queue-set output 2 buffers 16 6 17 61   (this is the percent
amount of buffer space for "queue set 2" allocated to to each of the
four queues)
                                                 so in this case the
expedite queue 1 is getting 16%)


mls qos   (this turns on qos globally for the switch, but the auto QOS
macro does this)                                          
!
!
no file verify auto
spanning-tree mode pvst
spanning-tree extend system-id
!
vlan internal allocation policy ascending
!
!         
interface GigabitEthernet1/0/1
!
interface GigabitEthernet1/0/2
 srr-queue bandwidth share 10 10 60 20   (When the expedite queue, queue
1 has a value other than 0 it is enabled.  So this overrides both
shaping and sharing
                                          for this queue on this port.
Queue 1 will always be serviced first until empty.  Unlike shaping where
the queue is
                                          limited to the amount defined,
sharing allows a queue to share unused buffer space from other queues if
available.)


 srr-queue bandwidth shape  0  3  0  0  (COS 3 is mapped to queue 2
above.  Shape overrides share.  Here a weight of 3 means 1 over 3 or one
third
                                         so a third of the bandwidth and
no more is guaranteed for this queue on this port.  The zero values in
shape mean share
                                         is being used)

 queue-set 2  (this is the queue set number assigned to this port.
There are two possible queue sets and the default queue set is set 1)


 mls qos trust cos    (trust the cos from


 auto qos voip trust (this was the command which initiated the auto qos
config)
!
interface GigabitEthernet1/0/3
!
interface GigabitEthernet1/0/4
!
interface GigabitEthernet1/0/5

Warren Heaviside    wheav...@cisco.com
ENGINEER.CUSTOMER SUPPORT
Phone: +1 408 853 7995
Office Hour 9 am - 5 pm Pacific Monday - Friday

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html


-----Original Message-----
From: ccie_voice-boun...@onlinestudylist.com
[mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of
ccie_voice-requ...@onlinestudylist.com
Sent: Friday, July 23, 2010 6:13 PM
To: ccie_voice@onlinestudylist.com
Subject: CCIE_Voice Digest, Vol 53, Issue 120

Send CCIE_Voice mailing list submissions to
        ccie_voice@onlinestudylist.com

To subscribe or unsubscribe via the World Wide Web, visit
        http://onlinestudylist.com/mailman/listinfo/ccie_voice
or, via email, send a message with subject or body 'help' to
        ccie_voice-requ...@onlinestudylist.com

You can reach the person managing the list at
        ccie_voice-ow...@onlinestudylist.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of CCIE_Voice digest..."


Today's Topics:

   1. Re: Called Party display (Daniel Berlinski)
   2. LAN QoS> Priority and buffer size (Daniel Berlinski)
   3. Re: LAN QoS> Priority and buffer size (Randall Saborio)
   4. Re: LAN QoS> Priority and buffer size (Daniel Berlinski)


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

Message: 1
Date: Sat, 24 Jul 2010 10:30:20 +1200
From: Daniel Berlinski <dberlin...@gmail.com>
To: Brian Valentine <bkvalent...@gmail.com>
Cc: OSL Group <ccie_voice@onlinestudylist.com>
Subject: Re: [OSL | CCIE_Voice] Called Party display
Message-ID:
        <aanlktimb89zqwl_a=tecetrvnwqoa5vwtmqcef31k...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

? have written down on my notes from the VoDs I watched and from testing
done that H323 gateways and cosmetic effect in calling device display is
achieved by the following on calls that traverse H323 gateways:
Any digit manipulation performed in:
RP or RL or RG or Inbound dial-peer or Num-Exp will affect the calling
device display whereas manipulation performed in outbouond dial-peer
does
not affect the calling device screen.  I think this explains your
workaround
and to be honest I think the for you to achieve your requirement you got
to
go down this track.  The other option you may have is to do called party
xfoms on the egress BR1 gateway and then use the no
supplementary-service
h225-notify CID-update on the H323 gateway or do your H323 DNIS dgt
manipulation on the outbound dial-peer.

I'm unware of any service params for this but sometimes when I am 100%
sure
something is correctly configured but does not work I reboot my servers.
Have you given your boxes a kick after attempting the no
supplementary-service h225-notify CID-update config?

I need to try this myself but wanted to provide a suggestion.  let us
know
what your findings are.  I'm still a bit far from the lab you are doing.

Cheers
Daniel

On Sat, Jul 24, 2010 at 6:21 AM, Brian Valentine
<bkvalent...@gmail.com>wrote:

> "no supplementary-service h225-notify cid-update" doesn't seem to
help.
>
> I had an epiphany and figured out a work around to accomplish the
> task.  What the PG suggests seems to work fine, but only on an MGCP
> gateway.   I had to build an additional dial-peer in my BR1 gw with
> destination-pattern 415888.... (forward digits 7).  So, from CUCMs
> perspective, it sends the gateway 4158884343.  If I do the
> manipulation on the H323 gateway, it works. HQ Phone 2 will basically
> send whatever CUCM sends an H323 gateway.
>
> Maybe there is a service param somewhere?
>
> Brian
>
> On Fri, Jul 23, 2010 at 2:15 PM, Matthew Berry
<ciscovoiceg...@gmail.com>
> wrote:
> > Voice service voip
> > No supplementary-service h225-notify CID-update
> >
> >
> > Matthew Berry
> >
> > **Sent from my iPhone**
> > Skype/Twitter: ciscovoiceguru
> > Google Voice: +1 612 424 5044
> >
> > On Jul 23, 2010, at 12:31, Brian Valentine <bkvalent...@gmail.com>
> wrote:
> >
> >> I'm working on Vol2 Lab7 Task2.4.  The task involves the following:
> >>
> >> HQ phone 2 dials 914158884343.
> >> Prefer to use TEHO to route the call out BR1.  Local telco expects
7
> >> digits.  BR1 is an H323 gateway, so CUCM sends it 98884343.  The
> >> gateway strips the 9 before sending to telco.
> >> Second choice gateway is the HQ gateway, which is MGCP.  Local
telco
> >> will expect 11 digits.  CUCM would send the gateway 14158884343.
> >> Regardless of which gateway the call goes out the HQ Phone 2
display
> >> should say: "To 4158884343".
> >>
> >> Got the call routing and redundancy down fine.  That's works well
> >> enough.  The problem is that no matter what I do, it seems to
convert
> >> the display on HQ Phone 2 to match whatever digit manipulation was
> >> required by the egress gateway.  The proctor guide says: "The
display
> >> on the Calling phone will be derived from the Route Pattern
> >> manipulation although the actual digits the UCM sends to the
gateway
> >> is determined by the Route List/Route Group Called #
transformations".
> >> So, I tried that.  I tried doing all my digit manipulation on the
RL
> >> details level and use the XXXXXXXXXX as the Called Party
> >> transformation on the Route Pattern level.  Call goes through, but
the
> >> HQ Phone 2 still displays "To: 98884343".
> >>
> >> Next I tried setting the RL details to leave it as 415888XXXX and
used
> >> a Called Party Transformation Pattern at the gateway level to
convert
> >> the call.  I got the same result. Call succeeds.  The display on HQ
> >> Phone 2 shows "To: 98884343".  What am I missing?  Is this task
> >> possible?
> >>
> >> Thanks in advance,
> >>
> >> Brian
> >> _______________________________________________
> >> For more information regarding industry leading CCIE Lab training,
> please visit www.ipexpert.com
> >
> _______________________________________________
> For more information regarding industry leading CCIE Lab training,
please
> visit www.ipexpert.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
</archives/ccie_voice/attachments/20100724/467ea239/attachment-0001.html
>

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

Message: 2
Date: Sat, 24 Jul 2010 11:49:23 +1200
From: Daniel Berlinski <dberlin...@gmail.com>
To: osl osl <ccie_voice@onlinestudylist.com>
Subject: [OSL | CCIE_Voice] LAN QoS> Priority and buffer size
Message-ID:
        <aanlkti=7gkgg=n=ptaa-8kbhvmjx3zkp3grre1r4q...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hello

Can someone confirm my understanding.  The below question implies the
use of
priority-queue out inteface command.

For adjusting how much bandwidth is given to the egress priority queue
of a
3750/3560/2960 switch the interface command:
srr-queue bandwidth shape *means nothing*

The srr command that tunes the buffer size of memory to be given to
queue 1
is the one that will adjust the priority-queue depth required.

Feedback please
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
</archives/ccie_voice/attachments/20100724/b6894fb0/attachment-0001.html
>

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

Message: 3
Date: Fri, 23 Jul 2010 18:49:37 -0600
From: Randall Saborio <ill2...@gmail.com>
To: Daniel Berlinski <dberlin...@gmail.com>
Cc: osl osl <ccie_voice@onlinestudylist.com>
Subject: Re: [OSL | CCIE_Voice] LAN QoS> Priority and buffer size
Message-ID:
        <aanlktinf533m8b3qwbyocrqfodta4w3oda+yyvk=b...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi Daniel,

I had to review again my notes and the documentation to tell for sure
(wish
I knew it out of my head as earlier I was studying a lot of the lan qos
theory).

You are correct, the srr-queue bandwidth shape means nothing when you
configure the priority queue out. As it says on the doc:
"All four queues participate in the SRR unless the expedite queue is
enabled, in which case the first bandwidth weight is ignored and is not
used
in the ratio calculation. *The expedite queue is a priority queue, and
it is
serviced until empty* before the other queues are serviced. You enable
the
expedite queue by using the priority-queue out interface configuration
command. "

So what I get is the settings are ignore completely for the calculation
of
shared bandwidth for the other queues, and because the queue is serviced
until empty.

I'm all dizzy today from studying the LAN QoS and still can't say I know
it
all. :-/

On Fri, Jul 23, 2010 at 5:49 PM, Daniel Berlinski <dberlin...@gmail.com>
wrote:
> Hello
>
> Can someone confirm my understanding.  The below question implies the
use
of
> priority-queue out inteface command.
>
> For adjusting how much bandwidth is given to the egress priority queue
of
a
> 3750/3560/2960 switch the interface command:
> srr-queue bandwidth shape means nothing
>
> The srr command that tunes the buffer size of memory to be given to
queue
1
> is the one that will adjust the priority-queue depth required.
>
> Feedback please
>
>
> _______________________________________________
> For more information regarding industry leading CCIE Lab training,
please
> visit www.ipexpert.com
>
>



-- 
Randall "da ill" Saborio
CCIE Voice Wannabe #10054675811
(Real number coming this July 2010)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
</archives/ccie_voice/attachments/20100723/d072159d/attachment-0001.html
>

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

Message: 4
Date: Sat, 24 Jul 2010 13:12:28 +1200
From: Daniel Berlinski <dberlin...@gmail.com>
To: Randall Saborio <ill2...@gmail.com>
Cc: osl osl <ccie_voice@onlinestudylist.com>
Subject: Re: [OSL | CCIE_Voice] LAN QoS> Priority and buffer size
Message-ID:
        <aanlktimvvd1sk8aev5as7kvgrppqbggyi3xjr7ebp...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Thanks sir for your reply.

This is my understanding for quite a while and i hope i am not wrong for
all
this time. So i'm happy that you agree.  This goes inline to the
document
3750 QoS configuration examples - The document does not state this
objectively and I'm finding weird the fact of seeing lots of posts
lately in
this forum of people adjusting priority queue size by tweaking the wrong
place so keen to hear any contrary intelligent opinions out there.

If anyone out there disagrees please join the discussion and don't be
shy.



On Sat, Jul 24, 2010 at 12:49 PM, Randall Saborio <ill2...@gmail.com>
wrote:

> Hi Daniel,
>
> I had to review again my notes and the documentation to tell for sure
(wish
> I knew it out of my head as earlier I was studying a lot of the lan
qos
> theory).
>
> You are correct, the srr-queue bandwidth shape means nothing when you
> configure the priority queue out. As it says on the doc:
> "All four queues participate in the SRR unless the expedite queue is
> enabled, in which case the first bandwidth weight is ignored and is
not used
> in the ratio calculation. *The expedite queue is a priority queue, and
it
> is serviced until empty* before the other queues are serviced. You
enable
> the expedite queue by using the priority-queue out interface
configuration
> command. "
>
> So what I get is the settings are ignore completely for the
calculation of
> shared bandwidth for the other queues, and because the queue is
serviced
> until empty.
>
> I'm all dizzy today from studying the LAN QoS and still can't say I
know it
> all. :-/
>
>
> On Fri, Jul 23, 2010 at 5:49 PM, Daniel Berlinski
<dberlin...@gmail.com>
> wrote:
> > Hello
> >
> > Can someone confirm my understanding.  The below question implies
the use
> of
> > priority-queue out inteface command.
> >
> > For adjusting how much bandwidth is given to the egress priority
queue of
> a
> > 3750/3560/2960 switch the interface command:
> > srr-queue bandwidth shape means nothing
> >
> > The srr command that tunes the buffer size of memory to be given to
queue
> 1
> > is the one that will adjust the priority-queue depth required.
> >
> > Feedback please
> >
> >
> > _______________________________________________
> > For more information regarding industry leading CCIE Lab training,
please
> > visit www.ipexpert.com
> >
> >
>
>
>
> --
> Randall "da ill" Saborio
> CCIE Voice Wannabe #10054675811
> (Real number coming this July 2010)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
</archives/ccie_voice/attachments/20100724/5874060a/attachment.html>

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

_______________________________________________
CCIE_Voice mailing list
CCIE_Voice@onlinestudylist.com
http://onlinestudylist.com/mailman/listinfo/ccie_voice


End of CCIE_Voice Digest, Vol 53, Issue 120
*******************************************
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Reply via email to