Provision a Dynamic Node¶
Using Open Patterns¶
Objective¶
I want to provision a node without knowing anything about it. I just want it to receive a default configuration.
Solution¶
You can accomplish this by using neighbordb. Neighbordb contains associations between LLDP neighbor patterns and definitions. So if we use a pattern that matches anything, we can use it to assign a simple, default definition.
# Go to your data_root - by default it's /usr/share/ztpserver
admin@ztpserver:~# cd /usr/share/ztpserver
# Modify your neighbordb
admin@ztpserver:~# vi neighbordb
Add the following lines to your definition, changing values where needed:
---
patterns:
- name: Default Pattern
definition: default
interfaces:
- any: any:any
If you happen to be provisioning a node in isolation and the node does not have any neighbors, use the following pattern:
---
patterns:
- name: Default Pattern
definition: default
interfaces:
- none: none:none
Then add a definition to [data_root]/definitions/default
Note
See the sections on Definitions and Actions to learn more.
Explanation¶
By placing this pattern in your neighbordb, the ZTPServer will allow this node to be provisioned and will assign it the default definition. Use caution when placing this pattern in your neighbordb as it might allow nodes to receive the default definition when you intend them to receive another pattern.
Identify a Node Based Upon Specific Neighbor¶
Objective¶
I want my node to be dynamically provisioned based upon a specific LLDP neighbor association.
Solution¶
Modify your neighbordb:
# Go to your data_root - by default it's /usr/share/ztpserver
admin@ztpserver:~# cd /usr/share/ztpserver
# Modify your neighbordb
admin@ztpserver:~# vi neighbordb
Then add the pattern that includes the required match.
---
patterns:
- name: tora for pod1
definition: tora
interfaces:
- Ethernet1: dc1-pod1-spine1:Ethernet1
This pattern says that the node being provisioned must have a connection between its Ethernet1 and dc1-pod1-spine1’s Ethernet1.
Explanation¶
In this recipe we use neighbordb to link a pattern with a definition. When a node executes the bootstrap script it will send the ZTPServer some information about itself. The ZTPServer will not find any existing directory with the node’s System-ID (System MAC or Serial Number depending upon your configuration) so it next checks neighbordb to try and find a match. The ZTPServer will analyze the nodes LLDP neighbors, find the match in neighbordb and then apply the tora definition.
Identify a Node’s Neighbors Using Regex¶
Objective¶
I want my node to be dynamically provisioned and I’d like to match certain neighbors using regex.
Solution¶
Modify your neighbordb:
# Go to your data_root - by default it's /usr/share/ztpserver
admin@ztpserver:~# cd /usr/share/ztpserver
# Modify your neighbordb
admin@ztpserver:~# vi neighbordb
Then add the pattern that includes the required match.
---
patterns:
- name: tora for pod1
definition: tora
interfaces:
- Ethernet1: regex('dc1-pod1-spine\D+'):Ethernet1
This pattern says that the node being provisioned must have a connection between its Ethernet1 and any dc1-pod1-spines Ethernet1.
Explanation¶
In this recipe we use neighbordb to link a pattern with a definition. When a node executes the bootstrap script it will send the ZTPServer some information about itself. The ZTPServer will not find any existing directory with the node’s System-ID (System MAC or Serial Number depending upon your configuration) so it next checks neighbordb to try and find a match. The ZTPServer will analyze the nodes LLDP neighbors, find the match in neighbordb and then apply the tora definition.
Note
There are a few different functions that you can use other than regex(). Check out this section to learn more.