From: Muhammad Ahmed (faisal3541@hotmail.com)
Date: Thu Jun 26 2008 - 15:46:31 ART
Thanks Nick. I will change my access-list per your recommendation.
Best regards,
Muhammad
> Date: Thu, 26 Jun 2008 05:13:03 -0400> From: matthn@gmail.com> To:
bspunt_2000@yahoo.com> Subject: Re: OT - VoIP QoS over PPP Multilink - VoIP
quality issues> CC: ccielab@groupstudy.com; faisal3541@hotmail.com> > 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> > >> > >
This archive was generated by hypermail 2.1.4 : Tue Jul 01 2008 - 06:23:23 ART