Telnet issue

[John Blakley]

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

[John Blakley]

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

[John Blakley]

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

[Edison Ortiz]

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.

[John Blakley]

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

[Edison Ortiz]

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.

[John Blakley]

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

[Edison Ortiz]

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.

[John Blakley]

Yes I can, with no issues.

[John Blakley]

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

[Edison Ortiz]

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.

[John Blakley]

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

[Edison Ortiz]

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.

[John Blakley]

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

[Edison Ortiz]

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.

[John Blakley]

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