SecureCRT sending commands to multiple sessions.

I came across this in secureCRT and thought I would share it.

When labing things up (and indeed on real networks), there are times when you need to send the same command to multiple devices. you can of course copy and paste between the sessions but what about if you want to past the exact same block of configuration to 20 devices, or just want to do something simple like save the running configuration on your devices in you lab before you close down?

Well SecureCRT has a nice little feature to do this, so before enabled secure CRT looks much like below, as you can see I have several tabs open.

Default SecureCRT Window

However by going in to the view menu up the top there is a option to enable the “chat window”, this will bring up an extra panel at the bottom of the screen. Then by right clicking in this new panel you can enable the “send chat to all tabs” option as shown below.

Chat window enabled

Now any command typed in the chat window will be sent to all devices. Commands typed in the main terminal are still only sent to a single device.

What would be even nicer is if you could highlight multiple tabs and have the commands only sent to those terminal sessions. At the moment it is an all or nothing solution, maybe I will go suggest it to them as an improvement for future versions 🙂

The more I use CRT the more I like it, written quite a few scripts for it now, if you know any VB script or Java you can pretty much do what ever you like as SecureCRT has a nice simple API in to it.

I am finally moving house this week, so after that should have more time to post on here, and will take some of the script I have and tidy them up and post them for people.

Take care

DevilWAH

I need to learn more C#

Been playing around with it a lot, but come to the conclusion that I need to learn a bit more out of a book, than just using google and Microsoft sites. To be fair not done badly just a few areas I have been working on lately the code is a bit messy and I know there must be a better way to do it. So to help me on my way I have done two things.

Number one. Brought a Kindle, or to be more accurate my wife has got me one, just awaiting its arrival.

Number two. Getting hold of “Headfirst in to C#” and a few other C# books for it.

Hopefully by the end of this week I will have achieved the following in my application.

  1. Added controls to the output form for “Next config” and “Cancel”, Plus a button to copy to clipboard or download to file.
  2. Added the ability to create a single output from multiply lines in the entry form, and ability to chose a single line and out put only that config.
  3. After that I will be adding a header and footer section to the templates, that will all user to enter varibles aht are to be standard to all configs. Things like company information, user name, date, etc.

All simple stuff but just making sure it do it right now so when it comes to updating later it is all nice and clear. All about adding controls at run time at the moment and making sure its done in the most efficient way.

ConfGen update.

Spent quite a bit of time lately with this, the more I get in to C# the more impressed I become, I use to think that C# and .NET where only for people who couldn’t learn C++, but now I see the point. C++ is fun to learn, but it is very involved and I know I would be no where near as far along with this if I had decided to go down that route. OK C# requires the .NET framework to be installed on the client machine, but as for as developing goes it hit a nice sweet-spot, between the simplicity of VB, and the maze of C++. I would definitely suggest any one wanting to develop Window based applications to have a look.

As for ConfGen made a number of changes to the code to add some more functions, but still got lots more to do, see the ConfGen Page above for more details. This really is the middle application in terms of the long term goal. I also want to produce a tool that will build configs from scratch based on users specification, and a final implementation tool to deliver configuration to devices.

Also it looks like soon I should have a bit more time at work so CCNP study will be back in the picture. Thinking maybe to buy a Kindle and get the CCNP Foundation Guide as an Ebook, the hard back is just to heavy to lug around, so having it to hand on the Kindle for any spare time i get would be great.

Anyway back to some more coding now.

DevilWAH

CISCO commands

Just lately while cleaning up things at work, and on the web I have come across some CISCO commands that are usefully but often over looked, or forgotten. So I thought I would write them up here and attach them to the Tips and Tricks page so I would always have them to hand. IT might start of a small list but I hope to increase it gradually as I remember/find more. Think of it as a work in progress which you can find here.

I also though as well as the useful ones I would create a common list as well. These are things like the #show IP interface brief, and show Interface status. Again a work in progress and found under the tips and tricks page. If you have any ides suggestions for things that should be included let me know.

I don’t want to have a list of every command on CISCO, but the common ones we all use daily and take for granted. Or ones that are not quite so well known but very useful nevertheless

As I say the lists are no way completed, but I have put up the pages so I can start adding thing on, as and when I think of them.

DevilWAH

Applying a configuration to a CISCO device using xmodem.

Last week at work now, so been rushing to get things sorted out. I have still been doing a bit of study and planing some more ROUTE posts, but with a broken down car and house sale looking like its falling through haven’t had time to do any actually real posting.

However I came across something today, that I have known about for a while but never really used much. One of the things every one seems to love about CISCO is the fact you can simple copy and past configurations in to the terminal emulator window.  And this is indeed great. set up one interface, copy the config to notepad, update it as you wish and past it back in… A real time saver and why we all love CISCO more than Microsoft ;).

In the past this is also how I have always copied backed up configurations on to a new switch/router. Simply open the saved config in notepad. Ctrl-A to select it all, copy and paste to the device. However I was doing this today and hit an issues. With really large configuration files (500+ lines of configuration), I was watching the console windows and could see it was skipping some of the configuration when doing this connected through the serial port. I could see that while things like VLAN’s where being created and the device was pausing, the following lines would some times get lost or corrupted. Now while if you only have a small size configuration file this is not an issue as it is quite easy to check, hundreds of lines become very hard to validate.

I found the best way around this problem was to set up the device with an IP address, put it on a limited access network that has a TFTP sever and copy over the configuration file, either to the startup-config or running-config. This works fine but it is a bit of a hassle going to all that trouble and it means you have to connect the switch to the network, so you have to be very careful with things like VTP and spanning tree. What I really wanted was a way to send the configuration file through the console port.

This made me think of how to recover a corrupted IOS image (which you can fine in the tips and tricks link above). Where boot the device in to ROMmon mode, and then copy the IOS over using the xmodem protocol. Almost all the mainstream terminual emulators have this built in, and while for recovering the IOS you need to increase  the baud speed of the console port to speed up the copying process, as the configuration file is only 20-30kb max for most people, the standard speed will move that across in a few seconds.

So then it is just a case of knowing the command to achieve the goal, and I was happy to see it is as simple as it should be. On the device simple type the following from the enable prompt.

router#copy xmodem: startup-config

That’s it, no file names or anything, the device will now wait to receive the file(if you do not start the transfer within a few minutes the device will time out waiting). Then in your terminal emulation program start the transfer. In teraterm it is under the file menu, while secure CRT has a whole menu structure dedicated to various methods to transfer files. Simple chose the xmodem protocol (I found selecting the 1K option was more reliable), and browse to the configuration file, and away it goes. A few moments later the configuration will be on the device (#show Flash: to confirm), and a reboot will have it all up and running.

To me this is a far more reliable way of copying large configurations across, and allows you to easily set up the device from any client, this can be very useful if you are out on site and don’t have access to a limited access network, or the TFTP server to use to copy the files via TFTP or FTP using the network.

DevilWAH.

PS. Some older routers don’t seem to like you copying from xmodem to nvram, or require you to give a source file name. But you can still achieve the same by copying the file to Flash: .

PPS. Although I prefer the xmodem method, you can improve the reliability of the copy/paste method by increasing the line/character delay in you terminal emulation program. A 5msec delay per character seems to help, although with a 1000+ lines of configuration you may get from a complex configuration, you may find the paste takes a little time, and you may still get errors.