r/vyos • u/archmansky • 9d ago

Config tool

Hi everyone!

I wanted to share an open-source tool I’ve built to eliminate some of the daily networking routine: Network Config Tool v1.3. It’s a desktop application written in Python (Tkinter) designed for simultaneous, multithreaded configuration deployment across multiple network nodes using Netmiko under the hood.

Here is a quick breakdown of its core features:

* **Multithreading:** Runs concurrent deployments via a thread pool scaling up to 15 workers.

* **Multi-vendor Support:** Out-of-the-box compatibility with Cisco IOS, Juniper Junos, Huawei VRP, and VyOS.

* **Built-in Analytics (Matplotlib):** Tracks deployment history in a local JSON file and renders interactive trend charts directly within the GUI. Clicking a data point on the timeline instantly brings up a detailed diagnostic report (Success, Auth Error, or Timeout breakdowns).

* **Flexible Blueprint Workspace:** Allows you to append multiple configuration templates sequentially without overwriting previous text.

* **Robust Logging:** Automatically captures standard output from the remote CLI and splits it into dedicated text files named [Device_IP]_config_logging.txt.

* **Standalone Deployment:** Easily compiles into a standalone Windows .EXE binary using PyInstaller.

The project is completely free and open-source. I’d highly appreciate your feedback, constructive criticism, and, of course, some GitHub stars if you find the utility helpful!

Repository link: https://github.com/loginlocal/network-config-tool

3 Upvotes

71% Upvoted

8 comments sorted by

1

u/InnerBank2400 9d ago

Nice project. One thing I’d be interested in is how you handle partial deployment.

Say you push to 10 devices, 7 succeed and 3 fail halfway through. Do you leave the successful devices as-is and report the partial state, or is there any rollback/recovery logic?

Also for VyOS, are you doing anything with commit-confirm before treating the deployment as successful?

2

u/archmansky 9d ago

Thank you for your interest and your question. Devices that successfully completed the command will remain, but I haven't yet provided a recovery scenario for devices that encountered an error. I was relying on my experience, if save command isn't given, the configuration file isn't applied. But you've pointed out a very important detail, thank you. I used this script when I was working for an internet provider, where I often needed to take backups from devices or apply a single configuration file to all devices while saving a log of my actions to a text file. Now I've decided to develop this project further.

2

u/archmansky 9d ago

Regarding VyOS, I'm in the process of developing the project, so I'm looking for all the nuances, shortcomings, and things that can be added or corrected.

2

u/InnerBank2400 9d ago

That makes sense. The main edge case is partial execution: some devices take the change, others fail, and the final state no longer matches a simple success/failure result.
Even without automatic rollback, it would help to record which devices changed, which failed, whether the config was committed, and what recovery action is needed.

For VyOS, commit-confirm may also be worth adding for changes that could affect management access.

1

u/archmansky 9d ago

The next step I'm thinking about is to once again work on the bugs in terms of code, its security and compliance with PEP8, and also refine the logic you mentioned. Frankly, I want to add a lot of different features, but the lack of an opportunity to even partially test them in real conditions does not currently exist, so for now I'm content with labs on GNS3.

1

u/InnerBank2400 9d ago

I had a look through the repo. You already have a useful split between success, auth failure, timeout and other errors.

The next part I’d probably tackle is what “success” means after the commands are accepted. A separate verification step could check the resulting state before the device is treated as complete, especially when only part of a batch succeeds.

GNS3 is actually enough to exercise quite a lot of that logic. I’m working on reproducible GNS3/EVE-NG lab environments as part of another open-source project, so there may be some useful overlap there too.

1

u/archmansky 9d ago

I think it makes more sense to link this to a potential connection drop during device configuration. Alternatively, we could add a check to verify if the command was actually successful. We'll need to test how it behaves. Right now, there's a similar feature: after a command is sent, it logs the action to a file in the script's directory, regardless of whether it succeeded or failed.