Frame Relay PVC Counter Help

[mcotrone]

I am having FR provider issues and of course the provider says they are not in the wrong. I am trying to prove that their FR switches are dropping my frames in transit.

Can someone explain to me what the in pkts dropped counter means?

DLCI = 19, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.19

input pkts 119750 output pkts 125309 in bytes 72027342

out bytes 14407289 dropped pkts 7534 in pkts dropped 7534

out pkts dropped 0 out bytes dropped 0

in FECN pkts 0 in BECN pkts 0 out FECN pkts 0

out BECN pkts 0 in DE pkts 27795 out DE pkts 0

out bcast pkts 845 out bcast bytes 54080

pvc create time 2w1d, last time pvc status changed 1d17h

service policy VoIP

Serial0.19: DLCI 19 -

Is this the counter that recognizes that the frame-relay switch dropped 7534? My serial interface is clean with no drops and so is my LLQ counters so I am assuming this counter is directly connected to the frame-relay processing only.

Thanks!!!!

Mike

[mcotrone]

Also I am seeing some of my frames being marked DE so this is also leading me to believe the provider is dropping my frames.

Thanks

Mike

[kkalaycioglu]

Have you got traffic-dhaping config outbound on this interface? I think you're exceeding CIR. Have you checked your CIR/EIR values with your FR provider?

Regards.

[mcotrone]

Yes traffic shaping is enabled on both sides and that is exactly what I am trying to figure out. The provider says that we are configured right and I know we aren't. THis is why I need to know EXACTLY what the "in pkts dropped" counter means.

[mcotrone]

This is a response my Cisco ANS friend found from a topic search...

This count means there have be that many incoming or outgoing packets over this DLCI were dropped, at the FR frame header parsing time, because the DLCI was down (with "inactive" or "deleted" status).

More specifically, in the following cases we drop the packet and increment this counter for the said DLCI:

(a) For an incoming FR packet, when we first identify what the incoming DLCI is but detect this DLCI is not "active" (given that LMI is enabled);

(b) For a FR packet to be switched out on another DLCI (under the FR switching functionality), but the outgoing DLCI is not "active"(given that LMI is enabled).

[ Note: When LMI is disabled, all existent PVCs are considered "active". ]

It means that the packets have been passing the output queue and passed to the interface but when the interface wanted to send them on Frame-relay, they were dropped because of FR problem. This value is different from the interface drops. It probably indicates a problem

with the FR switch.

[kkalaycioglu]

Could you send your interface config?