From: Muhammad Ahmed (faisal3541@hotmail.com)
Date: Thu Jun 26 2008 - 15:44:45 ART
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> > > >> >
This archive was generated by hypermail 2.1.4 : Tue Jul 01 2008 - 06:23:23 ART