12-19-2003 07:13 AM - edited 03-02-2019 12:28 PM
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
12-19-2003 07:15 AM
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
12-19-2003 07:23 AM
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.
12-19-2003 07:35 AM
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.
12-19-2003 07:47 AM
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.
12-19-2003 07:49 AM
Could you send your interface config?
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