Intent-based fabric management with Ansible#
| Summary | |
|---|---|
| Lab name | 4l2s |
| Lab components | 6 SR Linux nodes |
| Resource requirements | 4vCPU 10 GB |
| Lab repo | intent-based-ansible-lab |
| Authors | Walter De Smedt |
| Main ref documents | Ansible collection for SR Linux RFC 7432 - BGP MPLS-Based Ethernet VPN RFC 8365 - A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN) Nokia 7220 SR Linux Advanced Solutions Guide Nokia 7220 SR Linux EVPN-VXLAN Guide |
| Version information1 | containerlab:0.42.0, srlinux:23.3.3, docker-ce:23.0.3 |
Ansible is today the lingua franca for many network engineers to automate the configuration of network devices. Due to its simplicity and low entry barrier, it is a popular choice for network automation that features modular and reusable automation tasks available to network teams.
Disclaimer: Select the right tool for the job
As with every tool there are pros and cons to consider when selecting Ansible for your network automation project. While being simple in many aspects, Ansible tends to be hard to troubleshoot or shoehorn for complex and/or call-intensive automation projects.
Do your own due diligence and select the right tool for the job at hand. This post explains "a way" to achieve intent-based configuration management, but it is not the only way, nor is it a silver bullet for all automation projects.
With this post, we aim to provide a practical example of using Ansible to manage the configuration of an SR Linux fabric with the intent-based approach leveraging the official Ansible collection for SR Linux. Remember that the demo code we provide throughout this blog post is not an 'off-the-shelf' solution but a demonstration of Ansible collection capabilities and hopefully a source of inspiration for your own automation projects.
The intent or desired state of the fabric in this solution is abstracting the device-specific implementation. The abstraction level is always a trade-off between usability of the automation and feature coverage of the managed infrastructure: the higher the abstraction, the more user-friendly it becomes, but at the expense of feature coverage. The right abstraction level depends on your specific use cases and requirements.
The approach we discuss here only partially covers the SR Linux configuration or data model. Only resources required to establish and maintain a functional fabric are covered. The solution is meant to be extended as needed to cover other aspects of the configuration or data model by employing similar techniques, but this is left as an exercise for the reader.
-
the following versions have been used to create this tutorial. The newer versions might work, but if they don't, please pin the version to the mentioned ones. ↩