In the final exercise, we’ll see how to put together what we’ve learned to configure and manage a legacy fabric (based on STP). So let’s ope

In the final exercise, we’ll see how to put together what we’ve learned to configure and manage a legacy fabric (based on STP).

So let’s open the Cisco Legacy Core-Access topology lab, start all the devices, and make sure they’re reachable.

Modeling

Before even thinking about writing playbooks, we need to create a model of our environment, which means creating a data structure that can represent our fabric and serve as a working tool. There are many possibilities:

• NetBox  / Nautobot : I’ve seen integration between these applications, Ansible, and devices. People would make a change on NetBox / Nautobot regarding a device’s interface. The change would trigger an Ansible playbook that would modify the configuration on the physical device.
• GitLab  / GitHub : This approach leans more towards Infrastructure as Code. An operator makes a change on the data structure, typically based on CSV / YAML / JSON, and the CI / CD pipeline runs various tests. If everything works, it adjusts the configuration of the devices in production.
• CSV / XLS / YAML: This is the simplest case, where a simple file contains the parameters of the structure, and the manual execution of a playbook adjusts the configuration of the devices. Any tests are done manually by the operator.

For simplicity, let’s choose the third approach. The first two would require significant development beyond the scope of this specific course.

In particular, for its readability and flexibility, we choose to use a YAML file. The YAML file should contain all the parameters that define our fabric. In particular, we definitely need to include information about:

• DNS
• hostname and domain
• NTP
• SNMP

Operationally, we definitely need to apply the following as well:

• hardening of devices
• configure interfaces

In particular, we can imagine that the interfaces have a template based on their function. We will definitely need templates for:

• inter-switch-link (ISL) interfaces
• interfaces to endpoints

Furthermore, the interfaces to endpoints will have a profile based on the connected device, for example:

• virtualization server
• firewall
• client access with VoIP phone
• management access
• office devices access

We have made this analysis based on our experience, but in a real case, the analysis must be done on the environment we are willing to automate. We must understand how a particular environment is structured and the way people work. Our goal is to formalize a structure (modeling) and standardize the way of working. Only then can we start developing the working tools, which in our case will be based on Ansible.

Practically speaking, we can create a first draft of a data structure that will define our environment:

We also need to define the VLANs that need to be configured in the fabric:

Finally, we need to define the profile associated with each interface:

The decision on how to formalize the interface-profile association is crucial because it has a huge impact on the way of operating but at the same time must ensure the integrity of the infrastructure. The format chosen in the example above appears cumbersome but ensures that interfaces are not associated with multiple profiles.

Continue reading the post on Patreon .