Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

Telnet issue

Ok,

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?

--John

HTH, John *** Please rate all useful posts ***
34 REPLIES
Hall of Fame Super Bronze

Re: Telnet issue

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.

HTH,

__

Edison.

Re: Telnet issue

Ping works fine. The setup is like this:

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

Router B's last resort is 192.168.1.2 (ip route 0.0.0.0 0.0.0.0 192.168.1.2)

That's the only route that it has.

If I do a show arp | i 192.168.1.2, 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.

Thanks,

John

HTH, John *** Please rate all useful posts ***
Hall of Fame Super Gold

Re: Telnet issue

John

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?

HTH

Rick

Re: Telnet issue

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!

--John

HTH, John *** Please rate all useful posts ***
Silver

Re: Telnet issue

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.

Re: Telnet issue

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

HTH, John *** Please rate all useful posts ***
Silver

Re: Telnet issue

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.

Re: Telnet issue

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

HTH, John *** Please rate all useful posts ***

Re: Telnet issue

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 0.0.0.0 0.0.0.0 192.168.1.2"?

Thanks!!

--John

HTH, John *** Please rate all useful posts ***
Hall of Fame Super Bronze

Re: Telnet issue

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.

HTH,

__

Edison.

Re: Telnet issue

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 (10.10.10.0) to the rest of the network via bgp by redistributing my statics on the primary router that links to this router.

--John

HTH, John *** Please rate all useful posts ***
Hall of Fame Super Bronze

Re: Telnet issue

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?

Thanks

Re: Telnet issue

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 192.168.1.1 is the public side. This is a fiber point to point connection (ATT Opteman link).

Here's my routing table

Routing entry for 10.10.10.0/24

Known via "static", distance 1, metric 0

Redistributing via bgp 65101

Advertised by bgp 65101

Routing Descriptor Blocks:

* 192.168.1.1

Route metric is 0, traffic share count is 1

192.168.1.1 Routing table:

192.168.1.0/24 is subnetted, 1 subnets

C 192.168.1.0 is directly connected, FastEthernet0/1

10.0.0.0/24 is subnetted, 2 subnets

C 10.10.10.0 is directly connected, FastEthernet0/0

C 10.11.11.0 is directly connected, FastEthernet0/0

S* 0.0.0.0/0 [1/0] via 192.168.1.2

Thanks!

John

HTH, John *** Please rate all useful posts ***
Hall of Fame Super Bronze

Re: Telnet issue

Try redistributing connected on the 192.168.1.2 BGP router.

HTH,

__

Edison.

Re: Telnet issue

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

HTH, John *** Please rate all useful posts ***

Re: Telnet issue

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

RemoteRouter#sh ip route 192.168.1.0

% Network not in table

RemoteRouter#

RemoteRouter#sh ip route 10.10.10.0

Routing entry for 10.10.10.0/24

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

Tag 13979, type external

Last update from 172.20.155.2 05:30:34 ago

Routing Descriptor Blocks:

* 172.20.155.2, from 172.20.155.2, 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.

John

HTH, John *** Please rate all useful posts ***
Hall of Fame Super Bronze

Re: Telnet issue

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 192.168.1.0/30 subnet isn't known to many devices so any request being sourced from 192.168.1.1 are being dropped.

HTH,

__

Edison.

Re: Telnet issue

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 192.168.5.50 255.255.255.255 192.168.1.2

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

Thanks Edison!

John

HTH, John *** Please rate all useful posts ***
Hall of Fame Super Bronze

Re: Telnet issue

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?

__

Edison.

Re: Telnet issue

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.

--John

HTH, John *** Please rate all useful posts ***
Hall of Fame Super Bronze

Re: Telnet issue

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?

__

Edison.

Re: Telnet issue

Yes I can, with no issues.

HTH, John *** Please rate all useful posts ***

Re: Telnet issue

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 10.5.5.50 /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!

John

HTH, John *** Please rate all useful posts ***
Hall of Fame Super Bronze

Re: Telnet issue

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...

___

Edison.

Re: Telnet issue

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?

Thanks!

John

HTH, John *** Please rate all useful posts ***
Hall of Fame Super Bronze

Re: Telnet issue

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.

HTH,

__

Edison.

Re: Telnet issue

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 10.10.10.0 0.0.0.255 any log

Then I would apply this to the debug?

Thanks!

John

HTH, John *** Please rate all useful posts ***
Hall of Fame Super Bronze

Re: Telnet issue

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 10.10.10.0 0.0.0.255 any

then debug:

debug ip packet 100 detail

HTH,

__

Edison.

Re: Telnet issue

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. :-)

--John

HTH, John *** Please rate all useful posts ***
284
Views
15
Helpful
34
Replies
CreatePlease to create content