<

Go Premium for a chance to win a PS4. Enter to Win

x

Copy Files to a Router through Telnet and why we need it

Published on
3,768 Points
768 Views
Last Modified:
Predrag
Just another network engineer...
Use of TCL script on Cisco devices:
 - create file and merge it with running configuration to apply configuration changes
The reason for article is question here on EE - startup config modification.
 
Sure, modification of a startup file can be done. I did it for some testing purposes, but I would not recommend that approach in the production environment.

Warning:
I am not good at writing articles, so this can be hard to read.

I am network engineer that work in large enterprise environment and I am always at least a few hundred kilometers away from network equipment and often there is no one present on site during maintenance windows except for hardware refresh. However, during hardware refresh, placing devices in rack and patching is done by a third party company that have no access to devices so anything more than power cycle of a device is not an option.

Modification of a startup file can result with an inaccessible device after power cycling (bad IP address, bad gateway, bad route, typo... could be anything) that's why I am strongly NOT recommending this approach.
What I believe is a good approach for changing parameters that will cut you off of device is preparing a file with all necessary changes and then issue it from the device itself. So, basically you have a backup option - startup configuration will not be changed and if the device is power cycled manually, or by reload command, it will be accessible again.

Let me explain it in one simple example - change of IP address range for management VLAN.

IP address management interface VLAN and the IP address default gateway on the device need to be in the same range, for a device to be accessible over the internet. On Cisco IOS changes are immediately applied after typing command and pressing enter key on keyboard.

Basic problem that should be solved somehow is - change of management IP address or default gateway address will cut us off of the device. Both need to be changed simultaneously. Creating configuration changes on text file, placing it on some TFTP server, copy it to device sometimes is also unavailable or simply is not preferred solution for some reason (like: it can take a lot of time).

To go around all of these problems I use TCL scripting.
You are still reading? Hmmm

OK, let's go to for the real thing, this intro is boring.

Configuration of the device that need to be changed (change of interface and default gateway IP addresses).

StartConfig.PNG
TCL script to create file with new IP addresses (hostname change is performed just to make it more obvious).
tclsh
puts [open "flash:TEST" w+] {interface fa0/0
ip address 172.16.0.10 255.255.255.0
ip default-gateway 172.16.0.1
!
hostname DistantRouter
!
}
tclquit

Open in new window


Paste TCL script into terminal software. CreateFileWithTCL.PNGIMPORTANT!
If you are doing this from remote location your best friend is reload in command
Reload.PNGChecking flash is file created, check configuration in the file and merge commands from file with running configuration.

IssueTEST.PNGError message can safely be ignored (Cisco Bug). Hostname is changed, let's check interface IP address and default gateway IP address.

NewConfig.PNGLooks good. If the device, after adding commands, into running configuration is correct do not forget to save changes and to cancel reload
DistantRouter#wr mem
Building configuration...
[OK]
DistantRouter#

DistantRouter#reload cancel
DistantRouter#


***
*** --- SHUTDOWN ABORTED ---
***

DistantRouter#

Open in new window


Now original problem with changing startup configuration. We can apply the same solution.
Currently  by default startup configuration on new Cisco devices can be found on flash stored in config.text file (e.g 2960-X), on older devices startup configuration is present in nvram.

This is GNS3 example (and no more pictures).
DistantRouter#copy startup-config flash:
Destination filename [startup-config]?

402 bytes copied in 0.536 secs (750 bytes/sec)
DistantRouter#

Open in new window


Now we have file with current startup configuration present on flash (startup-config).
DistantRouter#sh flash:
-#- --length-- -----date/time------ path
1          111 Mar 01 2002 00:24:58 TEST
2          402 Mar 01 2002 00:33:56 startup-config

133971968 bytes available (8192 bytes used)

Open in new window


To get config issue:
DistantRouter# term len 0
DistantRouter#more flash:startup-config
!
!
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname DistantRouter
!
!
********* lines omitted for brevity *****
!
!
line con 0
 exec-timeout 0 0
 logging synchronous
 privilege level 15
 no login
line aux 0
 exec-timeout 0 0
 logging synchronous
 privilege level 15
 no login
!
!
end

DistantRouter#

Open in new window


We have template. Then, copy everything into notepad++ (or whatever is convenient for you), change what you want and use TCL to copy new startup configuration into flash. I used file name startup-config to overwrite old startup-config file on flash (in example hostname is changed)



tclsh
!
!
puts [open "flash:startup-config" w+] {!
!
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname NEWHOST
!
!
********* lines omitted for brevity *****
!
!
line con 0
 exec-timeout 0 0
 logging synchronous
 privilege level 15
 no login
line aux 0
 exec-timeout 0 0
 logging synchronous
 privilege level 15
 no login
!
!
end

}
tclquit

Open in new window


Paste TCL script with modified configuration into terminal software (typically in small chunks).
Check is everything is copied as it should by using more flash:startup-config and replace startup configuration in nvram.

DistantRouter#copy flash:startup-config startup-config
Destination filename [startup-config]?
[OK]
1128 bytes copied in 0.120 secs (9400 bytes/sec)
DistantRouter#

Open in new window


GAME OVER

Reasons why I consider the first approach much better (flexibility that is missing in the second approach):
  • If the device with changed running configuration become inaccessible it will reload itself and become available again (or ask someone to power cycle device for you if you forgot to schedule reload - startup configuration is not changed prior to reload)
  • If the device with changed running configuration is available,  you need to check configuration changes, save configuration and cancel reload (even if you don't do any of it - device will still be available after reload)
  • No need to reload device if changes were successfully applied
Obviously, all that flexibility is missing in the second approach.

Cisco article - Copy Files to a Router without File Transfer Access

 
0
Comment
Author:Predrag
0 Comments

Featured Post

NEW Veeam Agent for Microsoft Windows

Backup and recover physical and cloud-based servers and workstations, as well as endpoint devices that belong to remote users. Avoid downtime and data loss quickly and easily for Windows-based physical or public cloud-based workloads!

Join & Write a Comment

In this brief tutorial Pawel from AdRem Software explains how you can quickly find out which services are running on your network, or what are the IP addresses of servers responsible for each service. Software used is freeware NetCrunch Tools (https…
Monitoring a network: why having a policy is the best policy? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the enormous benefits of having a policy-based approach when monitoring medium and large networks. Software utilized in this v…
Suggested Courses
Course of the Month8 days, 22 hours left to enroll

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month