06-09-2009 08:09 AM - edited 03-04-2019 05:02 AM
Here is the config:
I cannot telnet and not sure why...
version 12.3
service timestamps debug datetime localtime show-timezone
service timestamps log datetime localtime show-timezone
service password-encryption
!
hostname MONR005
!
boot-start-marker
boot system flash c3725-ipbase-mz.123-8.T.bin
boot-end-marker
!
card type t3 1
logging buffered 4096 debugging
enable secret 5 $1$QmEK$i3jypfmwHTbkiGrN9KQxL0
!
username Full@cc3ss privilege 15 secret 5 $1$FjA0$.Y2iIWMgkSrCLcaSp6nFY0
clock timezone EST -5
clock summer-time EDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00
no network-clock-participate aim 0
no network-clock-participate aim 1
no aaa new-model
ip subnet-zero
ip cef
!
!
!
!
ip flow-cache timeout active 1
no ip domain lookup
ip domain name lzbmon.hq
no ftp-server write-enable
!
!
!
controller T3 1/0
clock source line
!
!
interface FastEthernet0/0
description Inside-FastEthernet0/0
bandwidth 102400
ip address 12.181.229.1 255.255.255.128
no ip redirects
no ip proxy-arp
ip route-cache flow
load-interval 30
speed 100
full-duplex
!
interface FastEthernet0/1
no ip address
no ip redirects
no ip proxy-arp
shutdown
speed 100
full-duplex
!
interface Serial1/0
description 30300
bandwidth 44210
ip address 12.aa.bb.94 255.255.255.252
ip nbar protocol-discovery
encapsulation ppp
ip route-cache flow
load-interval 30
dsu bandwidth 30300
!
ip classless
ip route 0.0.0.0 0.0.0.0 12.dd.ee.ff
ip route 12.20.xx.yy 255.255.255.224 12.aa.bb.cc
ip flow-export source FastEthernet0/0
no ip http server
!
!
control-plane
!
line con 0
login local
transport preferred all
transport output all
line aux 0
exec-timeout 0 0
transport preferred all
transport output all
line vty 0 4
exec-timeout 0 0
login local
transport preferred all
transport input all
transport output all
!
There is no acl applied
I cannot telnet from the outside or from my internal network.
Any ideas?
I ran a debug telnet and do not see any attempts.
route-views.oregon-ix.net>ping 12.181.229.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.181.229.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/64/64 ms
route-views.oregon-ix.net>telnet 12.181.229.1
Command authorization failed.
route-views.oregon-ix.net>
06-09-2009 08:13 AM
It's the following line
exec-timeout 0 0
It's setting the exec to 0 minutes 0 seconds! This means it timeouts immediately.
Try setting it to something like
exec-timeout 5 0
Hope that helps
06-09-2009 08:25 AM
changed it to:
line vty 0 4
exec-timeout 30 0
login local
transport preferred all
transport input all
transport output all
still nothing
06-09-2009 08:31 AM
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?
06-09-2009 08:57 AM
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
06-09-2009 08:58 AM
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!
06-09-2009 09:04 AM
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
06-09-2009 08:52 AM
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
06-09-2009 08:54 AM
RET901R001#telnet 12.181.229.1
Trying 12.181.229.1 ...
% Connection timed out; remote host not responding
06-09-2009 09:06 AM
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
06-09-2009 11:28 AM
Yeah, I get that wrong everytime (sorry). I'm blaming Cisco for not making the command fit my frame of mind.
06-09-2009 08:30 AM
Actually exec-timeout 0 0 means no time out at all.
This looks more like an authentication issue.
Sam
06-09-2009 08:32 AM
Cannot get to the authentication piece.
I cannot even get connected to enter in credentials.
06-09-2009 08:36 AM
Do you have any access to the switch? Can you post a show line?
06-09-2009 08:37 AM
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: