Why does telnet session hang after saying ... Open?

Unanswered Question
Jul 22nd, 2010

Trying to telnet from router to router across frame relay (details below). Can ping OK but when I telnet it gets as far as telling me the session is open but I never get prompted for a password. I hit enter and every key combination I can think of. I have tried entering the telnet password despite not being prompted. Nothing. The connection times out anywhere from 15 seconds to 2 minutes after connecting (no matter how much I bang on the keyboard). A field tech said he could telnet to the router from the ethernet side (when he was there previously) but no one has actually demonstrated this to me.

Below are some configuration details. You'll notice that one dlci is set to IETF and the other one isn't. I tried changing the near side from IETF to CISCO and it did not fix the problem. I have since changed it back to IETF. I was told this setting is locally significant only and besides, remember that it pings.

Telnetting from: Cisco 3845 Version 12.4(16a), RELEASE SOFTWARE (fc2)

Telnetting to: Cisco 2821 Version 12.4 (sorry, that's all the details I have on this one -- from a show run printout)

Destination (FAR end) router vty config:

line vty 0 4
password 7 xxxxxxxxxxx
login
transport input telnet
!

Destination (FAR end) router interface config:

interface Serial0/0/0.181 point-to-point
description PVC for Monitoring
bandwidth 56
ip address 192.168.0.2 255.255.255.252
frame-relay interface-dlci 181  
  class 56ps_16cir_Shaping

NEAR end interface config:

interface Serial1/0.180 point-to-point
description ABC group2 (ABC)
bandwidth 56
ip vrf forwarding ABC
ip address 192.168.0.1 255.255.255.252
no cdp enable
frame-relay interface-dlci 180 IETF

Thanks in advance.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Giuseppe Larosa Fri, 07/23/2010 - 08:18

Hello G-fadie,

>> Below are some configuration details. You'll notice that one dlci is set to IETF and the other one isn't. I tried changing the near side from IETF to CISCO and it did not fix the problem. I have since changed it back to IETF. I was told this setting is locally significant only and besides, remember that it pings.

No encapsulation must match on both endpoints in order to work, LMI settings are local not encapsulation settings

So remove IETF on near end side

note2:

on near end side the link is associated to a VRF

this means that to really use the link you need to use

ping vrf ABC 192.168.0.2

and also when you telnet you need to use

telnet 192.168.0.2 /vrf ABC

be aware that in global routing table another device may have the same address as remote end this can explain why ping 192.168.0.2 can be successful even if FR encapsulation is not correct at both ends of the link of interest.

Hope to help

Giuseppe

g-fadie Fri, 07/23/2010 - 09:04

Hey giuslar

Thanks for the reply. I neglected to mention that I was already using the 'ping vrf ABC 192.168.0.2' and 'telnet 192.168.0.2 /vrf ABC'. So I'm convinced that ping is working end-to-end. I also neglected to mention that the field tech who installed the far end successfully ping'd my end.

But just to be sure I changed the encapsulation from IETF to so that now both ends match. Unfortunately this has not helped. The telnet session still hangs. I get this line:

Trying 192.168.0.2 ... Open

And that's it.

Actions

This Discussion