I dare to say that most organizations know less about their network than they want to. Especially when there’s a need to describe the network or use the information in any way. In theory, there might be a lot of things that are known about the network. However, often it’s hidden away in someone’s head, or some wiki page, old Visio diagrams or just lost to the ages.
A lot of companies, even large ones still don’t have their network devices in DNS. While DNS isn’t by any means a requirement the lack of it is usually an indication that the organization doesn’t have a good data source which contains information about their network. DNS is of course not enough. When talking about zero-touch provisioning you need some data source which you can query in order to get a complete picture of what the configuration should look like.
In some environments, it could be that most of the configuration should look identical for all devices. It is much, much easier to automate such an environment. Though even in that kind of environment each device will have different IP addresses and you need some place to keep track of these.
You will have to find a system which suits your needs and I won’t cover that in this tutorial. There are a lot of commercial and open source inventory, CMDB or IPAM solutions to choose from. You also might end up creating your own one if you can’t find any other tool that provides what you need.
The important part is that you have a single source of truth which can be queried by a program, i.e. it can’t be written down in a Wiki or a post-it note. If you don’t know where to start Netbox could be an option. Regardless of which tool you use you will probably start with doing a brownfield discovery of your network.
If you don’t have an inventory at all you won’t have a zero-touch provisioning system, you will only have a system with a delayed first touch.
To keep things simple in this guide I won’t be using an external system and instead relying on a Yaml file. There are four devices in the inventory:
I’ve created the file /opt/ztp/devices.yaml
---
og-sw-01:
management_ip: 172.29.50.3
ip_interfaces:
- name: Vlan20
ip: 172.29.50.3
mask: 255.255.255.224
links:
- interface: "FastEthernet0/7"
interface_brief: fa0_7
neighbor: og-sw-02
neighbor_if: GigabitEthernet0/1
location: desk
platform: c2960
model: WS-C2960-8TC-L
gateway: 172.29.50.1
vlans:
- id: 20
name: TRANSIT
og-sw-02:
management_ip: 172.29.50.14
ip_interfaces:
- name: Vlan20
ip: 172.29.50.14
mask: 255.255.255.224
links:
- interface: "GigabitEthernet0/1"
interface_brief: ge0_1
neighbor: og-sw-01
neighbor_if: FastEthernet0/7
access_vlan: 20
snooping_trust: True
- interface: FastEthernet0/2
interface_brief: fa0_2
neighbor: lab-sw-01
neighbor_if: FastEthernet0/1
access_vlan: 20
location: desk
platform: c2960
model: WS-C2960-8TC-S
gateway: 172.29.50.1
vlans:
- id: 20
name: TRANSIT
lab-sw-01:
management_ip: 172.29.50.15
ip_interfaces:
- name: Vlan20
ip: 172.29.50.15
mask: 255.255.255.224
links:
- interface: "FastEthernet0/1"
interface_brief: Fa0_1
neighbor: og-sw-02
neighbor_if: FastEthernet0/2
access_vlan: 20
snooping_trust: True
- interface: FastEthernet0/4
interface_brief: Fa0_4
neighbor_if: FastEthernet4
neighbor: lab-rtr-01
access_vlan: 20
location: closet
platform: c2960
model: WS-C2960C-8TC-L
gateway: 172.29.50.1
vlans:
- id: 20
name: TRANSIT
lab-rtr-01:
management_ip: 172.29.50.16
ip_interfaces:
- name: FastEthernet4
ip: 172.29.50.16
mask: 255.255.255.224
- name: Vlan100
ip: 192.168.10.1
mask: 255.255.255.0
ip_helper: 172.29.58.10
- name: Vlan200
ip: 192.168.12.1
mask: 255.255.255.0
ip_helper: 172.29.58.10
links:
- interface: "FastEthernet4"
snooping_trust: True
interface_brief: fa4
neighbor: lab-sw-01
neighbor_if: FastEthernet0/4
- interface: "FastEthernet0"
interface_brief: fa0
neighbor: lab-sw-01
neighbor_if: FastEthernet0/1
trunk:
vlans:
- 100
- 200
native: 100
location: closet
platform: c880
model: 881
gateway: 172.29.50.1
vlans:
- id: 100
name: MANAGEMENT
- id: 200
name: USERS
Some of you might gasp at the mention of FastEthernet, while others are horrified about the duplication of data. I am more in the camp of the second group, of course, we don’t want to define the same data twice. If you are wondering what I’m talking about each link gets entered twice, one time for each host where it is connected. The management IP addresses could have been handled differently too. I do it here to highlight the issue though, it’s fine to have this format if the data is autogenerated from another source. One other thing to keep in mind is that it’s really easy to make errors in Yaml files, for instance, we could have accidentally entered the same IP address for og-sw-01 and og-sw-02. It’s always a good idea to validate and test input like this by an automated system. Another reason is to simplify the code needed to use this inventory, while Python is needed to complete the tutorial this isn’t a tutorial about learning Python.
We will need to read this file from our application so install a Yaml parser.
pip install ruamel.yaml
To end this part we add a small snippet of code in /opt/ztp/app/inventory.py to load the device data.
import ruamel.yaml
inventory_file = '/opt/ztp/devices.yaml'
with open(inventory_file, "r") as f:
yml = ruamel.yaml.YAML(typ="rt", pure=True)
devices = yml.load(f)