changed it to:

line vty 0 4

exec-timeout 30 0

login local

transport preferred all

transport input all

transport output all

still nothing

found this:

MONR005#sh access-list

Extended IP access list sl_def_acl

10 deny tcp any any eq telnet log

20 deny tcp any any eq www log

30 deny tcp any any eq 22 log

40 permit ip any any log

MONR005#sh run | i sl_def_acl

MONR005#

I do not see it in my sh run.

I am not sure where this is at.

I did this:

MONR005(config)#no ip access-list Extended sl_def_acl

MONR005(config)#exit

MONR005#sh access-list

Extended IP access list sl_def_acl

10 deny tcp any any eq telnet log

20 deny tcp any any eq www log

30 deny tcp any any eq 22 log

40 permit ip any any log

MONR005#

Still there?

I have seen that access list before (in a fairly old piece of code if I remember correctly). It is inserted by IOS and it can not be deleted. I believe that it can not be modified. And it is not the problem.

As far as I could tell the access list shows up when you do show access list but is not applied to any interface or access class. If the access list were denying anything there should be a hit count when you show access-list and there is not hit count.

HTH

Rick

This one definately has me baffled.

I am not a fan of rebooting devices to solve issues, but it has been up for over 3 years so maybe it is time for a swift kick in the butt!

reboot if you wish. But I do not see that this is anything that will be affected by reboot.

I believe that the fundamental issue so far is that you are attempting to telnet from a source that does not allow you to telnet. It is not an issue with your router. It is an issue with where you are attempting to telnet from.

HTH

Rick

Collin is mistaken about the meaning of exec-timeout 0 0. This expresses the length of the inactivity timeout in minutes and seconds. While it might seem logical that 0 0 would indicate an immediate timeout that is not the case. Using the value of 0 0 indicates that there is no timeout. So this was never the issue.

I believe that there is a good clue about what the issue is in your post. You include this:

route-views.oregon-ix.net>telnet 12.181.229.1

Command authorization failed.

The error message indicates that command authorization failed. This is your immediate problem. When I looked carefully at the config that you posted I notice that there is no authorization configured. So why is authorization failing?

Then it occurred to me that you are doing this from the public route looking glass at route-views.oregon-ix.net. I am pretty sure that the public looking glass sites will let you look at routes and that they do not allow you to do things like telnet.

So if you try to telnet from somewhere that is not a public looking glass, then what happens?

HTH

Rick

RET901R001#telnet 12.181.229.1

Trying 12.181.229.1 ...

% Connection timed out; remote host not responding

Rick

If the connection is timing out from here that is a different symptom. My first question would be can you verify that you have a correct route to that address and that your router has a correct route back to you. This looks like it could be an issue with basic IP connectivity.

HTH

Rick

Yeah, I get that wrong everytime (sorry). I'm blaming Cisco for not making the command fit my frame of mind.

Actually exec-timeout 0 0 means no time out at all.

This looks more like an authentication issue.

Sam

Cannot get to the authentication piece.

I cannot even get connected to enter in credentials.

Do you have any access to the switch? Can you post a show line?

try inserting a permit telnet to ur destination under seq 5, so u keep the ACL but test if that is the reason.

else find out where it is applied (interface) and remove it...but its risky cos its there for a reason.

HTH

Sam