Go Premium for a chance to win a PS4. Enter to Win


last-dropped bytes???

Posted on 2004-09-03
Medium Priority
Last Modified: 2013-12-12
I am currently working on problem with a Frame Relay DS3 that has a 5mb CIR. I have been seeing some drops on the interface. The Telco says that everything is testing clean, which I am not taking as a totally true answer..... I wanted to find out if someone can explain the LATE-DROPPED OUT PKTS and LATE-DROPPED OUT BYTES.? Is it part of the Queueing strategy?  I have been monitoring the link on 5 minute polls and seen utilization low. (95th percentile IN/OUT=1.5m/900k) I'm thinking dirty lines or frame switch issue, telco issues.......   THANKS
sh frame-relay pvc in sx/x/x.206
nput pkts 851091759     output pkts 738244414    in bytes 2350918783
  out bytes 174765793      dropped pkts 1428        in pkts dropped 0
  out pkts dropped 1428             out bytes dropped 815141
  late-dropped out pkts 1428        late-dropped out bytes 815141
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 3814093       out DE pkts 0
  out bcast pkts 1668846   out bcast bytes 142396896
  5 minute input rate 1415000 bits/sec, 289 packets/sec
  5 minute output rate 838000 bits/sec, 215 packets/sec
  pvc create time 14w1d, last time pvc status changed 3d10h

  MTU 1500 bytes, BW 44210 Kbit, DLY 200 usec,
     reliability 255/255, txload 17/255, rxload 8/255
  Encapsulation FRAME-RELAY, crc 16, loopback not set
  Keepalive set (10 sec)
  Restart-Delay is 0 secs
  LMI enq sent  1063567, LMI stat recvd 1063631, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 0  LMI type is ANSI Annex D  frame relay DTE
  FR SVC disabled, LAPF state down
  Broadcast queue 3/4000, broadcasts sent/dropped 407380797/71, interface broadcasts 3
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 17w4d
  Input queue: 0/75/54/9 (size/max/drops/flushes); Total output drops: 3565
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  30 second input rate 1546000 bits/sec, 526 packets/sec
  30 second output rate 2983000 bits/sec, 828 packets/sec
     2829966506 packets input, 1656117048 bytes, 41 no buffer
     Received 0 broadcasts, 0 runts, 1 giants, 0 throttles
              0 parity
     931 input errors, 859 CRC, 0 frame, 46 overrun, 0 ignored, 26 abort
     4278505032 packets output, 2274577291 bytes, 0 underruns
     0 output errors, 0 applique, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     5 carrier transitions
   rxLOS inactive, rxLOF inactive, rxAIS inactive
   txAIS inactive, rxRAI inactive, txRAI inactive
Question by:ballstryker
  • 3
LVL 79

Expert Comment

ID: 11983923
>last time pvc status changed 3d10h
>   5 carrier transitions

These two items indicate the circuit went down and came back up at least 5 times, last one probably 3days and 10 hours ago.
Circuit flaps will certainly result in dropped packets.

Suggest clear counters and watch them some more.

LVL 79

Expert Comment

ID: 11996643
Any progress or updates to your status?

- Cheers!

Author Comment

ID: 11997973
I actually cleared the counters when I posted the message and there is no incrementing errors, just DE PKTS, which looking on my RRD, spikes above the CIR but is okay... I'm still researching the response time, I am thinking there are some server-to-workstation issues at my site.

One thing I am still wondering about is the LATE-DROPPED errors under sh frame pvc command. Would you know what those pertain to?

Thanks a bunch...
LVL 79

Accepted Solution

lrmoore earned 1000 total points
ID: 11998476
It is most likely related to the queueing strategy


Frame Relay is a special case with respect to policing the priority queue. The Low Latency Queueing for Frame Relay feature overview notes the following caveat: "The PQ is policed to ensure that the fair queues are not starved of bandwidth. When you configure the PQ, you specify in kbps the maximum amount of bandwidth available to that queue. Packets that exceed that maximum are dropped." In other words, originally, the priority queue of a service-policy configured in a Frame Relay map class was policed during periods of congestion and non-congestion. IOS 12.2 removes this exception. PQ is still policed with FRF.12, but other non-conforming packets are only dropped if there is congestion.



Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

    Over the past few years, small business and home owners have become so dependent on internet that a need for redundancy has arisen.    What happens when your small business or home / home office loses its internet connection?  The results c…
Cable Modem Provisioning from DPoE compliant server  This Article is to support CMTS administrators to provide an overview of DOCSIS compliance configuration file, and to provision a cable modem located at customer place from a Back office serve…
Are you ready to place your question in front of subject-matter experts for more timely responses? With the release of Priority Question, Premium Members, Team Accounts and Qualified Experts can now identify the emergent level of their issue, signal…
Is your data getting by on basic protection measures? In today’s climate of debilitating malware and ransomware—like WannaCry—that may not be enough. You need to establish more than basics, like a recovery plan that protects both data and endpoints.…

886 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question