NetBox LabsRed Hat AnsibleInfrastructure AutomationAutomationRed Hat
Blog • • 4 minute read

Building a Common Data Platform for Data Center Fabrics

Many organizations make decisions to run multi-vendor networks and relying on vendor-centric tooling can lead to inefficiencies in operating or interoperating those networks. Building a common control plane using NetBox provides a reliable and standardized model of network infrastructure, which drives all of modern automation activities. The ability to abstract the configuration data required to build a data center fabric can lead to great gains in operating multi-vendor solutions as well as setting up easier transitions from one vendor to the other.

What is a common data platform?

A Common Data Platform allows us to describe the devices down to the interface components in an agnostic way.

Imagine a tree. Every tree has common characteristics. A leaf. Bark. Limbs. A trunk. Roots.

That is our data model. We can abstract the attributes of a tree from the tree itself. We can then use those attributes to describe all sorts of trees.

The same can be said for networks. Every switch has an interface. Every switch has VLANs. We can model VRFs, IP addresses, BGP information, etc. The way those things are implemented on a switch might be different, but our automation can take care of that. What we want to concern ourselves with is the architecture. What VLANs go on what switch. What IP Address should be on which interface. Who are my neighbors? How are the cables connected between switches and to downlinked devices.

Common Data Model architecture diagram for data center fabrics using NetBox
Fabric Data Model

Why this matters?

  1. Agnostic: Many organizations through strategy changes or through calculated design rely on multiple vendors in or across data centers. Allowing a common model makes it somewhat easier to maintain and potentially move between different vendor fabrics.
  2. Visibility: Abstracting device and IP information from the actual configuration itself and presenting it in an intuitive format like NetBox allows easy digestion of that data. This democratizes access to the data beyond just the network architect or engineer who deployed and maintained the fabric. Think of NOC personnel or other resources whose access to that information may be helpful, but also may traditionally not be easily accessible. Giving them access to information means they don't need to escalate to other groups to get that data.
  3. Management: This approach allows engineers to get out of managing 100s of YAML files. And allows them to view devices as connected items in an easily consumable way. (easily consumable from a human and a machine)
  4. Agents: As we introduce agentic operations into our organizations and as we come to rely on the insights from these agents, data is paramount to making good decisions. Relying on a reliable database of all objects in a network from a configuration and architecture perspective as well as things like location, models, serial numbers, and software versions will allow better decision making from our AI-aided workflows.

 

What does it look like?

There are vendor-suppported Ansible collections that help consumers provision and manage data center fabrics. For example, Arista has their Arista Validated Designs (AVD) and Cisco has their Cisco Network-as-Code (NAC). Both of these solution have user-defined YAML files, this is what our design aims to alleviate. We want NetBox to serve as the user-defined data that the Ansible collection consumes. We create a shim playbook that retrieves data from NetBox programmatically and puts it into the format that the Ansible collection expects, but this is transparent to the consumer of this workflow.

We model the same information in NetBox with the following design criteria. 

  1. Use Native NetBox objects as a first choice wherever possible. If we need to introduce custom fields or custom objects we will. We use config contexts as a last resort because we are trying to get out of the business of managing YAML or JSON directly.
  2. As much as possible create common objects in the data model. There may be explicit differences in fabric objects needing definition, we will define those as needed.
  3. Don't modify the Arista or Cisco collections and roles. We don't want to introduce the complexity and burden of maintaining a fork of an upstream-maintained Ansible collection.

 

The takeaway from this methodology is that trustworthy data produces trustworthy outcomes. Using NetBox and Ansible together enables that trustworthy data and the trustworthy outcomes. We get away from scaling inconsistencies that may come from manually editing IPAM spreadsheets and YAML files. We also enforce standardization by not relying on human-level attention to configure dozens of switches by hand. All of these things together produce scalable, repeatable, and reliable operating methods for complex network fabrics.

Technologies