2911 TS causing async line lockout

[samuel.d.knox]

I have a brand new 2911-TS running 2900-universalk9-mz.SPA.151-4.M1.  I have connected the async lines to several devices including ASA5510's, 7206VXR and 6506es.  I'm experiencing issues where I go to connect to the console port of one of my devices and my access is denied as if the port was already in a session.  I clear the line and try again, same response.  If I swap that line with a known functioning line I see lines and lines of output as if the device I was trying to connect to was constantly sending data to the console port.  I've not had this problem on any of my older Cisco terminal servers.  I opened a TAC case and they had me RMA the HWIC module.  Things appeared to clear up for a while but now I'm experiencing this issue again.  I cannot find any information about setting some sort of buffer limit or session timeout.  I feel this is a configuration, or mis-configuration issue. 

Has anyone run across this or maybe someone knows how to control this?  I will need to resolve this before I ship the equipment to a remote site.

Sam

[Richard Burts]

Sam

Can you post the configuration of the term server? Would you tell us whether the async lines are configured with the command no exec?

HTH

Rick

[samuel.d.knox]

As soon as I figure out how to attach the file I will.  I used to have "no exec" set for the lines 0/0/0 0/1/15 but I just noticed that the TAC support person must have removed them.

[Richard Burts]

Sam

I have not done a terminal server on a router running 15.1 code and maybe that changes some things. But here are my suggestions.

- first and most important - configure no exec on the async lines.

- if that does not address the problem then I would remove the encapsulation slip commands and see if that helps.

HTH

Rick

[samuel.d.knox]

Hey Rick,

Thanks for your time with this.

I tried to add the "no exec" command to interface async 0/0/0 but it doesn't have "exec" in its list of config items.  Are you referring to "lines 0/0/0 - 0/1/15"?  I was able to put "no exec" back on them.  (see attached snippet)

I've reloaded the router to see if that helps as the first port I tried failed to clear.

< waiting for the router to boot up >

After the reboot I tried all of the ports and all of them responded.  I will check again tomorrow and report back in.

Sam

[samuel.d.knox]

Rick,

I just went through and connected to everything I have console cables to with no issues.  I feel that your suggestion to add the "no exec" to lines 0/0/0 - 0/1/15 solved my problem.

Would you happen to know why this occurred?  I assumed that "no exec" told the port that is configured for this that no commands can be executed but each of those lines are connected to the console port of my devices so I would want to execute commands once I logged in.  For example:  If I set up lines VTY 5 -15 with no exec, I can have five sessions established (vty 0 - 4) but will not be able to establish any more after that. 

PS.  I must be mistaken about having all of my lines set up with no exec prior to the TAC getting involved.  Unless this was how they determined the HWIC was bad and simply forgot to put it back after the RMA. 

Thanks for the assist.

Sam

[Richard Burts]

Sam

In my experience probably the most common problem that people have when they are trying to set up a terminal server is that they do not have the no exec command on the async lines. What the no exec does is to tell the terminal server to not execute any commands that come in on that line.

When you think about it when you use the terminal server to connect to a remote device and you enter a command you want that command to execute on the remote device and not to execute on the terminal server.

I am confused about the comments that you make about no exec on the vty lines. You are quite correct that if you include no exec on vty 5 - 15 then you will be able to create remote sessions only on vty 0 4. But what does that have to do with no exec on the async lines used for reverse telnet?

HTH

Rick

[samuel.d.knox]

Rick,

My "no exec" on the vty lines comments was an attempt to explain what I understood about the "no exec" command.  In my group they developed a standard where we set up vty lines 0 - 4 for access (telnet, ssh) yet put the "no exec" on vty lines 5 - 15.  Apparently they wanted to limit how many network engineers would offer to help during any troubelshooting event. 

I really don't know what the full extent of those async line's capabilities can be on a terminal server as we have only ever used them purely for console access into other devices.  But with your explanation as to what is going on coupled with the effects I have seen, the entire issue has become much clearer for me.  It is very obvious that the terminal server is flooding those async lines with some sort of data.  By issuing the "no exec" it blocks that data from passing over to the far end device's console port, which in turn prevents it from locking itself out.  I know that is a real rough explanation and maybe someday when I have time I will find a way to see exactly what is going on.  In the meantime I am back to being able to get to all of my devices now. 

Thanks for your time on this one. 

Sam

[Richard Burts]

Sam

Thanks for the explanation about no exec on the vty. Your understanding is correct that doing this will limit the number of remote connections (SSH or telnet) to only 5.

I am glad that you have been able to resolve the problem that was impacting your terminal server and that you can now access your devices.

HTH

Rick