Nautobot use cases

Before we get deep into Nautobot, let’s level set on what Nautobot is as a network SoT and network automation platform. These are the two primary use cases for Nautobot.

These are not mutually exclusive and can be used in conjunction with other solutions. We’ll review all of that and more, but let’s start with the basics.

Network SoT

We already introduced the concept of a SoT and how it is the foundation for data-driven network automation. Adopting a SoT shifts the paradigm to focus on intended state data. At its core, Nautobot is a network SoT. What does this mean?

First off, it probably means a migration away from spreadsheets, which is a big win in itself:

Figure 1.2 – Evolution of implementing a network SoT

The usual next step is YAML and then deciding which data should be in Nautobot. However, these are not mutually exclusive as Nautobot has native Git integration, which allows users to sync YAML files directly into Nautobot. Much more on that later. The following are the power of Nautobot, where you can effortlessly manage your network inventory, define locations, and organize your infrastructure according to your unique needs:

• Nautobot allows you to store network inventory-defining locations, location types, floor plans, racks, and more alongside custom location types. In the real world, network devices are everywhere. They are in campuses, buildings, closets, racks, ceilings, locations on a manufacturing plant floor, cars, and spaceships... the list goes on. The goal of Nautobot is to provide an opinionated way to get started but allow users to define an inventory and organization structure that makes sense to them. The Nautobot data model will be discussed in great detail in Chapter 2.
• Nautobot allows you to store and model your devices based on vendors (manufacturers), device models, platforms, and roles. All of these are extensible and customizable for your environment. For example, common roles are leaf and spine for the data center, but if you use different roles or naming conventions, it is as simple as adding them.
• Nautobot allows you to store your IP Addresses and prefixes with support for namespaces that allow for overlapping IP space. This is an area where there may be existing solutions in place, such as Infoblox or BlueCat, as mentioned earlier in this chapter. However, IP addresses are required for assignment to interfaces and policies in Nautobot. With the Nautobot SSoT app, it’s possible to synchronize data from third-party systems into Nautobot, giving you flexibility if you need it. Having this data aggregated in Nautobot streamlines your automation initiatives.
• Nautobot allows you to store and model circuit data ranging from circuit providers to individual circuits and then allows you to attach them to specific interfaces on a device. Going one step further, it is possible to use the Nautobot Circuit Maintenance app to dynamically parse and read circuit notification emails from providers and update Nautobot accordingly attaching that notification to a circuit and a device.
• Nautobot embraces extensibility by allowing users to add any model to Nautobot to store the data they need and how they need it. For example, there are already open source Nautobot applications for Nautobot that allow you to store security ACLs, BGP routing protocol configuration, and device life cycle information such as End-of-Sale/End-of-Life data in Nautobot. This means that as the Nautobot core project continues to evolve, the community and users around the world can add data models they need to continue to store the intent needed to drive their network.
• Nautobot allows users to define the relationships that make sense for them. Nautobot has a defined data model, but relationships allow users to associate unrelated object types. For example, you can map a VLAN to a rack; you can map an IP address to a device (remember, IPs are assigned to interfaces); you can map a circuit to an IP address; when using Nautobot apps such as Device Lifecycle Management, you can map contracts to devices, and more. The list goes on.
• With flexibility in mind, Nautobot supports a Data Validation API that allows users to write any logic required to accept and add data to Nautobot. While many users use the Data Validation app, which allows for RegEx and ranges in the UI, the Data Validation API allows you to write any Python logic to ensure your standards and governance are enforced – for example, naming conventions, preventing certain data from being deleted, and more. All of your data standards can be codified and enforced so that bad data never finds its way into Nautobot.

This is just a glimpse into how Nautobot is a network SoT. The following visual also shows firsthand how Nautobot can power data-driven network automation:

Figure 1.3 – Codifying network designs through data enables network automation

As a network SoT focused on network automation, Nautobot has many features that showcase how it can seamlessly integrate into NetDevOps environments. Let’s look at a few of those features as a precursor of what will be covered throughout this book:

