Speaking of, here is one nice terminal server setup for someone who wanted to configure a large number of router pods and/or dialups (ends in 20 minutes): http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=1232652456 Compaq 6200 w/6 2511s w/96 modems. Heh, start your own small ISP. Not too bad for $1500. -- Jason Roysdon, CCNP+Security/CCDP, MCSE, CNA, Network+, A+ List email: [EMAIL PROTECTED] Homepage: http://jason.artoo.net/ ""Kevin Wigle"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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] > 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=2654&t=2654 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
