From: brett spunt (bspunt_2000@yahoo.com)
Date: Thu Jun 26 2008 - 16:12:53 ART
As you said, that's the proper way to do it...cant say for sure if it wouldnt work the way you have it, but also, cant say you wouldnt have unpredictable results..I'd do the nested shaping..
HTH,
___________________________________
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 Thu, 6/26/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: "brett spunt" <bspunt_2000@yahoo.com>, ccielab@groupstudy.com
> Date: Thursday, June 26, 2008, 11:44 AM
> Thanks Brett.
>
> Please tell me if the suggestion in point 4 in your email
> is a recommendation or a requirement to perform shaping for
> non-VoIP traffic. Almost every document I have read dictates
> using nested policies but I do not understand why I would
> not get the desired results with the way I have it
> configured.
>
> Best regards,
> Muhammad
>
>
>
> > Date: Wed, 25 Jun 2008 20:33:30 -0700> From:
> bspunt_2000@yahoo.com> Subject: RE: OT - VoIP QoS over
> PPP Multilink - VoIP quality issues> To:
> ccielab@groupstudy.com; faisal3541@hotmail.com> > 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> > >
> >
> _________________________________________________________________
> The other season of giving begins 6/24/08. Check out the
> ibm Talkathon.
> http://www.imtalkathon.com?source=TXT_EML_WLH_SeasonOfGiving
This archive was generated by hypermail 2.1.4 : Tue Jul 01 2008 - 06:23:23 ART