From: Nick Matthews (matthn@gmail.com)
Date: Thu Jun 26 2008 - 06:13:03 ART
There are a number of reasons why you don't want to match an access list to
just the IP phone address destinations. Some of these include different
media resources - if you're transcoding/conferencing/ using a MTP, the
destination IP address will be to one of your gateways/CMs rather than the
phones directly. This is why you're better off using a NBAR or access-list
based upon ports for voice QoS.
On Wed, Jun 25, 2008 at 11:33 PM, brett spunt <bspunt_2000@yahoo.com> wrote:
> Hi Muhammad,
>
> There are a number of potential issues at hand here..
>
> If you can not use DSCP/COS in the network, still see the following for
> issues I see in the config
>
> 1. Remove the following:
>
> ppp multilink fragment delay 1 (normally should be 10ms)
> ppp multilink interleave (not needed for links over 768kb)
>
> 2. identify voice payload using L4 information and put only this traffic
> into LLQ
>
> 3. create a CBWFQ for signaling traffic using L4 information. Give it 64kb
> and you'll be fine
>
> 4. remove the traffic shaping from the default queue. If you want to do
> class based shaping, you want to setup a "nested qos policy"...
>
> see the following config snippet..
>
>
> class-map match-any Voice-QoS
> match ip dscp ef
> match ip rtp 16384 16383
> class-map match-any Mark-Voice-Signaling
> match ip dscp af31
> match ip dscp cs3
> !
> policy-map Voice-QoS
> class Voice-QoS
> priority 4096
> class VOICE-Signal
> bandwidth 32
> class class-default
> fair-queue
> random-detect dscp-based
> !
> policy-map Shape_Nested_QOS
> description traffic shaping and QOS WAN policy
> class class-default
> shape average 10000000
> service-policy Voice-QoS
> !
> interface gig0/1.25
> service-policy output Shape_Nested_QOS
>
> ___________________________________
> Brett Michael Spunt, CCIE No. 12745
> Senior Consultant
> Convergence Practice, AT&T Consulting
> http://www.att.com/consulting
> Bs3757@att.com
> Your world. Delivered.
>
>
>
> --- On Tue, 6/24/08, Muhammad Ahmed <faisal3541@hotmail.com> wrote:
>
> > From: Muhammad Ahmed <faisal3541@hotmail.com>
> > Subject: RE: OT - VoIP QoS over PPP Multilink - VoIP quality issues
> > To: ccielab@groupstudy.com
> > Date: Tuesday, June 24, 2008, 7:50 PM
> > resending the configuration with line breaks. do not know
> > what happened
> > there.
> >
> > class-map match-any GOLD
> > match access-group 105
> > policy-map MEX_Priority
> > class GOLD
> > priority 1544
> > class class-default
> > fair-queue
> > random-detect
> > shape average percent 93 10 ms
> > interface Multilink1
> > ip address 10.63.0.1 255.255.0.0
> > ip flow ingress
> > ip flow egress
> > load-interval 30
> > ppp multilink
> > ppp multilink interleave
> > ppp multilink group 1
> > ppp multilink fragment delay 1
> > ppp timeout multilink lost-fragment 0 200
> > service-policy output MEX_Priority
> >
> >
> >
> >
> > > From: faisal3541@hotmail.com> To:
> > ccielab@groupstudy.com> Subject: OT - VoIP
> > QoS over PPP Multilink - VoIP quality issues> Date: Tue,
> > 24 Jun 2008 21:44:24
> > -0500> > Hello guys,> > Sorry for the OT. I
> > need some advise on a VoIP quality
> > issue over PPP> Multilink bundle. If a question sounds
> > stupid, its probably
> > because it is> stupid. I do not know much about QoS and
> > practically do not
> > know anything> about VoIP.> > I have configured
> > the following on the PPP
> > Multilink bundle and I just want> the to ensure there is
> > no other
> > configuration required to optimize VoIP> packets over
> > the bundle.> > I am
> > using 3 T1's to form the bundle and PPP Multilink
> > Multiclass is> configured on
> > the serial interfaces to sequence non-fragmented VoIP
> > packets as> well. One
> > way delay variation between the fastest and the slowest T1
> > is ~8ms,> which
> > quite frankly I do not know if 8ms is within the jitter
> > tolerance level> for
> > VoIP. End-to-end, one-way, latency between the phones is
> > about 12ms> through
> > the fastest T1 and 22ms through the slowest T1. Access-list
> > 105 is> matching
> > the IP addresses of the VoIP phones which have static IP
> > addresses.> It
> > matches any packet destined to VoIP phones at the remote
> > site. I am hoping>
> > matching VoIP phone IP addresses would match any and all
> > VoIP packets that>
> > should be treated through the QoS policy. Please confirm if
> > this would not>
> > match all packets. I know I should probably tag VoIP
> > packets with DSCP or>
> > Precedence at the VoIP phone boundary switch but I do not
> > manage these>
> > switches and I cannot convince the switch administrator to
> > implement the>
> > correct configuration fast enough. fragment delay of 1 ms
> > results in a>
> > fragment size of 184 bytes which I am assuming would be
> > large enough to frame>
> > the largest VoIP packet, please confirm. Multilink bundle
> > is congested with>
> > data traffic. I do know there are packet drops, for both
> > PPP multiclass Class>
> > 0 and 1, which are probably causing the entire VoIP quality
> > issue but since>
> > this is my first deployment of QoS I am not confident and
> > do not feel like I>
> > have the command on it to definitively say that my
> > configuration is correct>
> > for QoS so I can start looking at resolving the drop packet
> > issue with>
> > whichever T1 is at fault. The total VoIP payload through
> > the bundle is>
> > ~800kbytes during peak usage. I configured 1.544Mbps for no
> > apparent reason>
> > other than to avoid built in policing on the priority
> > policy.> > Best Regards
> > and thanks for reading my misery. :)> Muhammad> >
> > BTW, the QoS policy has been
> > removed for testing the T1's for faults so I> would
> > not be able to provide any
> > "show" command outputs.> > class-map
> > match-any GOLD match access-group 105>
> > policy-map MEX_Priority class GOLD priority 1544 class
> > class-default>
> > fair-queue random-detect shape average percent 93 10 ms>
> > interface Multilink1
> > ip address a.b.c.d 255.255.0.0 ip flow ingress ip flow>
> > egress load-interval
> > 30 ppp multilink ppp multilink interleave ppp multilink>
> > group 1 ppp multilink
> > fragment delay 1 ppp timeout multilink lost-fragment 0>
> > 200 service-policy
> > output MEX_Priority> > > >
> > _________________________________________________________________>
> > Need to
> > know now? Get instant answers with Windows Live
> > Messenger.>
> >
> http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_
> >
> > Refresh_messenger_062008> > >
> > _______________________________________________________________________>
> > Subscription information may be found at: >
> > http://www.groupstudy.com/list/CCIELab.html> > >
> > >
> > _________________________________________________________________
> > Introducing Live Search cashback . It's search that
> > pays you back!
> >
> http://search.live.com/cashback/?&pkw=form=MIJAAF/publ=HMTGL/crea=introsrchca
> > shback
> >
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Tue Jul 01 2008 - 06:23:23 ART