03-26-2007 07:53 AM - edited 03-03-2019 04:18 PM
Hi Experts,
We have a P2P link between India and UK. What we have noticed is that we are seeing incrementing Output Drops on our serial interface in UK.
Pls find screenshot
Serial0/0/1 is up, line protocol is up
Hardware is GT96K Serial
Internet address is 192.168.20.129/30
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set
Keepalive set (10 sec)
Last input 00:00:01, output 00:00:01, output hang never
Last clearing of "show interface" counters 2d13h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 69891
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 1 packets/sec
5 minute output rate 0 bits/sec, 1 packets/sec
122629643 packets input, 889580392 bytes, 0 no buffer
Received 25992 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
98870494 packets output, 2723332531 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
Please find below the config of the interface-
interface Serial0/0/1
ip address x.x.x.x y.y.y.y
no ip redirects
no ip unreachables
no ip proxy-arp
ip tcp header-compression iphc-format
ip tcp compression-connections 256
no ip mroute-cache
no fair-queue
no cdp enable
ip rtp header-compression iphc-format
ip rtp compression-connections 1000
!
We are running VoIP trafic over this link. Please can someone suggest/advise as to why we are seeing these output drops increments as we are facing some voice quality issues in this setup.
Many thanks in advance.
03-26-2007 11:19 AM
Your link is getting congested, and you have not configured QoS. Not surpisingly you have voice quality issues.
is simple as that. Probably you don't need that many pre-allocated cRTP sessions.
Hope this helps, please reate all useful posts!
03-26-2007 11:24 AM
Hi there,
Thanks for your suggestion.
HOw would you suggest we configure QoS on this link. We are running both voice and data on the same link. Please can you advise of the config required.Also pls elobarate on the pre allocated cRTP sessions config.
Many thanks.
03-26-2007 11:29 AM
See:
http://cisco.com/en/US/products/sw/iosswrel/ps1830/products_feature_guide09186a0080087b13.html
In the configuration, assuming the voice endpoint are marking RTP with DSCP EF, you do not need to use IP address or anything. Just configure to match DSCP EF and put it in the LLQ.
Hope this helps, please rate all useful posts!
03-28-2007 05:39 AM
Hi There,
Much appreciate the response.
Just an update, we have now separated the voice and data traffic on two different serial interfaces.
The utilization on the Voice link is around 40% max, however we are still observing these output drops.
Any suggestions.Config of interface is attached-
interface Serial0/0/1
description ****link Connected to Chennai****
ip address x.x.x.x y.y.y.y
no ip redirects
no ip unreachables
no ip proxy-arp
ip tcp header-compression iphc-format
ip tcp compression-connections 256
no ip mroute-cache
no fair-queue
no cdp enable
ip rtp header-compression iphc-format
ip rtp compression-connections 1000
Also if it helps, this is a cisco 2821 router with Version 12.3(8)T11 IOS.
03-28-2007 05:45 AM
Is cef enabled on the router ?
You can increate the output queue a little bit, and monitor it together with router cpu, buffer utilization, etc.
03-28-2007 08:43 AM
If you have a link that is frequently in a congestive state then neither a QoS policy nor CEF is going to help. In fact, although you use a QoS policy to insure a certain level of service for specific traffic/applications that would only make the problem worse for other traffic flows. QoS is not a solution for a congested link; it?s more like a safety net for what should be rare occurrences of congestion. Also, increasing the output queue size can be dangerous. If packets sit in the queue too long its as good as if they had been dropped altogether.
03-28-2007 09:21 AM
griffijo, all what you said is correct, however in certain cases the router can exhibit drops not directly related to congestion, one typical case is buffer exhaustion. This is why the TAC has published literature on-line on how to diagnose and address 'strange' output drops cases.
03-28-2007 09:27 AM
That is interesting, I had not heard that. I'd be interested in reading the literature on that.
03-28-2007 11:13 AM
Here you go:
http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186a0080094791.shtml
True however that most 'strange' problems will be input queue drops, not output.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide