I couldn’t find a suitable title for this post, in which I try to gather various insights that I’ve received in the past few days and that I’ve planned, sooner or later, to discuss together with Rocco Sicilia.
In recent years, Network Access Control (NAC) solutions based on the 802.1x protocol have gained significant traction. Like all security solutions, it is crucial to carefully evaluate their functionality to integrate them into a proper Cybersecurity strategy.
This article serves as an example to explore different strategies for configuring a feature on network devices using Ansible. Specifically, we will focus on configuring NTP on Cisco IOS devices, although the discussions here can be generalized.
This article explores how to optimize the provisioning of a hundred Cisco XR devices so that they are configured with minimal human intervention. Depending on the context, the devices might be shipped directly from the factory and configured automatically on-site, or more likely, they could be automatically configured in a lab environment, verified, and then shipped for installation.
Ansible Navigator is a container-based textual interface designed to manage various components of Ansible. In essence, it serves as a wrapper, providing a unified interface to the Ansible ecosystem. Initially, the use of Ansible Navigator does not require container usage; thus, we will use the --ee=false parameter.
When working with Ansible, one of the “recipes” that I always keep handy is related to debugging variables. I find it particularly useful to have a comprehensive view of the variables associated with a host, defined at the “facts”, environment, group, and host levels.
In this article, we’ll explore the two methods for defining an inventory usable by Ansible. The inventory serves as the source of truth containing the information that Ansible will use to connect to devices.
In the realm of automation, each laboratory we will create requires a feature as basic as it is essential: the IP addresses of the devices must be accessible from the automation system.
In my opinion, one of the less understandable constructs in Ansible concerns loop management. If we then talk about nested loops, the situation becomes even more complex. In this short post, we’ll see the recipes for:
I have been involved in automation since around 2004, when I was managing nearly 200 nodes on the AlphaServer. Specifically, I was responsible for the hardware aspect. It may seem straightforward, but it’s important to consider that there was a mini operating system running under Unix that checked the connected components, detecting both critical and non-critical errors.
