On the surface, this is very easy to do. You would create a parameterized Netconfig template to deploy your IP address change. Your template would look like:
interface Vlan 1
ip address $address 255.255.255.0
Then, your parameterized command file would look like:
However, when this job runs, RME will no longer be able to access the switches after it deploys the commands. It will therefore now be able to determine if the deployment succeeded, and thus mark the job as failed.
You will also need to go into DCR after making this change, and update the IP addresses there (if you are keeping IPs in DCR). This could be made easier if you export the DCR data, change the IPs in bulk, then re-import the file.
No. First, you're using a user-defined template, so there is no inherent knowledge that what you're doing would affect manageability. Second, you could be changing just some arbitrary interface address, and not the management address.
We are looking at automatically grouping unreachable devices for LMS 3.2. This way, it would be up to the user if they want to purge these devices in one shot.
3) Change tftp source int., ntp source and delete old Vlan interface
4) Change DNS
After the device discovery job finishess, the devices automatically appear in the DCR with new IP address, without the need to change this manually.
It would be great thou if some tools are embedded in Ciscoworks for creating parameter files in the new version.
Also a little more tooling to create and modify default configuration templates files are welcome, so life can be a little easier ;))
It would also be great if you can see in groups (for e.g. day, week , month, year) which devices weren't reachable, so the user can choose to delete them from the DCR or not. Can't wait for version 3.2!
Hi everyone, I would like to thank you in advance for any help you can provide a newcomer like myself!
Im studying the 100-105 book by Odom and am currently on the topic of Port security. I purchased a used 2960 and I'm trying to follow a...
While deploying a number of 18xx/2802/3802 model access points (APs), which run AP-COS as their operating platform. It can be observed on some occasions that while many of their access points were able to join the fabric WLC withou...