freeztp
freeztp copied to clipboard
PackeTsar
v2.0.0 Objectives
ALL FREEZTP USERS: If you have used, intend to use, or could make use of FreeZTP, please leave a note in this thread. I am considering a full rewrite of FreeZTP for v2.0 and it will take a lot of time and is not worth it if there are not many people using it.
-
Full rewrite with modularity/abstraction between core engine and protocol handling (Adding in protocol handling for POAP as well as others).
-
Unit testing and CI functionality
-
New CLI handling library to ease integration of new features
-
Integration with Pypi for easier installation/updating
-
#61 - Full support for current Python3 (likely loss of Python2 support)
We're interested, however the CSV import function that you posted to the current dev branch may fulfill our requirements (will do some testing today).
We are testing out FreeZTP at my place of work, trying to figure out how to work it into our workflow and best integrate it with our existing tools. I would welcome modularity/abstraction and PyPi integration in a new version.
In the event this takes off and requests are being considered, I'll keep a running list here;
- Option to omit merged configs from ztp.log (lines 340, 382, 401, 420).
- Option to choose DHCP interfaces on install.
- Omit templates from ztp show config, show them with ztp show templates <opt: name>
- Move individual templates to separate files.
I am JUST starting to use it after years of following this project and never having the chance to do things My Way.
I'll let you know how this deployment goes.
I just deployed this and love it. A feature I would really like is the ability to point ZTP to a backup repository. Example, every switch nightly backs up to a tftp server, currently for me that is a win box. I could SMB share that to the ZTP server, just like I am mapping an SMB to the ZTP for the CSV and templates. Then I could point ZTP somehow to that drive and say, this serial matches this device so that if a single switch not stacked dies, could be swapped out and the serial updated so that it grabs the previous backup instead of a template. I realize I could do this now manually by creating a template with the backup config but I am hoping for something more automated.
We also have an in house network catalog. we are likely to be modifying it to put all the data that is in the CSV into the netcat and then auto export the CSV. Our netcat is a mysql db, if there was a way to point the external keystore to a mysql connection, that would be really cool.
Not quite sure about the first request. I cant really see how you would get ZTP to dynamically map between a merged template/keystore and a static template file.
On the second request, I am considering building an external keystore type for Netbox. This would possibly allow you to scan Netbox devices to find the serial, then pull device attributes from Netbox to fill in template variables.
Not quite sure about the first request. I cant really see how you would get ZTP to dynamically map between a merged template/keystore and a static template file.
I could create a backup on the switch that backs up, as an example, to the ZTP tftp with it's serial as the name of the backup. path could be \etc\ztp\tftproot\backups\ .When the switch dies, I replace it and grab the serial of the new switch. Then in the external keystore CSV, for the association "template" I put the serial of the old switch. maybe there is another variable that acts as a flag, call it backup_restore and when set to yes it knows to use the "backup store" and instead of sending a customized template, it just sends the backed up config of that serial listed in association.
The idea is a help desk jockey could swap out the dead switch and update a CSV on the 4th of July instead of me driving 4 hours in from the lake. :)
~~If a stack member dies, can't you just replace it with a clean switch (no config) of the same model that has a compatible OS version? The host interface configs for the replacement switch should remain as long as the switch {{sw_num}} provision {{model}} configuration exists in the config, no?~~
I suppose reading comprehension is key here...
...if a single switch not stacked dies...
Apologies.
No problem, so far everything I control is in a stack but I am bringing online a very large warehouse and a single switch for a hand full of APs in an isolated IDF is going to be unavoidable, not sure yet how many but enough that I would like to be prepared with a plan. This is a fringe scenario with modern switches having modular and dual PSU, it would make for a nice tool in the toolbox.
First of all, thank you for the great product, a nice feature will be an idarray or JSON that can support multiple mapping from serial to hostname. Based on research that I have done this seems to only be available in a flat keystore ztp keystore SERIAL001 hostname switch1.
The JSON can be ztp set keystore COMMON_SW settings '{ 'hostname': 'switch1, 'serial_number': 'SERIAL001'}, { 'hostname': 'switch2, 'serial_number': 'SERIAL002'}'
This will group switches so that it can be associated to the final template.
An external CSV keystore would probably be your best bet, and more feasible IMO.
keystore_id,association,idarray_1
SW-001,SW-TMPL,SERIAL001
SW-002,SW-TMPL,SERIAL002
SW-003,SW-TMPL,SERIAL003
You can also add multiple idarray's for stacks.
keystore_id,association,idarray_1,idarray_2
SW-001,SW-TMPL,SERIAL001,SERIAL004
SW-002,SW-TMPL,SERIAL002,
SW-003,SW-TMPL,SERIAL003,
@EarlRamirez I’m not sure what you are looking to do here. A keystore is meant to be a store of key/value pairs meant for a single switch [stack]. If you want to map two different serial numbers to two different hostnames, then use two keystores:
ztp set keystore STACK1 hostname SWITCHNAME1
#
ztp set keystore STACK2 hostname SWITCHNAME2
@derek-shnosh the external keystore is exactly what I need, @PackeTsar I will go with the external keystore, this is not for a stack but for a bunch of 12 port switches.
Thank you very much
@PackeTsar and @derek-shnosh, thank you for the remarkable product. To date, I was able to configure a few thousand switches using FreeZTP. Two of the features that I will love to see are:
- Replace JSON logging to a database like a MongoDB collection, this will permit better concurrency
- The option to read an external Keystore from a database
@EarlRamirez - just want to clarify that @PackeTsar is the sole developer of FreeZTP, I merely contributed some usage tips in the TIPS.MD file.
That being said, having used this for 4 different client projects, I share your sentiment; FreeZTP has been invaluable.
@derek-shnosh, thanks for the clarification, your tips are very useful. @PackeTsar thanks again for the remarkable product.
I required the ability to determine many switch types and upgrade IOS accordingly. I hacked away at ZTP-Watcher and accomplish this effectively via trivial SNMP calls. I can clean up the code and post if there is interest, or possible look into integrating into FreeZTP. My thanks again to the authors of FreeZTP and ztp-watcher.
@helpdeskdan I welcome any PRs on ZTP-Watcher, would love to see what you put together.
Only did IOS - need at least 3850 functionality. (Not a big 3850 fan) Let me write a couple functions for the old and new commands needed to upgrade them and then perhaps it might be suitable. Suggestions welcomed.
Had less free time than I thought, but here is my fork that provides the ability to support different switches (IOS or IOS-XE), different copy methods (bin or tar) and different protocols (tftp, ftp, scp). https://github.com/helpdeskdan/ztp-watcher
Just came across this whilst looking for a way to automate deployment of Cisco SG series switches. Not sure if it will work, but it LOOKS like it will. If it does, you are my hero and we will gladly assist in testing of any new version.
It does work, I used it to deploy switches. Please post an issue if you have a problem.
i would love to see version with Python3 and the updated TFTP libary.
Every once in a while i get error like
Sep 28 10:05:50 freeZTP bash[3084894]: ERROR:tftpy:Fatal exception thrown from session 10.81.95.176:62603: File not found: /srv/tftp/ZTP-25485FC54E-confg
from what i read it could haven been fixed in the tftpy version 0.8.0 Issue 70
I'd like to request an enhancement to the keystore merge mechanism.
Use Case Large scale switch replacement project (100+). Device names and IPs are well known and can be easily documented in CSV format (potentially other variables). Designated models and stack order are unknown prior to deployment.
This would make it fairly simple to add supplemental automation that can pull final deployment data from an external system and inject it into freeztp with standard CLI commands.
Implementation Allow CLI defined keystore variables to be merged with an external keystore. Establish precedence for conflicting variable names (my recommendation would be that CLI defined would be winning version, but I'm open to debate the pros/cons).
CLI Entries
ztp set keystore MYHOST1 model1 c9300-48uxm
ztp set keystore MYHOST1 model2 c9300-24ux
ztp set keystore MYHOST1 snmp_location HQ
External Keystore
| keystore_id | sec_octet | last_octet | snmp_location | vlan_data | vlan_voice |
|---|---|---|---|---|---|
| MYHOST1 | 22 | 33 | Admin | 10 | 20 |
Merged Variable List for MYHOST1
- model1 = 9300-48uxm
- model2 = 9300-24ux
- snmp_location = HQ
- sec_octet = 22
- last_octet = 33
- vlan_data = 10
- vlan_voice = 20
PSC
Have been using freeztp now for a solid year and it is brilliant! We've staged thousands of switches and has saved us so much time, fantastic tool.
Forget about the refactoring, if you just did the minimum to port to python3 that would be a huge step forward. I'm considering using this but only if I have time to dockerize this due to the python2 requirements.
