Basic I know but is driving me mad. Am writing configs in notepad then copy/pasting to new swicthes - after about 1/2 the config copies in (sucessfully) - I start to lose data in the copy process - is this to do with memory buffers somewhere ? (Dont tell me to tftp - thanks)
Are you using hyperterminal?I have seen this issue as well in the past. Try Putty/Secure CRT.
If you have to use hyperterminal, try changing ASCII set up(increasing line delay). You can do this under File > properties > settings > ASCII setup
I've had issue with copy/paste commands and up/down arrow keys. Cisco provided following config and after that worked fine for me!
line con 0
I am new to this community and wondered if anyone has experienced the problem of when I copy and paste a whole config file into any of the emulators I have tried ie. Tera term, HyperTerm and Putty
with a Cisco 800 series router, the commands end up going in triplicate into the router.
Eg. Router# hostname router1
Router# hostname router1
Router# hostname router1
I do split the the amount I copy and paste rather than take the whole config at once.
This does not create any problems to the router working but obviously not easy to read.
Thank you in advance.
I know that is a really old post.... but we still facing the problem .... and is great do not be alone
I found this site with a short awk script that working great for me
thanks a lot for a good Forum
I solved my problem!
I take my config information from a spread sheet format.
If I open it in Notepad ++ and show all information it includes all my ! and spaces.
This is the reason for the triplicate entries.
Thanks for posting back to the forum and letting us know that you have solved your problem. It is good news when someone posts about a problem and then is able to find the solution to their own problem. Congratulations to you.
It's a problem with flow control between the switch and your terminal emulator. It's never been more than s slight annoyance with me so I never messed with the settings to figure out what it was specifically. I just paste the config in to the device in several smaller sections.
this problem differs from device to device:
You can copy quite large amounts of text into a router's console, but switches can handle not that much lines at one time. Access Points are even worse.
I guess this is indeed caused by the CPU/memory of the devices.
Prashanth is quite right in his explanation that the paste function is out running the input buffer of the router or switch. And correct that configuring line feed delay (or even character delay) will slow down the paste and allow the router or switch to catch up.
He is not correct in associating this problem only with Hyperterm and suggesting that SecurCRT would fix it. I have experienced the problem with SecurCRT.
Ive recently encountered this problem with SecureCRT and ive come to know that its your terminal emulator (SecureCRT, putty etc) that has some issues ! in secureCRT you have to go to session options by right clicking on the TAB if you have a prompt open, and go into Modes beneath the Emulation category and Check mark "New line Mode", and i hope your problem will be solved if not...then try telnet from CMD of windows to the cisco device and do the pasting there it will surely work! because its not your Device that's faulty its your emulator
If you have other emulator's play around with their settings a bit and hopefully that will solve the issue
I am not sure that it is correct to assert that this is an issue with the terminal emulator. The problem is a mismatch between the speed with which the emulator can send text and the speed with which the router or switch can process the text. There are two ways to solve this problem. You can make the router or switch process faster (difficult to achieve) or you can make the emulator go slower (generally easy to achieve). But that does not mean that there is a problem with the emulator.
I would suggest that one way to look at it is that today's PCs and emulators have very high performance levels and are capable of sending text very quickly. And in some cases we want the high performance quick transmission of text while in other cases we want to slow down the rate of transmission. So the high rate of transmission from the PC and emulator is really an advantage and not a problem.
Yes thats technically true what you have said, but my SecureCRT was copy and pasting just fine when all of a sudden i couldn't do that anymore, then i did a telnet to the switch and copy and pasted from there, and it worked like a charm.... then i fixed the problem in SecureCRT like i have posted above.
What do you make of that Mr.Richard Burts?
And another thing, I did a telnet from windows CMD and it worked! but when i did a telnet from SecureCRT it didn't, so clearly the emulator went buggy
I find Teraterm works a treat for your type of scenerio, These are the settings I use from the Terminal window:
Setup - Window - Scroll buffer 10000.
Setup - Serial port setup - Transmit delay 1msec/char.
If copy/paste from SecureCRT was working fine and then it became a problem then what I make of it is that something changed. It might have been a change in the connection to the device which allowed a greater amount of traffic, it might have been some change in the device which slowed down its ability to receive and execute the config commands, it might have been a change in the PC which allowed faster transmission for this connection, it might have been the result of some software upgrade, it might have been the result in changing settings in SecureCRT, it might have been that previously you were working with relatively smaller config changes (in which buffering was not as critical) and now are working with larger config changes (in which buffering does become critical). We do not have enough information to assesss what changed, but I am certain that something changed.
You can describe it as the emulator went buggy and perhaps from your perspective that is an accurate assessment. From my perspective encountering a situation where the sending device has greater capacity than the receiving device does not mean that the emulator is flawed.
Teraterm is a fine emulator but it would be quite similar to SecureCRT in that you need to configure settings to control the speed at which you transmit (which is what you tell us that you did) and if Teraterm send data at full capacity then it would be likely to have the same mismatch issues that SecureCRT has.
Am writing configs in notepad then copy/pasting to new swicthes
This is "old school" method.
Let me ask you the following questions ... How many minutes does it take you to build a switch? (When I mean "build", I mean configure the switch and upgrade/downgrade the IOS to the standard of your network.) How many minutes will it then take you to build a brand new pile of, say, 20 switches?
What if I can tell you it'll take, an average, about 20 minutes to "build" just one switch. Now, what if I say that I can build a pile of 20 switches in 20 minutes. Here's the icing ... What if I say "I can build a brand new pile of 20 switches in 20 minutes ... without even touching the keyboard". Are you still interested?
Welcome to the conversation :)
Yes that approach is "old school" and the post that mentions it is 6 years old. But please do enlighten us about how you would build a new pile of 20 switches "without touching the keyboard".
Yes that approach is "old school" and the post that mentions it is 6 years old.
Gawk! I didn't see the "age". :(
But please do enlighten us about how you would build a new pile of 20 switches "without touching the keyboard".
Since 12.2(55)SE2 and later, Cisco has introduced a feature called Zero-Touch SmartInstall. You plug an ethernet cable to your new switch (no config). The SmartInstall "director" will identify the model of the switch via CDP and, if the switch model is in the "list", the "director" will push the config to the new switch's startup-config and, optionally, upgrade the switch IOS. All complete in 20 minutes.
There's a reason why it's called Zero-Touch: Hit any keys (except the Shift key, of course) on the keyboard and the process stops.
I've been using (still using until now) this since 2011 and we haven't looked back. As a matter of fact, we can't take it out anymore because it's an integral part of our tools.
Read this: How to use Zero-Touch SmartInstall
Any suggestions? Increase the Line send delay above 5 or lower it? The default emulator in SecureCRT seems to be VT100 but Putty is xterm. Could that be the issue.
I've experienced this truncating / random line missing issue twice now. Both caused major problems on our network as we save ACLs in a txt doc and then copy them into the switches. When i copied the ACL in it has an "end" and "exit" so it kicks me out of the switch and that did happen so i thought the ACL copied all the way. I've had issues where it flat out stops copying halfway and the solution is to just do smaller junks of data, and thats not a big issue. The issue is that i have to copy the ACLs from the switch back into notepad++ and figure out which lines are missing from the correct ACL. And these are lines that i didn't touch / are old so its not syntax or something like that related. Random lines of the ACL disappear. We used to have a GLBP setup (now using VSS) but have some distributions running GLBP still so i have to copy the ACL to both switches. I've seen one switch be fine and the other missing random lines.
The problem is not related to emulating VT100 or xterm or anything like that. The problem is that the PC is capable of sending text faster than the network device (router or switch or whatever) is capable of processing it. With smaller amounts of text to send the network device is usually capable of buffering and processing the changes. But as the amount of text increases you get to a point where some of the text is dropped. This would explain why it seems to be random lines and that the exit/end command at the end of the file would be processed while some lines in the middle might be dropped.
If the same set of commands were processed without problem on one switch and had problems in another switch then I would guess that either there is some difference in processing capability between the switches, or that one switch was able to dedicate all its processing capability to your config changes, while the other switch had some processing requirements for other tasks during your config change and could not dedicate all of its processing resources to your config changes.
The answer is to slow down the rate at which you send the text. Increase the line delay will help or solve the problem. Lowering the line delay would make the problem worse.
The easiest solution I've found for this is using Rutty (Putty with a few additional features for scripting).
Rutty allows pasting text files with fixed inter-character delays and fixed inter-line delays. Thus you can take a massive configuration, configure the line delay to be 200ms (or however much you find necessary), and then paste the configuration.
As far as I can tell, no other free TTY software supports this feature.