• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 831
  • Last Modified:

last-dropped bytes???

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
  • 3
1 Solution
>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.

Any progress or updates to your status?

- Cheers!
ballstrykerAuthor Commented:
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...
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.


Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now