**WARNING - THE VERBOSITY BIT IS SET - THIS MESSAGE IS DISCARD ELIGIBLE IF YOUR BUFFERS ARE FULL** Hi, I think there may be a degree of misunderstanding about the use of the no exec command. If you have seen this command used in an access server that provides dialin access to corporate users, or you have configured an access server for a typical ISP, that is probably an appropriate place for this command. When you place no exec under a given line, it will preclude any use of an executive process (user or privileged). Dont take my word on it. Lets all do a little test on our home routers. First, do not do this test in a production network, period. Second, it you are a little weak on the IOS, you may want to brush up on your password recovery procedures; you will need it later. Here goes. I will show you three different ways to test this. First, go to the console port of your router **DO NOT TELNET IN** Next, configure your router as follows: router# router(config)# router(config)#lin vty 0 4 router(config-line)#no exec router(config-line)#exit router(config)#int loopback 77 router(config-int)#ip add 1.0.0.1 255.0.0.0 router(config-int)#end router# Now attempt to telnet into your own router using any accepted telnet command, such as: router#telnet 1.0.0.1 or, router#connect 1.0.0.1 or, router#1.0.0.1 You should get the following output: 2503#telnet 1.0.0.1 Trying 1.0.0.1 ... Open [Connection to 1.0.0.1 closed by foreign host] The connection will not open. Since we did not have any access class commands applied, the only other explanation is that a vty line is dedicated for one purpose, namely to run an executive process. You can either telnet into the vty to do user exec commands, or privileged exec commands. When the line has been restricted so that no exec is in place, then the vty line is effectively shut down and no connection is allowed. Remove the "no exec" command under the vty lines and reattempt it. You will note it works. Lets try it a second way. This time, we will implement the following commands on any cisco router that has both an AUX port and a console line. We will change the AUX port into a line configuration and we will issue the no exec command on the AUX line. Before you start, make sure your configuration is clear under the AUX line and console lines. It should similar to this: line con 0 transport input all line aux 0 transport input all Go ahead and verify you get a command prompt in both AUX and console lines. Verify you have interactivity by starting a ping to 1.0.0.1 on each (physically plug into both ports). Then execute the following additional commands while plugged into the AUX line: router#conf t router(config)#lin aux 0 router(config-line)#no exec router(config-line)#end router# Try a ping again. It will work. Now save your configuration with the following command and execute a reload while still plugged into the AUX line: router#copy run start router#reload Proceed with reload? [confirm]y 07:35:36: %SYS-5-RELOAD: Reload requested The last line is the last entry you will see. When the router reboots, you will not be able to see any output. You may be asking yourself why the command did not take place immediately as most commands do. It did take place immediately however, you were still on a connected line. Once the connection is severed (via a reload), then the AUX line will have no exec process when the system reboots. This can be further verified once the system boots by attempting to get a router prompt from the AUX line. When you are unsuccessful, plug into the console line and go into line configuration mode and restore the exec process with the following commands: router#conf t router(config)#lin aux 0 router(config-line)#exec router(config-line)#end router# Log back into the AUX line and verify it now works properly. On some routers you may have to reboot to get this to take effect. The final check on this is to do the same test with the console line. WARNING - DO NOT ATTEMPT TO DO THIS UNLESS YOU ARE VERY FAMILIAR WITH PASSWORD RECOVERY!!! Plug into the console line and type the following: router#conf t router(config)#lin con 0 router(config-line)#no exec router(config-line)#end router# Run the same test and verify all functionality is still there, e.g. execute a ping and get a response. Everything should work just fine. Save your config and do a reload as before: router#copy run start router#reload Proceed with reload? [confirm]y 07:35:36: %SYS-5-RELOAD: Reload requested This time you are going to notice something really strange and different. You will note that you can watch the router reload and go through its POST and execute its startup-config. The only problem is that you cannot tell the router to do anything because you guessed it, you have no exec on the console line. You will see output go by one the screen, but you cannot enter any commands. So, how do we fix it? Yes, you guessed it password recovery. The only difference here is that when you do password recovery in this instance, you will not recover a password, rather, you will remove the no exec entry from your configuration on the console line. Final point why do you use such a command, no exec? It would seem to be terribly unhelpful and not too useful. Consider the example of the access server. You have configured your access server with multiple modems attached. When a user wants to access your network remotely while in a hotel, they just call in via a POTS line and reach a modem. Since they have no need and no business playing on the router itself (only the network it serves), you would want to use the no exec command to ensure they could not set up an executive session on the router. What about the original example and the reason for this post? Well, as I remember it, the original post was about somebody who was trying to configure this CS-500 for reverse telnet as a terminal server. In that case, you would want to leave exec configured on all of the lines that have router console ports attached. Additionally, you will still have to fix the issue mentioned below regarding a reverse telnet into a line that has no cable attached. Hope this helps more :-) v/r, Paul Werner > I don't think your problem has anything to do with the "no exec" command > in > your config. I also use the "no exec" command for my async ports and it > works great. > > I think the problem lies within these commands. > > ip host R1 2003 1.1.1.1 > line 1 > no exec > monitor > transport input telnet > transport output telnet > > Notice that the port you specified was 2003. Port 2003 maps to line 3, > not > line 1. You don't have anything configured for line 3, so the reverse > telnet > session will not work for it. I would either try changing the port to > 2001 > or change the "line 1" command to "line 1 3" ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=2536&t=2536 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
