Telnet issue

Unanswered Question
Nov 21st, 2008


I posted a couple of days ago about a telnet problem that I had where I could ping the router, but couldn't telnet to it. There are NO acls involved at all.

Well today, I figured out that I can telnet to the router from another router, but not from a host behind the router. It looks like this:

Cannot telnet: host -> router -> router

Can telnet: router -> router

This doesn't make any sense to me at all. Any ideas?


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3.8 (4 ratings)
Edison Ortiz Fri, 11/21/2008 - 10:57

It seems the destination router does not have a route back to the host - Yes, I know you said ping works but it could be due to some proxy-arp feature enable on the router<->router link.

Verify routing from the router to host and vice-versa.




John Blakley Fri, 11/21/2008 - 12:04

Ping works fine. The setup is like this:

RouterA (f0/0) -----> (fa0/0) Router b

Router B's last resort is (ip route

That's the only route that it has.

If I do a show arp | i, I show that 1.1 and 1.2 are on interface fa0/0 on RouterA. Does this mean it's doing proxy arp? I don't have it specifically disabled, and I'm not sure what ramifications it would have if I did disable it. Aside from that, why can I telnet from a router, but not from a host behind the router? No firewalls in any scenario by the way.



Richard Burts Fri, 11/21/2008 - 10:58


Can that host telnet to the first router? Is it possible that there is something on that host that interferes with telnet?

Is it possible that there is some security policy on the middle router that might intercept the telnet to the other router?



John Blakley Fri, 11/21/2008 - 11:59

The host can telnet into the router that's local to it, but not across to the other router. The router that's local to the host can telnet to the other router. There's nothing blocking traffic, and it's really frustrating me. :-)

Thanks Rick!


Rick Morris Fri, 11/21/2008 - 11:00

Can any other host get to this router?

Is there a firewall inline between these, or a proxy server?

I had an issue at a client site and it was a firewall that sit between the host and the edge router, but there was another path via another zone in the firewall that allowed a switch to telnet into the router.

John Blakley Fri, 11/21/2008 - 11:58

There are no hosts behind this router, but all routers in the enterprise can telnet to it.

Rick Morris Fri, 11/21/2008 - 12:02

Is this the only router that this particular host cannot telnet to?

Have you tried from another host?

also telnet to that specific router from another router and turn on debug

debug telnet

Make sure you term mon to show the output

This will tell you if you can even get to it.

John Blakley Fri, 11/21/2008 - 12:07

