[c-nsp] VOIP QoS problem

[Eric Kagan]

> 
> What does the output of "show policy-map interface" provide?

>show policy-map interface
 Serial5/0/18:1

  Service-policy output: voice

    Class-map: VOIP (match-any)
      3907283 packets, 968793011 bytes
      5 minute offered rate 4000 bps, drop rate 0 bps
      Match: protocol rtp
        3381834 packets, 694582632 bytes
        5 minute rate 0 bps
      Match: protocol sip
        525449 packets, 274210379 bytes
        5 minute rate 4000 bps
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 65 (%)
        (pkts matched/bytes matched) 362279/86354233
        (total drops/bytes drops) 325/253673
      QoS Set
        ip precedence 5
          Packets marked 3907283

    Class-map: class-default (match-any)
      9540569 packets, 3881841498 bytes
      5 minute offered rate 8000 bps, drop rate 0 bps
      Match: any

> 
> 
> On 8/27/06 4:44 PM, "Scott Granados" <sgranados at jeteye.com> wrote:
> 
> > This may be totally unimportant, but shouldn't the 
> bandwidth setting 
> > be 1536?  ESF, B8zs with 8K framing?
> > 
> > 
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net 
> > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Eric Kagan
> > Sent: Sunday, August 27, 2006 1:35 PM
> > To: cisco-nsp at puck.nether.net
> > Subject: [c-nsp] VOIP QoS problem
> > 
> > We have several customers that utilize service with a 3rd 
> party VOIP 
> > provider.  We have applied a very simple QoS policy (below) 
> to several 
> > customers interfaces on our Cisco 7206VXR's as well as the 
> CPE.  One 
> > customer in particular is complaining of frequent problems. 
>  We could 
> > not find anything real obvious of why they are having 
> issues.  Traffic 
> > on the norm is about 200-300k on a full T1 which should not even 
> > warrant needing the QoS in place.  From what I understand and have 
> > read on the Qos config below - it will only get applied as 
> the circuit 
> > starts to get congested. We put some real time traffic 
> monitors on the 
> > customers interface and saw a few real short spikes almost 
> maxing out 
> > the circuit.  Is it possible for the circuit to experience a really 
> > quick burst of traffic that doesn't allow the QoS policy to 
> "kick-in" 
> > quick enough so the customer experiences some drops ?  
> Anyone have any 
> > ideas on how to best troubleshoot or determine this problem 
> ?  Should 
> > we consider reserving a fixed amount of bandwidth vs the 
> config below.  
> > Could the output drops be contributing to this problem ?  
> Any pointers 
> > would be appreciated.
> >  
> > Thanks
> > Eric
> >  
> >  
> > class-map match-any VOIP
> >   match protocol rtp
> >   match protocol sip
> > !
> > policy-map voice
> >   class VOIP
> >    priority percent 65
> >    set ip precedence 5
> > 
> > interface Serialx/x/x
> >  bandwidth 1544
> >  ip address x.x.x
> >  ip flow ingress
> >  ip nbar protocol-discovery
> >  service-policy output voice
> >  encapsulation ppp
> >  no clns route-cache
> > 
> >  
> > show int Sx/x/x
> > Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 
> > 5222 Queueing strategy: weighted fair Output queue: 0/1000/64/5222 
> > (size/max total/threshold/drops) 
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net 
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > 
> > 
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net 
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
>