Loss of connectivity - ping mainly

[mwilkinson]

Hi

I've got a site that, up until last week, was fine. Since then, we're losing ping requests and users have complained of slow connectivity to the Internet (the net server is housed here - off-site). The PVC's are showing as active, yet I'm concerned about the number of Giants on the serial interface (see below). The telco are saying that the PVC's are fine (obviously!) but as far as I can see everything looks OK. Any ideas?

CAC#sh int ser 0/0

Serial0/0 is up, line protocol is up

Hardware is PowerQUICC Serial

Description: Frame Relay Circuit NXFSxxxxxx CSACxxxxxxx

MTU 1500 bytes, BW 512 Kbit, DLY 20000 usec,

reliability 255/255, txload 4/255, rxload 6/255

Encapsulation FRAME-RELAY, loopback not set

Keepalive set (10 sec)

LMI enq sent 52121, LMI stat recvd 51514, 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

Broadcast queue 0/64, broadcasts sent/dropped 160095/0, interface broadcasts 1

42655

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters 6d00h

Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue :0/40 (size/max)

5 minute input rate 14000 bits/sec, 10 packets/sec

5 minute output rate 10000 bits/sec, 7 packets/sec

3042917 packets input, 743328230 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 243 giants, 0 throttles

110054 input errors, 61457 CRC, 45842 frame, 0 overrun, 0 ignored, 2755 abo

rt

3020304 packets output, 660022149 bytes, 0 underruns

0 output errors, 0 collisions, 39 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

DCD=up DSR=up DTR=up RTS=up CTS=up

CAC#sh interface serial 0/0 summary

*: interface is up

IHQ: pkts in input hold queue IQD: pkts dropped from input queue

OHQ: pkts in output hold queue OQD: pkts dropped from output queue

RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec)

TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec)

TRTL: throttle count

Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL

----------------------------------------------------------------------

* Serial0/0 0 0 0 0 24000 13 13000 10 0

* Serial0/0.1 - - - - - - - - -

* Serial0/0.2 - - - - - - - - -

NOTE:No separate counters are maintained for subinterfaces

Hence Details of subinterface are not shown

CAC#sh interface serial 0/0 accounting

Serial0/0 Frame Relay Circuit NXFSxxxxxx CSACxxxxxxx

Protocol Pkts In Chars In Pkts Out Chars Out

IP 2975295 784438355 3093934 666068674

CDP 16330 4727523 34884 9802404

CAC#sh frame-relay pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

Active Inactive Deleted Static

Local 2 0 0 0

Switched 0 0 0 0

Unused 0 0 0 0

DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

input pkts 2913518 output pkts 2888845 in bytes 734615503

out bytes 695771460 dropped pkts 0 in pkts dropped 0

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 9689 out DE pkts 0

out bcast pkts 80319 out bcast bytes 8331301

pvc create time 6d00h, last time pvc status changed 1d02h

DLCI = 17, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.2

input pkts 78912 output pkts 80156 in bytes 8439958

out bytes 8193372 dropped pkts 0 in pkts dropped 0

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 0 out DE pkts 0

out bcast pkts 79803 out bcast bytes 8135597

pvc create time 6d00h, last time pvc status changed 1d02h

CAC#sh frame-relay ip tcp header-compression

DLCI 16 Link/Destination info: point-to-point dlci

Interface Serial0/0:

Rcvd: 1560483 total, 1466787 compressed, 64 errors

0 dropped, 0 buffer copies, 0 buffer failures

Sent: 1531843 total, 1434477 compressed,

45016693 bytes saved, 129535070 bytes sent

1.34 efficiency improvement factor

Connect: 256 rx slots, 256 tx slots,

1331313 long searches, 12142 misses 0 collisions, 0 negative cache

hits

99% hit ratio, five minute miss rate 0 misses/sec, 0 max

DLCI 17 Link/Destination info: point-to-point dlci

Interface Serial0/0:

Rcvd: 189 total, 99 compressed, 1 errors

0 dropped, 0 buffer copies, 0 buffer failures

Sent: 197 total, 96 compressed,

2882 bytes saved, 10579 bytes sent

1.27 efficiency improvement factor

Connect: 256 rx slots, 256 tx slots,

141 long searches, 71 misses 0 collisions, 0 negative cache hits

63% hit ratio, five minute miss rate 0 misses/sec, 0 max

[erobles]

Hi there, the first thing I would do is clear out the counters on this interface and look at it while trying to access the sites that you are having an issue with. From what you posted up I see alot of input and CRC errors. This can be several things, but mostly comes down to the physical level like a bad wire. Now it can be anywhere from inside your telco provider all the way to your hand-off or even in rare situations your CSU/DSU on your router. What I would suggest in doing is clearing out the counters while having your telco provider on the phone monitoring Try to access the sites you are having diffculties reaching they will be able to see if your traffic is comming across their network clean or with errors. At the same time do a show int ser 0/0 and take a look at the input and crc errors see if they are going up. If they are I would suggest in having your telco provider come out and running a test from your drop and seeing where the error is at. Once again I do state that it may not be on their end and in the CSU/DSU but the amount of errors that I see in the document you provided does show that it might be a physical issue on the line. I went thru the same situation with a remote site of mine and it was a bad pair of wires leading to my smart-jack. - Ed

[m.iancu]

hi,

not likely but you might want to check also clock source for your interface and/or csu/dsu.

mihai

[rjackson]

If this is your internet connection I would turn CDP off. Its just wasting bandwidth. Previous post about clearing counters and watching again is important to prove/disprove physical layer problems. After that I have to wonder who you are pinging. If its into the internet that can be unreliable and at many sites is blocked. To isolate and test the link just try to ping the other side of the link from the router on your end of the link. If it has problems and you dont see errors on your end you need to know whats happening in the router at the other end.