I can telnet to any of my other routers from this host (and it's not really a host issue). I can't telnet from any location, any host, behind a router, to this router. I've created access lists that dump logs, and I don't see any of my host IPs in there, but I do see when the router gets connected.


John Blakley Fri, 11/21/2008 - 12:13

Ok, I can't telnet from the "bad" router to another host. I'm sure it's a routing issue, but I can ping the host from the router, soooo my next question is:

What is so different about telnet as compared to ping in that it won't just use the default route of "ip route"?



Edison Ortiz Fri, 11/21/2008 - 13:25

Are you advertising the 192.168.1.x (router-to-router) link to the rest of the network?

Can you traceroute from the host to the router and see where it dies?

You can setup an ACL with log options on the router incoming interface and see if the packet is making it there.




John Blakley Fri, 11/21/2008 - 13:28

Packet isn't making it there, but traceroute doesn't die. It goes all the way through to the router. I admit, it's a weird problem.

I'm not advertising the public interface of that router, but I am advertising the internal subnet ( to the rest of the network via bgp by redistributing my statics on the primary router that links to this router.


Edison Ortiz Fri, 11/21/2008 - 13:32

I'm not advertising the public interface of that router,

A little confused there. You mentioned 192.168.1.x/24 - you call that public interface?

You said, traceroute doesn't die - does it go into a loop ?

Is this a lab or production network?

Can you post configs, diagram and routing table?


John Blakley Fri, 11/21/2008 - 13:58

No loop; it finishes the trace with no problems. I've attached a quick diagram. This is a production network, and it's working fine with everything else. It's a DR site, and yes the is the public side. This is a fiber point to point connection (ATT Opteman link).

Here's my routing table

Routing entry for

Known via "static", distance 1, metric 0

Redistributing via bgp 65101

Advertised by bgp 65101

Routing Descriptor Blocks:


Route metric is 0, traffic share count is 1 Routing table: is subnetted, 1 subnets

C is directly connected, FastEthernet0/1 is subnetted, 2 subnets

C is directly connected, FastEthernet0/0

C is directly connected, FastEthernet0/0

S* [1/0] via



Edison Ortiz Fri, 11/21/2008 - 14:08

Try redistributing connected on the BGP router.




John Blakley Fri, 11/21/2008 - 14:13

Can I do this in conjunction of the redistribute static? (I assume so.) And will it affect anything on a grand scale?

Thanks Edison,


John Blakley Fri, 11/21/2008 - 14:19

Here's what I get from a remote router (before adding redistribute connected):

RemoteRouter#sh ip route

% Network not in table


RemoteRouter#sh ip route

Routing entry for

Known via "bgp 65155", distance 20, metric 0

Tag 13979, type external

Last update from 05:30:34 ago

Routing Descriptor Blocks:

*, from, 05:30:34 ago

Route metric is 0, traffic share count is 1

AS Hops 2

Since the router knows about the remote routers inside interface, but it doesn't know about the routers outside interface, is this causing a problem with telnet? I can ping the inside and outside, but apparently, I'm just using my default route out to get to the public side on the remote router.


Edison Ortiz Sat, 11/22/2008 - 12:26

Hard to tell any side effect on bringing connected routes into BGP without a careful examination of your network.

With that said, you can control the redistribution with a route-map and just include the link in question into BGP.

Based on what you've told us, it seems the subnet isn't known to many devices so any request being sourced from are being dropped.




John Blakley Mon, 11/24/2008 - 07:04

But if the internal subnet is known, and I can ping it from anywhere, then why would the public side drop the packets if the destination address isn't the public? In other words, why do both public and private subnets need to be known in order for me to telnet to it? I can understand that I wouldn't be able to connect to the public side because it's not known, but I can ping the private side and still not telnet to it. What's the router doing with that packet that's keeping the return traffic from getting back, and what's the "best" way for me to troubleshoot this without injecting more routes? I thought about adding a static route on that router to just my workstation:

ip route

to see if that would work, but I'm not sure if it would tell me anything.

Thanks Edison!


Edison Ortiz Mon, 11/24/2008 - 07:35

That static route may reveal that the problem is from the router to the workstation, thus I recommend proceeding with this process.

The workstation knows to get to the router via the default route but does the router know how to get back to the workstation?



John Blakley Mon, 11/24/2008 - 07:41

Just to verify, I telnetted into the router (from another router of course), and I was able to ping my workstation with no problems. This is with the default route of all 0s. (Last resort).

With all of these posts, I don't know if I mentioned that I'm able to authenticate from this router to a radius server, but I also can't telnet from that radius server into the private side of that router.


Edison Ortiz Mon, 11/24/2008 - 07:43

but I also can't telnet from that radius server into the private side of that router.

This may reveal something. Can you ping the radius server while sourcing the packet from the private side of that router?



John Blakley Mon, 11/24/2008 - 07:53

Okay, my last test proved unfruitful. I tried to telnet from the router that no one can get to, to an AS400 server on the subnet that the radius server is on.

I tried:

ip telnet source fa0/0 <-- private interface

Didn't work (destination network unreachable)

I then tried to source telnet this way:

telnet /source-interface fa0/0

Same thing.

I can ping that address from the router while sourcing from f0/0, so apparently telnet is doing something other than going out the default router. This is odd to me, and I really don't understand it.

Thanks for all of your help Edison!


Edison Ortiz Mon, 11/24/2008 - 08:26

I know you mentioned no ACL is involved in your network topology but the only explanation I can give you is that there is some kind of ACL in the transit path.

Very weird behavior you are experiencing there...



John Blakley Mon, 11/24/2008 - 08:31

I guarantee there's no acl. Is there some sort of troubleshooting that I can do with debugs? I'm not even sure what type of debug to use. debug ip routing? Where would I place it? On the router I'm having a problem getting to from the "bad router", or one that I'm having a problem getting to the "bad router" from?



Edison Ortiz Mon, 11/24/2008 - 08:43

debug ip packet on a hop-by-hop transit and make sure to disable fast-switching in the transit interfaces to see the debug.

I'm assuming you aren't generating any traffic on this network at the moment?

If so, make sure to enable debug with an ACL.




John Blakley Mon, 11/24/2008 - 08:48

There is traffic going across it. This is the DR site that constantly has VM replication going across. What do you mean by "hop-by-hop transit?" Are you saying that I need to enable this on each router and l3 switch this is going through? Also, I need to disable cef? And I've not used a ton of acls with debugs, so how would that look?

permit ip any log

Then I would apply this to the debug?



Edison Ortiz Mon, 11/24/2008 - 08:52

You want to examine how the traffic is going from point A to point B, so you need to enable debug on every router in the path to see where the traffic is dying.

You can leave cef enabled but you need to disable ip route-cache.

As for the debug w/ ACL, it would look like this:

access-list 100 permit ip any

then debug:

debug ip packet 100 detail




John Blakley Mon, 11/24/2008 - 08:56

Would I need to change the acl source for every router or do I do this same acl on all three routers? And am I right with wanting to trace the internal interface as opposed to the external, or should I put both in the acl?

Thanks Edison! This is more debugging than I've done in the past I think. :-)


Edison Ortiz Mon, 11/24/2008 - 09:01

You need to format your ACL for the interesting traffic from the source to destination and vice-versa.

To make things simple, try a source w/ the problem that is closest to the destination. Initiate the test and see what the debug displays.

Another suggestion will be, if you have a lab, try dumping the configuration from the routers into the lab and see if you can duplicate it there.



John Blakley Mon, 11/24/2008 - 09:10

I'll have to test it out in a lab. I want to see what I'll have to look for, and I HOPE I can recreate this in a lab. :-)

I'll let you know tomorrow what the results were!

Thank you!

John Blakley Tue, 11/25/2008 - 07:19

Okay, I set up the lab exactly as it is here, and I couldn't duplicate the problem. I give up, and I'm just going to telnet from the box that I know can get to it. It's just a really weird situation that I can ping from both directions, but not telnet. Odd.


Edison Ortiz Tue, 11/25/2008 - 07:45

Usually, when I see issues with no reasoning behind it, a reboot usually fixes it :)

Give it a shot.



ullasupendran Fri, 11/21/2008 - 12:13

i fully agree with edison for checking the route in the target router to host network belongs and check for the default gateway of the host.



This Discussion