Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

line up , but line protocol down - can't figure out why

Status
Not open for further replies.

beatdown

Technical User
Feb 27, 2005
85
0
0
US
I'm a newbie setting up a lab to study for my CCNA cert. My lab consist of 3 routers: 1720, 2520, and 2524. The 3 routers are connected via 60 pin DTE/DCE back-to-back cables. The 2520 is the "middle" router, having 2 serial interfaces, and the 1720 and 2514 each have one serial interface.

The connection between the 1720 (DTE) and serial 0 on the 2520 (DCE) works great. However, the connection between serial 1 on the 2520 (DCE), and the 2524 (DTE) has problems: the line shows as being up, but the line protocol is down.

I've checked all the things I know to check, in my limited experience...clock rate, keepalives, encapsulation. I've also tried switching the cable with the cable I know to be good. I also tried hooking the 2524 up to serial 0 on the 2520 (the interface I know works because it works with the 1720). Still no luck.

The funny thing is that if I shut down one of the interfaces (it doesn't matter if its the DCE interface on the 2520, or the DTE interface on the 2524), and then start the interface again (no shut command), I get a message that both the line and protocol are up...but then about 10 seconds later, I get another message that the line is up, but the protocol is down. I figured this might have to do with the keepalives, so I changed them to 30 seconds, and the same thing happens when I shut down and restart an interface...except it takes about 30 seconds before I get the message that the protocol is down. However, if I try to ping the local serial interface, during that 30 seconds when both the line and protocol are "up"...I get no response...so it's like it's not really up.

If anybody has any ideas how to fix this, I sure would appreciate it.

Below is the "sh int serial" from both routers:

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

2524_Router#sh int s0
Serial0 is up, line protocol is down
Hardware is HD64570 with 5-in-1 module
Description: WAN link to 2520 router
Internet address is 192.168.40.2 255.255.255.0
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Last input never, output 0:00:04, output hang never
Last clearing of "show interface" counters never
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
192 packets output, 5424 bytes, 0 underruns
0 output errors, 0 collisions, 64 interface resets, 0 restarts
0 output buffer failures, 0 output buffers swapped out
127 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up

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


2520_Router#sh int s1
Serial1 is up, line protocol is down
Hardware is HD64570
Description: WAN l
Internet address is 192.168.40.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set
Keepalive set (10 sec)
Last input never, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1158 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
136 packets output, 2992 bytes, 0 underruns
0 output errors, 0 collisions, 47 interface resets
0 output buffer failures, 0 output buffers swapped out
90 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
 
The reason the line comes up immediately and then goes down shortly after is because keepalives are turned on. The router has to see three failed keepalives before it declares the line protocol down.

You might have a flaky port. Try swapping ends of the cable, i.e. making the DCE the DTE and vice versa.

If that doesn't work and you've already tried a known good cable then I would declare the port bad.

Oh, you might also want to try a lower clockrate if you're using a high clock rate. Sometimes these interfaces behave better at slow speeds when they're acting flaky.
 
I just tried swapping the cable with a known good cable, and still no dice.

I also tried changing which router was DTE and which was DCE, but the result is the same.

Finally, I tried a couple of lower clock rates, but it's still not working.

I also tried completely turning off keepalives on both routers, and after I did this...it showed the line & protocol as being up. BUT...when I tried to ping the local (or remote) serial interface, I got a 100% failure. Since I'm pretty new to Cisco, I'm not sure if this is what you would expect when you turn off keepalives...or if this is further proof that I have some major issues?

Is there a way to tell for sure if I have a flaky serial card, other than buying a new card to test with? I know there are several "debugging" options on cisco routers, but I don't really have a clue how to use any of them, or know if they would even help me isolate this issue?

Thanks
 
Sounds like the clocking isn't set up right , one end has to supply the clock and the other end must be set up to pull the clock from the line for it to come up .
 
If clocking is not configured, the interface will be down/down. In this case, the interface is up physically but the line protocol is not coming up.
 
In reply to Vipergg's post:

On the DCE router/serial interface, I applied the command:

router(config-if)# clock rate 64000

I also experimented with some lower clock rates. Is there anything else I need to do to set clocking? I thought this was all I needed to do (no clocking commands necessary on the DTE router)?

Thanks
 
Unfortunately, I'm still leaning toward a bad port. One other thing you can try is to switch cable types. If you're using V.35 cables, try switching to RS-232, or vice versa. You might get lucky, you never know.
 
Thanks to everybody for your help on this. I finally figured out what the problem was. I needed to set the encapsulation type to LAPB on both routers, and specify which was the DCE router. For anybody who's interested, it's all spelled out in this document:

 
beatdown, that document does not describe what you think it does. You should not be using LAPB in a lab like you have, especially if you're just doing CCNA-level stuff.

If you were having problems with HDLC encapsulation yet you are successful with LAPB then your problems are even stranger than I thought.

All you need is matching encapsulations and physical clocking on the DCE side--that's it, nothing else, and you surely do not need to be messing with LAPB.

Trust me on this: if you don't know *why* you need LAPB, then you don't.
 
Agreed, I have no clue what LAPB even is...all I know is that now my 2520 and 2524 routers are finally talking to each other.

I understand that all I should need is matching encapsulation and clocking on the DCE side... but for some reason, this just wouldn't work between my 2520 and 2524 routers.

I tried connecting my 1720 router to the 2520, and then to the 2524...and it worked great both ways...regardless of which router I made DCE or DTE (I tried this both ways too).

But for some reason, the 2520 and the 2524 just would not work together, until I changed the encapsulation like this document showed.

Any idea why this might be, that it only works with LAPB? Is it possible that it's not really LAPB that made the difference, but rather it's the fact that with this command you are able to manually specify that the interface is DCE:

(config-if)# encapsulation lapb dce

I noticed that there is no option to manually specify DCE when using HDLC.

Will the LAPB encapsulation stop me from being able to do the configurations in the CCNA level labs? I understand that I don't need (or understand) LAPB, but if it's the only thing that I can seem to get to work, will I be able to get by using it?
 
The DCE option you see with LAPB is a layer two DCE and is unrelated to the layer one DCE. LAPB and Frame Relay (among others) have the concept of datalink layer DCE and DTE. HDLC is not based on this concept so you don't need to manually configure a datalink DCE.

I'm beginning to think you have really old IOS on your 2500s. What IOS are you running on your 2520 and 2524?
 
I'm not sure of the exact versions (I'm not where the routers are, so I can't check), but I know the 2520 is pretty up to date with version 12.2.x, but the 2524 has an older IOS... version 11.0.x

Actually, this leads me to another question; is there a way for a guy like me (doing self study for cisco certs) to obtain IOS images, particularly so I could update the old IOS on my 2524? I know you can download IOS images from the Cisco TAC website if you have the proper account type & password, but as far as I know the only way to get such an account/password is to purchase a smartnet package for your router?
 
Hmm... Your 2520 should have had no problem whatsoever with this connection assuming everything else was done correctly. The 2524, however, may very well be suffering from a bug. There were some HDLC and frame relay bugs in the older releases that make them not play well with newer releases in some cases.

Upgrade your 2524 to the same IOS running on the 2520, if you have the memory available.

Regarding how to get IOS software, the only legal way to get it is to purchase a license for it.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top