erial up,line protocol up but cannot ping interface

[xhackuss1]

Hello folks,

I have a little problem that requires our attention. I am having some problems with a link. On one end of my router, I see the serial interface up, line protocol up yet I cannot even ping that interface. The other end is in up/down state. When I issue a local loop on the router towards the service provider,I do not see the loop. Any ideas what is wrong?

[gaurav_thapar79]

needs o/p of following commands.

1. show version.

2. show interface

3. show controller

[xhackuss1]

attached is the output of the:

sh ver

sh int sx/y

sh controller sx/y

[pciaccio]

The issue you are seeing is that your transmit from your router is not getting to the remote end. Your interface shows as UP/Up and the remote shows as UP/Down. They see carrier detect and DSR from the CSU but no protocol from your router. You need to isolate the failed point in your line (assuming T-1 PTP) If running external CSU's then you need to verify cabling to those devices. You can isolate further by giving yourself loopbacks down the line and see where the failure lies....Good Luck...Please rate

[xhackuss1]

Yes I am using an external CSU.A loopback locally on the side that shows up/up and not seen on the router.What do ou think?

[Mohamed Sobair]

Hi,

AT the DCE Other Side, IS there any type of Compression set?

Could u make sure of the V35 cable connection at the other side?

If its still there, please turn on debugging , command is (debug serial interface)

HTH

Mohamed Sobair

[Kevin Dorrell]

Is this a back-to-back serial connection?

First, I should say that if you are pinging the local interface, the remote end needs to be working as well. In the case of a point-to-point line, when you ping your local interface, the ping is reflected round the remote end. (The response takes this path too.)

If the local end is up/up and the remote end is up/down. You need to ask why. How can the local router think the protocol is up, and the other end think it is down?

Are the encapsulations perhaps different at each end, ppp vs. hdlc?

Are keepalives disabled at the local end only perhaps? That would force the protocol to seem up, but it is not the truth.

All in all, it looks like you might have transmission working in one direction only, from remote to local.

Kevin Dorrell

Luxembourg

[xhackuss1]

Thanks Kevin, you have saved my situation. I never thought about the keepalive.

The keepalive was indeed turned off. After I turned it on , everything is ok.

Thanks a million fold.

An aside is this, on that same router, I have realised an increased in the input drops on the fa0/0 interface as evidenced below. any suggestion?

FastEthernet0/0 is up, line protocol is up

Hardware is AmdFE, address is 0017.9474.20e0 (bia 0017.9474.20e0)

Description: ethernet Link to 10.0.1.0 network

Internet address is 10.0.1.X/24

MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

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

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s, 100BaseTX/FX

ARP type: ARPA, ARP Timeout 04:00:00

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

Last clearing of "show interface" counters 01:14:45

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

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 1947000 bits/sec, 550 packets/sec

5 minute output rate 2604000 bits/sec, 2149 packets/sec

4771567 packets input, 2251989607 bytes

Received 6644 broadcasts, 0 runts, 0 giants, 0 throttles

1140 input errors, 0 CRC, 0 frame, 364 overrun, 776 ignored

0 watchdog

0 input packets with dribble condition detected

11542200 packets output, 2088223489 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

[Kevin Dorrell]

Glad to be of service.

Mmm .. 364 overruns plus 776 ignored is 1140. I'm not sure, but I do notice that the interface is running continuous 2 Mbps, and that you do have quite a lot of drops on your input queue.^ I don't suppose you have any QoS policing on this interface or something?

Are these counters going up continuously? Could you clear them down just to get a reference point and see how they after an hour or so.

I'll try and think what the reason could be: I think input queue drops are unusual in those numbers unless the CPU is overloaded. Could you let us see the config of the interface?

Kevin Dorrell

Luxembourg

[aravindhs]

Hi Kevin,

That was a very nice reply. My understanding is that Frame-Relay Interfaces, when pinged, go uptill the switch and reflect back with a response. It is interesting to know the serial interfaces do the same. Is it because of the addressing structure of the HDLC frame ? Can you possibly elaborate it a bit more or provide a link that explains it.

Many Thanks,

Aravind

[Kevin Dorrell]

I don't have a link to hand, but I think it is simply that in a point-to-point link, any frame that has a destination address in the subnet (including those destined for the local address) will be transmitted out the link. It is then up to the device at the other end to receive the ping and relay it back to the sender. The response does exactly the same.

Another way of looking at it is that the router only responds to a ping that comes from the link. It does not intercept the ping on the way out, to respond to it.

As regards frame-relay, the ping A-to-B is not reflected by the switch, but it goes all the way to the other end (B) and is reflected there. 'A' then receives its own ping, and sends the response out on the link, where 'B' receives it, and sends it back to 'A', which treats it as a response.

That much is evident on a point-to-point subinterface. You can see what it going on by doing a debug ICMP at the other end.

But what about a multipoint FR interface, or physical? Well the same thing applies. More crucially, if you do not have a frame-relay map command for your own local address, pointing to the DLCI of one of your partners, then a ping to your own address will not work. You have to tell it which partner to reflect the ping off.

Does that make sense?

Kevin Dorrell

Luxembourg