I think the "no exec" issue may be a work around for other behaviour on async lines. Specifically for using async lines as a terminal server. I don't know how well the normal octopus cables are insulated but I have noticed lots of noise on these lines. The noise on these lines seem to be able to trigger an exec session which prevents the line from being opened until it is cleared. Using "no exec" seems to prevent this from happening but you are still able to connect. Now I'm talking "through the router out the line connection", not "in the line out the router connection" which it seems you are talking about. "Most" times when we're talking about reverse telent we're talking about connecting a line from the "server" to the console port of another router. In this case, the remote router is not initiating a call down the line, it is accepting a call. We talk about this so much it seems as it is just about the first thing you have to do in the CCIE lab. (so I'm told - haven't been there yet but I have books that say this) I grant that if you tried to make a call into the line with "no exec", you probably won't get too far. But in most of the cases we are talking about going the other way. The "no exec" keeps the line down (available) until we really want it. On our main terminal server at work - a 2611 we have the following line: line 33 48 no exec Now our purpose is to connect to the terminal server to access the lab and to access the console ports of the other routers in the lab pod. When I telnet to w.x.y.z 2033 I get connected to the router at the end of line 33. (which is line 1 on the cable) When on the terminal server console I telnet to port 2033 on the loopback I get to the same place. So, you are correct in what you say - but I think the most often the problem being addressed is that the line is reported as in use and the user isn't the one using it. I have yet to see anyone suggest using "no exec" on a vty or console line so that doesn't seem to fit into the discussion. My slant - others may vary. Kevin Wigle ----- Original Message ----- From: Paul Werner To: Sent: Monday, April 30, 2001 3:10 AM Subject: Re: RE: 500-CS...HELP!! [7:2414]......here is my 500-CS config [7:2536] > **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 > FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=2577&t=2577 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