• APIs: From REST APIs to GraphQL to webhooks, data in Nautobot is very accessible. The REST APIs provide your traditional Create, Read, Update, and Delete (CRUD) operations. GraphQL provides an extremely efficient and user-friendly way to query the exact data you want. Rather than parse through large data sets from a REST API, GraphQL allows users to query for the exact element or elements needed. We’ll cover APIs in much more detail in Chapter 8.
• Native Git integration: Nautobot supports the ability to use NetDevOps workflows, allowing you to store files in a Git repository; then, in the UI, you can configure Nautobot to clone those specific repositories. You can store YAML data, Nautobot jobs, and export templates in a repository and easily clone into Nautobot all from the UI. This ensures you can run CI on your repositories, perform peer reviews, and then, once merged, sync those updates into Nautobot.
• Job automation: Nautobot Jobs are arbitrary Python code that can be used to perform any task you would script, including analysis of the data in Nautobot and simplifying data management and population, though they can be used to perform actual network automation tasks. Jobs also simplify creating self-service forms to streamline the adoption of network automation. Jobs also supports Job Hooks, which are similar to webhooks, in that when there is a change to data in Nautobot, a job can be triggered. Chapter 10 is fully dedicated to jobs, so there’s much more to come on this topic.
• Secrets integration: To perform network automation, there need to be integrations with secrets, credentials, SSH keys, and API tokens. There needs to be intent on which secrets are needed for a location or device. Nautobot has native secrets integration to map secrets to environment variables or files on the system, while also providing more advanced features with the Nautobot Secrets Providers app, which includes dynamic integration with HashiCorp Vault, AWS Secrets Manager, and many more Enterprise Secrets Management tools. This allows users to rotate and change secrets in secrets management or vault platforms with Nautobot fetching them as automation is performed.
• Flexible location models and dynamic groups: Nautobot supports flexible location models and allows you to filter on many different attributes. However, Nautobot also supports dynamic groups, which are based on the metadata of a given object. With automation, you likely need to automate based on predefined criteria. For example, you may need to automate all devices that are in a given region, are a given device type, and have a given status. So, the next time a device enters that status, it’s automatically part of that group, so targeting that dynamic group simplifies the automation required. Rather than checking the devices, device types, and statuses, you’re simply querying for devices in that logical group.

These are merely five ways Nautobot embraces network automation as a first-class citizen. All of these and many more will continue to be covered throughout this book.

Network automation platform

Nautobot is also a network automation platform, thus going beyond a SoT. Let’s take a look at this in more detail to understand what this means.

Nautobot jobs

The first major feature to be aware of for Nautobot being a network automation platform is the support of Nautobot jobs.

Nautobot jobs offer users the ability to create self-service forms in a matter of minutes. Self-service is needed to drive the adoption of network automation; Nautobot jobs are the foundation of Nautobot’s platform strategy. Imagine having data stored in Nautobot and you want to verify that it is on the device:

Figure 1.4 – Example of a self-service job form

Usually, there is a need to create some code or automation somewhere, often in another tool. Based on size or scale, that may be needed; but for many environments, tying it into Nautobot as a job makes sense because the data is already there. Keeping in mind that jobs are Python code, that code can be stored as a job in a Git repository and easily integrated into Nautobot, thus providing self-service to any user that needs to execute it. This is just a basic example, but any automation task that can be built as a script can be deployed as a Nautobot job. There are already Nautobot integrations to Nornir, which is one of the most common Python-based network automation frameworks in the open source community.

Nautobot apps

Beyond Nautobot jobs, Nautobot as a Platform has a powerful developer API that allows users to create Nautobot apps. Nautobot apps enable users to create APIs, create new views and pages, and create any data model required in Nautobot. Nautobot Apps are what encapsulate specific functionality and are the entities that are created for specific use cases. Thus, apps can be as lightweight as only modeling and storing new data – maybe you want to model and store SNMP data, maybe you want to model load balancers, and so on. Apps can be heavier-weight Python applications that perform actual network automation tasks:

Note

Nautobot Apps is the new name for Nautobot Plugins. You may see older commentary online and in the code base that says the word plugin, but that is referring to what is now called Nautobot Apps.

Figure 1.5 – Overview (subset) of Nautobot apps

Nautobot apps leverage the power of Nautobot as a Platform. Using Nautobot as a Platform to construct a network automation application allows users to focus on the actual development without doing the heavy lifting of creating an application from scratch. You get to take advantage of Nautobot APIs, RBAC, logging, GraphQL, relationships, Git as a data source, SSO, and the list goes on. What this means is you can add your own items in the navbar, insert menu items in existing dropdowns, insert new pages, and insert new tables and widgets on detailed object pages. This flexibility allows you to tailor Nautobot to your liking by building Nautobot apps driven by your requirements. Nautobot apps are built at a more accelerated rate than building custom stand-alone applications.

There are already numerous Nautobot apps in the open source community and this number continues to grow. Let’s explore some of them.