Network automation
Sharing our progress on this:
("right click > Open image in new tab" to see full resolution)
![](https://promo.unimus.net/promo-images/config-interact/ci-home.png)
![](https://promo.unimus.net/promo-images/config-interact/ci-presets.png)
![](https://promo.unimus.net/promo-images/config-interact/ci-active.png)
The idea is that you can create network automation presets yourself, and then select which devices to run on.
This can be useful for both config pull (read) and config push (write) purposes.
Device output will automatically be grouped for ALL devices that output the same output.
Meaning this can also be used to spot inconsistencies in command output over the network.
Example 1:
On MikroTik, show me which devices have IPv6 package enabled:
Command:
We select 20 MikroTik to run this on.
We would get 3 output groups.
Group 1 would have 6 devices.
Group 2 would have 12 devices.
Group 3 would have 2 devices.
Group 1 output would be:
This means that on these 6 devices, IPv6 is enabled.
Group 2 output would be:
This means that on these 12 devices, IPv6 is disabled.
Group 3 output would be:
This means that these 2 devices do not have IPv6 package installed at all.
Example 2:
Let's enable IPv6 on the 12 devices where it is disabled.
We just create a new automation preset, and the command would be:
We run this, and Unimus will send this command to the 12 devices.
We would just have 1 output group, which would be empty (no output).
(this is because there is no output on successful command execution)
Example 3:
Deploy a new VLAN on 20 HPE Comware switches.
We create a new automation preset, this time requiring Unimus to switch the device into "configre" mode.
Commands would be:
We run this preset.
We get 2 groups.
Group 1 would contain no output - this was received on 19 devices.
This means these 19 devices ran these commands without issue.
Groups 2 - we get 1 devices which has different output.
When checking out the output, we would see that one of the commands failed with "not supported".
So we know our config was successfully pushed to 19 devices, and one failed.
Final words:
We are hoping this flexible system will allow you to easily create automation presets as you need around your network.
We are very opened to any feedback on this - so please tell us how you feel about this.
("right click > Open image in new tab" to see full resolution)
![](https://promo.unimus.net/promo-images/config-interact/ci-home.png)
![](https://promo.unimus.net/promo-images/config-interact/ci-presets.png)
![](https://promo.unimus.net/promo-images/config-interact/ci-active.png)
The idea is that you can create network automation presets yourself, and then select which devices to run on.
This can be useful for both config pull (read) and config push (write) purposes.
Device output will automatically be grouped for ALL devices that output the same output.
Meaning this can also be used to spot inconsistencies in command output over the network.
Example 1:
On MikroTik, show me which devices have IPv6 package enabled:
Command:
Code: Select all
/system package print where name=ipv6
We would get 3 output groups.
Group 1 would have 6 devices.
Group 2 would have 12 devices.
Group 3 would have 2 devices.
Group 1 output would be:
Code: Select all
Flags: X - disabled
# NAME VERSION SCHEDULED
0 ipv6 6.36.4
Group 2 output would be:
Code: Select all
# NAME VERSION SCHEDULED
0 X ipv6 6.36.4
Group 3 output would be:
Code: Select all
Flags: X - disabled
# NAME VERSION SCHEDULED
Example 2:
Let's enable IPv6 on the 12 devices where it is disabled.
We just create a new automation preset, and the command would be:
Code: Select all
/system package enable ipv6
We would just have 1 output group, which would be empty (no output).
(this is because there is no output on successful command execution)
Example 3:
Deploy a new VLAN on 20 HPE Comware switches.
We create a new automation preset, this time requiring Unimus to switch the device into "configre" mode.
Commands would be:
Code: Select all
Vlan 110
description new-vlan
igmp-snooping enable
mld-snooping enable
We get 2 groups.
Group 1 would contain no output - this was received on 19 devices.
This means these 19 devices ran these commands without issue.
Groups 2 - we get 1 devices which has different output.
When checking out the output, we would see that one of the commands failed with "not supported".
So we know our config was successfully pushed to 19 devices, and one failed.
Final words:
We are hoping this flexible system will allow you to easily create automation presets as you need around your network.
We are very opened to any feedback on this - so please tell us how you feel about this.
This sounds fantastic! I'm new to Unimus.
What sort of features will you be developing in terms of per device configuration?
Would be great to push out a default config to all devices enabling MPLS/Setting MTU etc as a base.
Then pushing out updated configs based on Unique Site info. (VPLS ID's VLANS, IP Addresses ...)
Edit: Using info from Google Sheets or NetBox API etc.
What sort of features will you be developing in terms of per device configuration?
Would be great to push out a default config to all devices enabling MPLS/Setting MTU etc as a base.
Then pushing out updated configs based on Unique Site info. (VPLS ID's VLANS, IP Addresses ...)
Edit: Using info from Google Sheets or NetBox API etc.
I'm super excited about this. This will save me soooo much time and headache as I know the commands I want to run, but don't want to have to learn ansible or another ACS to get it done.
Thank you Tomas!
BTW, I'd like to offer to beta test this feature once you start rolling it out. I have a variety of devices in my network which would allow for a wide range of tests. Brocade VDX Switches, Extreme Summit switches, Mikrotik routers, HP switches, and even UBNT switches
We are hoping to have this publicly available in a Beta release in a couple of weeks.
We will also be sending out a newsletter asking for help with testing, since the Beta release will also contain other major changes.
List of things in the coming Beta:
- credentials binding (use only one particular credential on a device)
- enable passwords (specify a list of enable passwords, rather than Unimus using just users password to switch to enable / configure)
- enable password binding (use particular enable password on device - by default enable password is discovered)
- subnet scanning (device discovery by scanning subnets)
- mass reconfig / device interaction (the feature we talked about here)
Since this is such an extensive Beta release, we will want as much testing as possible.
More news soon![Smile :)](./images/smilies/icon_e_smile.gif)
We will also be sending out a newsletter asking for help with testing, since the Beta release will also contain other major changes.
List of things in the coming Beta:
- credentials binding (use only one particular credential on a device)
- enable passwords (specify a list of enable passwords, rather than Unimus using just users password to switch to enable / configure)
- enable password binding (use particular enable password on device - by default enable password is discovered)
- subnet scanning (device discovery by scanning subnets)
- mass reconfig / device interaction (the feature we talked about here)
Since this is such an extensive Beta release, we will want as much testing as possible.
More news soon
![Smile :)](./images/smilies/icon_e_smile.gif)
Supremely interesting. One thing stands out though and it's the ability to push a file. In the mikrotik example above, the third group did not have IPv6 package installed. How would we push this package? If it's back to Winbox or FTP... Yikes.
Plus, this would be great for updates. Push the package, run the update. Not just M'tik but others too I'm sure.
Also, as an aside but the scripting (or maybe the UI?) should have a way to trigger some pre-execute and post-execute backups if desired (with a comment on each if possible)
So taking M'tik as my use case, process looks like this:
This is our SOP for all updates so would be essential for an automation tool to do just that.
Yes, a scheduled backup was possibly taken last night/last week/whenever.
Don't care.
Backup NOW pre update, backup again NOW post update.
Period.
This exact process saved my bacon last night pushing 6.42.1 to a bunch of routers. Some changes in 6.41 happened and some of the routers updated were only on 6.40.x Due to a known vuln, we pushed 6.42.1 hurriedly and were not aware of some of the changes and couldn't vet 6.42.1 in every scenario. The result broke some routers and blocked LANs from reaching WANs. Not good.
Because I was able to diff the pre and post backups I quickly spotted the changes, Ms. Google provided some details, and I quickly could push a fix.
Could this have been done from the sched'd backup and from an on-demand backup pulled at the "oh shit" moment? Yes. But this is save-your-bacon automation. Why wait and take chances?
Anyway, this looks like great first steps. Look forward to seeing and trying the beta, thanks.
Plus, this would be great for updates. Push the package, run the update. Not just M'tik but others too I'm sure.
Also, as an aside but the scripting (or maybe the UI?) should have a way to trigger some pre-execute and post-execute backups if desired (with a comment on each if possible)
So taking M'tik as my use case, process looks like this:
- Pre-exec 1 = take a backup, set Comment "pre x.yy.z update"
- push "\\SomeShareSomewhere\masterimages\mtik\mipsbe\x.yy.z.npk" to "/" (e.g. for root of mtik file system - or whatever's appropriate for that platform) Possibly push could even be "http://mikrotik.com/downloads/x.yy.z.npk" to grab straight from the web/source maybe and push to our share as well for archival.
- /system reboot (because that's how m'tik updates happen)
- Post-exec = take a backup, set comment "post x.yy.z update"
This is our SOP for all updates so would be essential for an automation tool to do just that.
Yes, a scheduled backup was possibly taken last night/last week/whenever.
Don't care.
Backup NOW pre update, backup again NOW post update.
Period.
This exact process saved my bacon last night pushing 6.42.1 to a bunch of routers. Some changes in 6.41 happened and some of the routers updated were only on 6.40.x Due to a known vuln, we pushed 6.42.1 hurriedly and were not aware of some of the changes and couldn't vet 6.42.1 in every scenario. The result broke some routers and blocked LANs from reaching WANs. Not good.
Because I was able to diff the pre and post backups I quickly spotted the changes, Ms. Google provided some details, and I quickly could push a fix.
Could this have been done from the sched'd backup and from an on-demand backup pulled at the "oh shit" moment? Yes. But this is save-your-bacon automation. Why wait and take chances?
Anyway, this looks like great first steps. Look forward to seeing and trying the beta, thanks.
We are planning to add SCP/SFTP/FTP connectors.
Once those are implemented, file push will be come possible as well.
Until then, only commands can be pushed.
This would indeed be useful, I created a ticket:
https://tracker.unimus.net/browse/UN-319
That is a bit more complicated.
Since Unimus does unique backup grouping, the per-push backup comment would show up on the previous backup, which can have validity range of months (or longer).
We will need to come up with something that is both useful and transparent to users.
The Beta is now public, we would appreciate any and all testing
![Smile :)](./images/smilies/icon_e_smile.gif)
viewtopic.php?p=1004#p1004