Search icon CANCEL
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Network Automation with Nautobot
Network Automation with Nautobot

Network Automation with Nautobot: Adopt a network source of truth and a data-driven approach to networking

Arrow left icon
Profile Icon Jason Edelman Profile Icon Gary Snider Profile Icon John Anderson Profile Icon Bryan Culver Profile Icon Brad Haas Profile Icon Celenza Profile Icon Glenn Matthews Profile Icon Josh VanDeraa Profile Icon Christian Adell +5 more Show less
Arrow right icon
Mex$1128.99
Full star icon Full star icon Full star icon Full star icon Full star icon 5 (4 Ratings)
Paperback May 2024 816 pages 1st Edition
eBook
Mex$631.99 Mex$902.99
Paperback
Mex$1128.99
Subscription
Free Trial
Arrow left icon
Profile Icon Jason Edelman Profile Icon Gary Snider Profile Icon John Anderson Profile Icon Bryan Culver Profile Icon Brad Haas Profile Icon Celenza Profile Icon Glenn Matthews Profile Icon Josh VanDeraa Profile Icon Christian Adell +5 more Show less
Arrow right icon
Mex$1128.99
Full star icon Full star icon Full star icon Full star icon Full star icon 5 (4 Ratings)
Paperback May 2024 816 pages 1st Edition
eBook
Mex$631.99 Mex$902.99
Paperback
Mex$1128.99
Subscription
Free Trial
eBook
Mex$631.99 Mex$902.99
Paperback
Mex$1128.99
Subscription
Free Trial

What do you get with Print?

Product feature icon Instant access to your digital eBook copy whilst your Print order is Shipped
Product feature icon Paperback book shipped to your preferred address
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Product feature icon AI Assistant (beta) to help accelerate your learning
Table of content icon View table of contents Preview book icon Preview Book

Network Automation with Nautobot

Introduction to Nautobot

Data-driven network automation powered by Nautobot is gaining momentum across the industry. This chapter provides the foundation required to understand the what and why of network automation and gives an overview of Nautobot and the role it can play in the greater network automation ecosystem. This chapter will start by uncovering the relationship between data and network automation and how Source of Truth (SoT), when used with Nautobot, is an integral part of the network automation journey. You’ll learn what network automation is, key use cases for network automation, and why you should consider network automation, dive into SoT, and be introduced to Nautobot and the power it can provide on the journey with Nautobot as a SoT and a network automation platform.

This chapter covers the following main topics:

  • Introduction to network automation
  • Understanding SoT
  • Nautobot overview
  • Nautobot use cases
  • Nautobot ecosystem

Introduction to network automation

If you’re reading this book, you’ve realized you need to think differently about managing your network. And you are not alone. If you ask any network engineer, there is still not a day that goes by when they are not logging into a device via SSH and doing work manually. Over the last few decades, the most common approach to managing networks of any size, ranging from tens to thousands of devices, was connecting to the device and using the network command-line interface (CLI). The network CLI is used to gather data, troubleshoot, and make configuration changes. This remains the most common way of managing networks. However, this is changing.

Over the last 10 years, we’ve seen significant growth and improvements around the operational models for networks. The software-defined networking (SDN) era brought us controllers and APIs. Controllers provide APIs and fewer points of management. Rather than manage thousands of devices, it is possible to manage tens of controllers (or fewer in some cases). Independent of the number, the point is that the number of directly managed nodes continues to decrease. The SDN era also shined a light on the programmatic interfaces, or lack thereof, of network devices. We have evolved from SSH and SNMP to APIs – REST APIs, GraphQL, gRPC, and event-driven webhooks from controllers and devices. While SSH and SNMP are still the de facto standards across the industry – even for automation, progress is being made. For that, we need to recognize the progress and celebrate, but continue to demand more.

The progress around network automation has been driven by open source. Before network automation, there wasn’t much use of open source in the network industry. The industry is learning from its history – that is, if you solely purchase and use vertically integrated tools, there is less flexibility and you could lose control of your network. With current trends, the belief is that those that adopt even just some open source remain in control and can extend libraries and tools as needed to ensure maximum adoption of network automation in their environment. Don’t worry – we’ll cover some of the most common open source tools and technologies for network automation in the Industry trends section of this chapter.

We’ll start by exploring what network automation is, its key use cases, and the value it can provide an organization. From there, we’ll dive into SoT and Nautobot.

What is network automation?

Any advanced and hot technology always gets flak when there are formal definitions because there are always varying opinions, and that’s okay. For this book, our approach is to keep it simple. So, what is network automation? Network automation is next-generation network management. Period. We can talk about Python, Ansible, Nautobot, YAML, JSON, REST APIs, NETCONF, RESTCONF, YANG – the list can go on for pages. Here is the bottom line – all of these tools and technologies are being used to improve how networks are managed and consumed daily, which is, simply put, better network management. Network automation involves transforming operational models that can radically transform careers and technical and business operations.

One major point you should think about on your network automation journey is that it isn’t just about doing your tasks better and more efficiently. That is only the starting point. You need to be thinking about how to expose your automation to other engineers, teams, and even non-technical people, thus enabling all parties with the self-service they need to do their job functions.

Let’s assume you are automating tasks such as operating system (OS) upgrades, which involves gracefully moving traffic from one device (and circuit) to another. This is a complex workflow. Sure, this can help you when you need to upgrade a device or perform maintenance on a device, but what about exposing that automation to individual site leads? If this workflow is made more accessible, can this expand who can perform the task using your trusted automation? Does it allow you or your team to delegate a little more? How often are upgrades happening today contrasted with how often you’d like them to happen?

What about if you had automated diagnostics? What if your Network Operations Center (NOC), Security Operations Center (SOC), or service desk could go to a portal, click a button, and diagnose their most common issues? In a manual process, one person opens a ticket, and that ticket remains open and an engineer picks it up. The engineer reviews the request and sees it is a semi-common problem. Maybe they need to check with another engineer or two along the way. After a few discussions, they know where to go, which devices to log in to, and which tools to log in to. They correlate the data gathered between the devices and tools. They ensure things look good and update the ticket. Common workflows like this should be automated.

Would your leadership be astounded to learn that the countless hours needed to gather data, let alone the hours spent formatting to make it look good, can be eliminated with automation? Compliance and reporting tasks often take a lot of engineering time and effort because they involve manually gathering and processing information. Now, imagine being able to automatically create any compliance document or report you need. Documents that include pre/post change tests. Documents required for change control. Reports you need to run monthly, quarterly, or annually for compliance. Reports that verify your devices are operating as expected.

This is network automation.

Network automation use cases

We just discussed some examples of network automation to bring it to life. Now, let’s look at some of the most common use cases, including the ones that were already mentioned:

  • Common config changes: Is your team performing the same types of changes day to day, week to week, or month to month? These are changes such as adding VIPs, turning up a port, adding a VLAN to a switch port, managing firewall policies (also discussed later in this chapter), turning up a new BGP peer, updating routing preferences, adding static routes, and updating zones and ACLs. These changes are ripe for automation because they happen so frequently.
  • Common operational tasks: These are similar to the previous use case, but they involve performing operations tasks that do not require a configuration change. Some examples include updating SSH keys and certificates on devices, performing a config save or backing up a configuration, copying files to devices, rebooting devices, checking logs, and even performing non-network device tasks such as checking and updating tickets.
  • Mass changes: While common config changes are scoped to a set of devices (this could be just a few devices), mass changes are meant to be site, campus, regional, or global. Mass changes include changes such as updating AAA, NTP, or SNMP but could also include changing the format and structure of all interface descriptions on every device. These types of changes don’t happen as frequently, but when they do, they are impactful and usually a large project.
  • Data gathering and reporting: How often is someone you know logging into numerous devices or tools to perform health checks, troubleshooting, or simply to execute a request that comes in for application or network performance degradation? Automated data gathering, reporting, and documentation is not only one of the best use cases for network automation – it is a great area to start with since it is less impactful in the event there is bad automation (because it’d be read-only automation). It could also be added to nearly any other use case producing reports before and after changes or generating compliance reports specific to your team or organization.
  • Configuration and operational state compliance: Compliance comes in two major flavors and can be best understood by asking the following two questions: Is the network configured as expected? and Is the network operating as expected? Configuration is easy to understand, but it does mean you’ll need to understand the intended state of the network. This is where SoT and data-driven network automation comes into play. We’ll cover this in more detail later in this chapter in the Understanding SoT section, as well as Chapter 11.
  • Pre/post-change state validation: Similar to the previous compliance use case, pre/post-change state validation is more focused on a defined scope of devices. There may be automation when performing global compliance that only runs daily, but changes are happening continuously. Pre/post change state validation ensures that the network is healthy and operating as expected before and after the change.
  • Firewall policy automation: How many firewall rules are you adding per day, week, or month? How do you know which firewalls need a new policy? How do you know where in the list of rules the new one should go? Do you know? Could you document this for a fellow engineer? Try. This is the start of firewall policy automation. While the last mile is configuring the actual firewall, the questions prior illustrate that a company’s firewall rule change workflow often involves many steps before the actual configuration change.
  • OS upgrades: While already mentioned briefly, how often are upgrades happening today contrasted with how often you’d like them to happen? How many of your devices adhere to your software standards? How many upgrades can you currently do in a single change window? Do you find yourself watching the console of devices as you upgrade them? Do you run any automation to see if devices have the required disk space before copying the new image to the device? Do you run any automation to verify the md5 checksum of the image after it is copied to ensure it isn’t corrupt? Is your network at risk due to vulnerabilities left unpatched? Upgrading devices often happens when needed, versus having a defined cadence. It is never a priority. Automation changes that.
  • Greenfield sites and devices: If you are repeating deployments, there is room for automation. It may mean adding new top-of-rack switches in the data center, it may mean adding a closet or IDF closet in a growing campus, adding a new retail location, or even a new colocation facility or point of presence (PoP). Much of the automation discussed here is around the configuration of these devices, but that is the easy part. Site planning and deployment is about data curation and management not to mention each organization’s business logic required for deployments. How do you and your team know which IP addresses, VLANs, ASNs, and overall configuration should be entered on those devices? Is it from spreadsheets or a SoT? Again, more on SoT later.
  • Vendor migrations: Have you ever not moved forward with changing vendors due to the work effort of migrating configurations? With a properly defined SoT and data strategy, this becomes trivial. Your focus becomes storing the intended state of the network using data, decoupled from any vendor-specific syntax. Syntax for a given vendor is generated by running the data through a set of vendor-specific configuration templates. In a migration, you can generate the desired state configuration for a given vendor by running the data through a different set of templates and then deploying those new configurations. Beyond configuration management, you’ll also want to ensure multi-vendor operational state compliance to ensure there are no gaps in visibility during the end-to-end migration.
  • Self-service: It is critical to think through how a given workflow will be triggered along with who the target user is. Self-service does not mean that it needs to be a click-button UI. It may mean an IT tool, CLI tool, pull/merge request, ChatOps, or yes, it may mean a full self-service user-friendly form. The point is that you do not need one way to expose network automation or even one way per workflow. Using an architectural and a platform approach to network automation allows you to expose the same workflow through multiple self-service interfaces. You should cater to your culture and your users. This will drive more adoption of network automation.

It is recommended to use a holistic multi-domain network automation architecture to serve as a platform to meet today’s requirements. This architecture will also serve as the foundation for tomorrow’s requirements. As you embark on the journey, be cautious about using different network automation architectures for different types of networks and domains. If so, it’ll create more issues and give your team even more tools to manage while making it harder to unify standards and processes. In Chapter 10, we will talk much more about network automation architecture to ensure a consistent approach to managing networks independent of size, domain, and location.

Why automate your network?

After covering the what, let’s take a look at the why. While many use cases are horizontal and can be used by any organization type (or verticals), the actual why, impact, and justification will differ per organization. Just to clarify, by vertical, we’re referring to companies with different business types. A few examples of different verticals include financial services, pharmaceutical, retail, telco/the cloud, manufacturing, accounting/legal professional services firms, state and federal government, K-12 education, and universities.

For some verticals, the network may be the business. It may either be a business enabler or have serious consequences if the network is down. For other verticals, other factors may be a bigger concern. For this reason, the why is going to vary widely, and we’ll cover general reasons to automate the network. Here are some common examples:

  • Lower costs: Every leader in every business is always asked by their leaders or directly by finance if there is a way to lower costs. In reality, automation helps lower longer-term costs. The more a company can show how automation lowers costs, the greater the chances are that the automation projects get initial buy-in and long-term support. With some of the use cases already mentioned, costs can be significantly lowered. If a company truly documents each of the tasks required and the time to do each for a workflow (such as OS upgrades or troubleshooting) and verifies the most common incidents, they are going to see drastic savings in time and effort when using automation. Time equates to money. It doesn’t mean anyone is getting replaced. However, it does mean that there is more time for more projects, each of which adds more value to the business. Increasing velocity without needing to hire new people is a tremendous cost savings.
  • Enhance security and reduce risk: In today’s world, security is top of mind for everyone; it’s integrated into all that we do. No company wants to be the headline in the local, national, or global news. Security-focused automation ranges from automated scans, firewall provisioning, VPN connects and disconnects, compliance and remediation, governance adherence and monitoring, and patch management just to name a few. Even if you are not directly on a security team, you should ask yourself if security can be improved in your domain. Can you rotate passwords more frequently? Maybe change those SNMP community strings? The list can easily go on.
  • Provide greater insight and control: Data is king and that includes greater visibility into your network and automation infrastructure. Automation can be used to gather data, document data, understand patterns, and compare against known baselines. Sure, there may be tools that provide this in the user interface (UI). That’s a great start, but what about seamless workflows that open tickets, update tickets, send emails, and send chat messages in response to network data that is outside the expected range? With automation, you have the opportunity to get the insights you need to answer the questions you have and know that the answers are contained within the network. Think about that. If you are logging into a few portals, copying data into a spreadsheet, creating Excel formulas, or creating a new document to then turn into a PDF and email, there is a better way. There is an automated way.
  • Increase business agility: Each business and team is always trying to go faster and also perform activities that are not possible without automation. Organizations need to work smarter and more efficiently. In some cases, it may also make sense to hire more people. However, hiring more people often slows things down because, at a certain point, people can start to get in each other’s way. In contrast, automation can reduce cost, improve performance/velocity, increase reliability, and do things that humans just cannot do. One example is automation-enabled self-service, which helps business stakeholders obtain the outcome they need sooner. Automation can also improve business-to-business connectivity, allowing organizations to either recognize revenue sooner (for those that are doing business over those connections, tunnels, or circuits) or start consuming a new service. Think about deploying a new application in a lab or test environment. If it takes weeks to get a new application and its network and security configurations deployed for each environment (dev, test, UAT, and so on), it may be an aggregate delay of months. This is either delaying employee or customer satisfaction or revenue. Using automation improves this and increases business agility.

In all that you do, keep automation top of mind, and try to understand the business and organization-level benefits for various leaders in your organization.

Persona-driven network automation

While we already looked at network automation use cases and the rationale for automation, let’s take a different spin on use cases. There is usually never one network team. There are usually teams focused on day 0 or architecture and/or engineering; day 1 or implementation; day 2 or operations. These teams may even span network domains such as LAN, WAN, WLAN, or Security, depending on the size of the network. Recognizing the work of the various teams will help structure automation projects for what’s possible within your team.

Here is a list of example projects and tasks broken down by the three types of teams often found in network organizations:

  • Day 0 or architecture and/or engineering:
    • Ensure configuration standards are documented in a structured and modeled manner that is programmatically accessible
    • Ensure hardware standards are documented in a structured and modeled manner that is programmatically accessible
    • Ensure software standards are documented in a structured and modeled manner that is programmatically accessible
    • Ensure architectural and engineering tests exist within every CI pipeline – for example is there redundancy?
    • Develop automation architecture and framework used by other teams
  • Day 1 or implementation:
    • Use automation to generate configurations
    • Use automation to perform configuration changes
    • Use automation for pre- and post-deployment verification
    • Use automation for continuous verification of deployment standards
  • Day 2 or operations:
    • Execute network device automation for common troubleshooting tasks
    • Continuously update automation that is used for common troubleshooting tasks
    • Execute network device automation for common changes
    • Ensure automation for dynamically reading emails from ISP/NSPs for circuit notifications
    • Execute automation for gathering and collecting information from various tools and devices to aid in troubleshooting
    • Execute automation for dynamically creating, updating, and closing change management tickets

Industry trends

As we’ve already discussed, the CLI still dominates the industry. However, each year, month, week, and day brings us closer to transformative and better network management through the use of network automation. In this section, we’ll look at several of the trends that are collectively driving the industry forward to do more with less and allow for more efficient network operations.

This list is not meant to be exhaustive, but illustrative of the trends that are driving operational efficiencies and automation:

  • SDN: SDN took the industry by storm in the 2010s. Most modern network architectures include controllers that simplify management and visibility and provide programmatic access with APIs. Simplified management is made possible because it allows users to manage systems versus managing devices and nodes, which allows more abstract policies to be created and applied. Because they allow for fewer points of management, SDN controllers simplify workflows and integrations using the controller (versus individual device) APIs. With SDN, you may have different controllers and solutions for campuses, WAN, data centers, and the cloud. So, if you are looking for a unified network automation strategy, there will be a bit of integration that needs to happen when it comes to data and orchestration. More on this later.
  • NetDevOps: We’ve learned a lot about the DevOps industry over the last 10 years. When we talk about NetDevOps, we’re referring to doing DevOps but applied to network infrastructure, engineering, and operations. Here are a few examples that highlight trends:
    • Using Git-based version control systems (VCSs) such as GitHub, GitLab, or BitBucket. Using VCS enables collaboration while providing traceability and audibility on all software or file-based artifacts (templates, data files, scripts). VCS allows users to create owners of particular projects or sections of a project providing accountability to the respective teams.
    • Using continuous integration (CI). Organizations that use VCS will require basic CI. CI allows users to create tests that must pass before accepting or approving any changes. These tests focus on ensuring nothing is going to break in the automation or the application. CI can also be applied more directly to the network, enabling network CI.
    • Implementing network CI. If the initial CI tests pass on code and static files, users can do tests such as pre-change analysis based on models of the network (mock devices or real equipment, if you have a larger budget), running active tests on the network (does the network need to be a certain state before making the change?), perform the actual change, and then finally ensure the network is operating as expected after the change.

    While DevOps and NetDevOps can be talked about for days, the actual industry facts show that nearly every network automation project in the world includes version control, automated tests, and some level of CI. If your organization is one of the few that aren’t using these three key items, be sure to explore them as soon as you can.

  • Open source: Many open source tools are used in the DevOps ecosystem. The same holds for NetDevOps. We’ll mention some of the most common tools in the Tools and technology point covered in this section. Regardless of the tools deployed, it is more important to understand the real value of open source. In the context of open source, the real value lies in its extensibility, ecosystems, and community. Extensibility and ecosystems can drastically change and improve what’s possible on your network automation journey. Keep in mind that each of these is predicated on the fact that there is a strong community at the foundation. Extensibility is what should give you confidence that no matter what decision is made for your network, you can adapt and change to account for that decision. A change may be as simple as upgrading to the latest version of software, migrating from vendor A to vendor B, or migrating from a traditional network to a controller-based network. In any of these scenarios, an organization needs to be confident that its automation can be tailored, updated, or augmented for their needs. While certain commercial tools offer extensibility, it is usually limited and extensibility features tend to be in a perpetual state of coming soon. Ecosystems built around community also play a critical role in open source software, further enhancing what is possible with particular open source projects. Ecosystems are usually fostered around extensions, adapters, apps, or add-ons that are outside of the core open source project but are powered by it. It is these ecosystems that usually incorporate the solutions required for true multi-vendor management and automation. The point is not that everything needs to be open source, but that open source software and solutions should either lead or complement any network automation strategy. If they do not, there may be a great risk to the success of the automation journey three to five years out.
  • SoT: Since you’re reading this book, you’ve likely heard about SoT. In fact, the main topic of this book is Nautobot! At its core, Nautobot is a network SoT that is actively being developed specifically for network automation environments. A SoT is a growing industry trend and probably why you’re reading this book, but the short overview of a SoT is that it is the location where you can define the intended state of the network. This is the truth; it is what should be. The SoT is not what is on the device or network. That is referred to as the actual or observed state. The intended state, or SoT, can be extrapolated and used to document the intended configured state and intended operational state, or even used as the place to define the intended state for monitoring thresholds and events. Overall, it allows for greater governance of network data with a focus on what should be in a manner that is often vendor-neutral. We’ll spend much more time on SoT in the next section and throughout every other chapter in this book.
  • Self-service: We covered self-service in the Network automation use cases section, but to restate it one more time, the notion of self-service is not one-sided. Those organizations that are successful on their network automation journey understand that it is about having the right mapping of workflows to people (consumers) and from those people to the right user interaction, or the right tool to execute and request that automation. If you get this wrong, there is a great chance to end up with network management systems that aren’t used, which will take us back a few decades.
  • Streaming telemetry: SNMP has been around for decades, and network visibility as we know it is largely based on SNMP. Streaming telemetry is what you may expect when you think about modern network visibility. In this modern era of streaming telemetry, network devices can continuously “push” or “stream” network data to a centralized location. This allows for greater visibility, querying, and trending based on data that would have normally been lost. Wouldn’t it be great if the network device could send you the information you need when you need it? Wouldn’t it be great if you could turn on a stream of data (collection of data points) from a series of devices on particular interfaces versus getting a response from an interface poll that may kill the device if your poll frequency is too high? Wouldn’t it be great if you could build a closed-loop system that can operate in near real time? This is made possible by streaming telemetry.
  • Intent-based networking (IBN): When you look at the key use cases and trends, you can start to see common components of an architecture, such as orchestration, automation, SoT, and telemetry. When these components are fully integrated, the result is an IBN. An IBN is just a comprehensive network automation architecture. It allows organizations to define intent, continuously collect network data (streaming telemetry, SNMP, show commands, and configuration data), analyze that data, ensure intent is deployed, and then react based on intent violations. The reaction to the data may be to remediate or make a change for managing capacity or minimizing the blast radius for a known issue. IBN becomes a natural progression as you start to deploy a holistic architecture for network automation.
  • Artificial intelligence (AI): Our general belief is that a significant amount of automation must be implemented without AI/ML, meaning don’t let flashy new tech derail projects and outcomes that are solving today’s problems. That said, at the time of writing, we’ve seen the launch of OpenAI’s ChatGPT (https://openai.com/blog/chatgpt/), Google’s Gemini, and many more services like these. It should be obvious that AI/machine learning (ML) coupled with natural language processing (NLP) creating more digital assistants is going to have a transformative impact on where we are as an industry in 5 to 10-plus years as it gets mainstream adoption. Until then, it’ll be explored and implemented by pioneers and manufacturers who can make it consumable in a turnkey and meaningful way.
  • Tools and technology: This is always one of my favorite topics since we live in a product- and tool-centric industry, but let’s look at existing tools trends for network automation. From an open source perspective, the dominant tools are Ansible, Nautobot, Batfish, and Terraform. We also see a sprinkling of Salt, but its presence is still largely seen in application and systems automation. Looking at open source from a lower-level library perspective, there is continued growth with Netmiko, NAPALM, Nornir, pyntc, ntc-templates, and scrapli. If you are using open source or building your solutions, you want to check out these projects. For example, if you need a custom Ansible module or custom Nautobot App, you’re more than likely going to consume those libraries to perform your automation. From a telemetry perspective, there is also growth in various stacks that include Prometheus, Influx, Telegraf, and Grafana. Teams that have the skills or are further on their journey can use these stacks to provide greater visibility through data aggregation, data enrichment, extremely powerful queries, and a holistic view of their networks and their IT infrastructure. From a commercial tool perspective, and exclusive of SDN products, we’re seeing the most adoption of Itential, IP Fabric, and Forward Networks.

Information

Interested in seeing a comprehensive list of all network automation projects, tools, and products? Check out Awesome Network Automation (https://github.com/networktocode/awesome-network-automation).

From a trends perspective, we thought it may be worth calling out a few things that get attention at industry events and in social circles, but aren’t gaining traction. The first is the direct use of YANG data models within automation tools. They are still mostly used by vendors to define their schema. Of course, there are outliers such as hyperscalers or a select few enterprises, but generally speaking, the actual use of YANG by network teams is not a trend. If you’re using an API that is based on a YANG schema, we do not consider that a trend for end users, but it is a trend for certain manufacturers. We’ll also call out REST APIs on network devices. While they are becoming more commonplace because the dominant majority of devices in production still don’t have APIs, and instead have two or more (different APIs per vendor and OS) ways of performing automation, the majority of device-specific automation still happens via SSH.

Understanding SoT

We’ve already mentioned SoT a few times. It’s finally time to dive in. Let’s start by talking about data. We’ll do that through the lens of making a change on the network.

Let’s assume that you want to turn up a new port that’s going to terminate a connection to a new building. If you look at other similar configurations on the same device, you’re going to find a configuration similar to this:

interface vlan100 description Routed Interface for connection to off campus house
 ip address 10.1.100.1/24
interface GigabitEthernet4/1
 description connects to och-sw-01 GigabitEthernet1/1 (off campus house)
 switchport
 switchport access vlan 100
vlan 100
 name off_campus_house

Is there any other way to configure the same interface? Could we have used a routed port? Could we have configured a trunk instead? A different prefix? Sure, these are all valid possibilities. The point is that you are going to have your own standards, and they will drive your new configuration. When adopting a SoT approach, we need to decouple data from configuration syntax.

For example, the standard configuration you copy and paste becomes your template while you extract the data. That data becomes any input that changes to derive a configuration. In this example, the data is as follows:

  • SVI interface: 100
  • SVI description: Routed interface for connection to off-campus house
  • SVI IP address: 10.1.100.1/24
  • Physical interface: GigabitEthernet4/1
  • Physical interface description: Connects to och-sw-01 GigabitEthernet1/1
  • VLAN ID: 100

In reality, both descriptions – that is, the SVI interface and the IP address, could be removed from data inputs since they can be auto-generated from the VLAN ID. We’ll see that soon. For descriptions, they can be auto-generated by having a use case or description of the project defined. Let’s look at a few examples of showing this data as YAML structured data:

Note

Teaching YAML and Jinja2 is outside the scope of this book.

svi_interface: 100svi_description: Routed Interface for connection to off campus house
svi_ip_address: 10.1.100.1/24
physical_interface: GigabitEthernet4/1
physical_interface_description: connects to och-sw-01 GigabitEthernet1/1 (off campus house)
vlan_id: 100

You may opt to nest some data, like this:

svi:  interface: 100
  description: Routed Interface for connection to off campus house
  ip_address: 10.1.100.1/24
physical_interface:
  name: GigabitEthernet4/1
  description: connects to och-sw-01 GigabitEthernet1/1 (off campus house)
vlan_id: 100

Going one step further, a few values could be eliminated if there is more logic in your Jinja2 template. This one also adds data for the remote peer:

physical_interface: GigabitEthernet4/1vlan_id: 100
connection:
  description: Routed Interface for connection to off campus house
  remote_peer: och-sw-01
  remote_interface: GigabitEthernet1/1

Finally, a Jinja template that could consume this data and render a configuration snippet would look like this (focused on one of the devices):

interface vlan{{ vlan_id }} description {{ connection['description'] }}
 ip address 10.1.{{ vlan_id }}.1/24
interface {{ physical_interface }}
 description connects to {{ connection['remote_peer'] }} {{ connection['remote_interface'] }}
 switchport
 switchport access vlan {{ vlan_id }}
vlan {{ vlan_id }}
 name {{ connection['description'] }}

Defining SoT

After looking at a few different ways to represent data, the main point is that we have successfully decoupled data, which is shown as YAML, and syntax, which is shown as a Jinja template. The templates are built or defined by those who own the standards. However, data is what needs to be created or updated for any given change. Focusing on the data focuses on a change, without getting pulled into syntactical details that vary per vendor.

This data is now the SoT (technically, the SoT would be the file that contains the data).

With our focus on the data, now comes the real questions to ask:

  • Why did we pick GigabitEthernet4/1?
  • Why was VLAN 100 chosen?
  • Why was 10.1.100.1 chosen?
  • How did we construct the interface descriptions?

It would be fairly common if you were checking one or more spreadsheets to get this data, but it’s more likely that you just knew because you’re good at what you do and you checked the devices and connections that you most recently deployed.

The idea of a SoT is that it allows you to plan and focus on what should be. A SoT defines the desired state. With a SoT, users manage the data that’s used for upcoming changes, which is then programmatically accessed by automation tools during a change. The automation tools access the data, render a network configuration, and then ensure that configuration exists on the network. On your SoT journey, you should be able to build a document that defines one tool as the authoritative source per type of data – for example, ASNs, VLANs, and so on.

Due to the breadth of network data required to manage a production network, often, one or more systems are used as an authoritative source of information to build a configuration. For example, a database might be used for inventory and IP addresses, and another that has policies used for ACLs. The authoritative source of data is the location where updates are made. This is also often referred to as a system of record (SoR). It’s worth calling out that SoT and SoR are often used interchangeably:

Figure 1.1 – Visualizing SoR, SoT, and SSOT

Figure 1.1 – Visualizing SoR, SoT, and SSOT

Generally speaking, the term SoT is a system that stores data from one or more SoRs. However, how often SoR and SoT are used interchangeably, the term Single Source of Truth (SSoT) is often used to reflect a system that is aggregating data from multiple SOR. This type of system allows relationships to be formed between these datasets and also provides one unified API that can be used to access all network data. Having this data accessed from a single API significantly lowers the amount of work required by your automation tooling. In Appendix 2, we review working with multiple SoTs, doing a deep dive on the Nautobot SSoT application, and discussing other designs used for managing network data.

Approaches to SoT

The previous section described the purist view and the most correct approach to understanding a SoT. It is based on the premise that the SoT always contains the intended state. This means that as a user, you change the data and then perform your change using that data. Of course, using automation to fetch the data is the ideal state, but even if you were using it as a documentation store, it’s a step in the right direction. The gap in this approach is that the SoT does not always reflect the actual state of the network (maybe a user makes a manual change because they don’t like automation or they are just fixing something quickly). There should be tooling built around the SoT in this approach that compares the SoT and the actual network. This provides assurance and compliance that the network is operating as expected.

Note

Based on the network technology deployed or your preference, another approach is also possible when implementing a SoT. The alternative is to ensure the SoT reflects what exists on the network. This approach may be used as a one-time event to turn the initial data population into a SoT. This may seem a little confusing because it goes against the purist view of SoT, but we thought it is worth calling out because it is reality.

With the growth of NetDevOps over the past few years, one common place to start with a SoT is to define data in a YAML file and version it in a Git repository. The YAML data is the intended state. That data gets rendered with one or more templates to generate the intended configuration, which is later deployed to the network. This approach provides peer review (through pull and merge requests) on the data before being merged and later deployed and also enables users to run automated tests with CI on the data providing even more assurances the data is good. This approach of defining the data first and having that drive automation is what data-driven network automation is all about.

Due to the plethora of technologies that exist today from SDN and cloud-native networking, networks are not always planned – they may be dynamic. There may be auto-scaling or dynamic policies. In these types of environments, you may prefer to see the actual state in one place. This is also possible by using a SoT. With this approach, it is more analogous to a discovery engine, but for configuration data.

It is also possible to employ a hybrid approach. This would mean certain data in the SoT is authoritative and drives the intent of the network, and other data shows what exists in certain domain managers, controllers, or clouds. The general assumption here would be that the data added via controllers or the cloud is authoritative and what is intended to be configured.

Overall, it’s always worth remembering that not all purist points of view and ideals can be implemented in a network that has been evolving for 25 years. We need to take a pragmatic approach, but it is important to recognize proper definitions and terminology to ensure everyone embarking on their SoT journey is on the same page.

Keeping the purist view in mind allows us to see the relationship between network data and network automation, given the data is ultimately at the center and driving network automation. The beautiful thing about data-driven network automation is that it allows us to start thinking about abstractions and the level of intent that we want to describe the network.

Even in this book, we’re talking about lower-level data, which leads to lower-level intent. However, once you’ve embraced data, it is possible to build abstractions around design. Consider the earlier example at a higher level of intent:

connection:    source:
        device: nyc-sw-01
        interface: GigabitEthernet4/1
    destination:
        device: och-sw-01
        interface: GigabitEthernet1/1
    type: off_campus

In this example YAML data file, you’ll notice off_campus defined as a type. This was not used in the prior example. With logic in your templates and automation, the right data will be generated and then populated in the SoT based on the standard off_campus designs for both required devices. You could go one step further and not even choose the devices and let the automation tell you the ports to use on particular devices that have capacity. This will take time, but it starts with repeatable standards (few to no snowflakes) and data, meaning it starts with SoT.

SoT tools and products

After learning more about SoT and the role of network data in network automation, we’re ready to look at SoT tools and products. The fact is that there are not many tools that focus on network data specifically for network automation. Let’s look at some tools that may be used in building out an overarching SoT strategy. Some are more common than others:

  • Nautobot: It should be obvious and is likely the reason you’re reading this book, but we believe Nautobot is the SoT for networking. With native models, extensibility, and a framework in place for aggregating data to and from other data sources, it is becoming the de facto standard for enterprises adopting a SoT for network automation. Nautobot is an open source project sponsored by Network to Code. Network to Code’s mission is to continue to drive network automation around the world, one network at a time.
  • YAML files: Usually playing a part in almost every network automation journey, they provide a solid path to getting started and understanding data-driven network automation. In Chapter 6, we’ll look at integrating YAML files stored in a Git repository directly into Nautobot – showing that with the click of a button, those files and data can be pulled directly into Nautobot.
  • NetBox: The motivation for Nautobot, NetBox is a solution that models and documents modern networks. NetBox is an open source project sponsored by NetBox Labs. Nautobot forked NetBox when NetBox was at v2.10 and has continued to diverge (as a hard fork (https://producingoss.com/en/forks.html#:~:text=Hard%20forks%20(also%20sometimes%20called,line%20with%20their%20own%20vision)) since February 2021.
  • Configuration management databases (CMDBs): More often than not, CMDBs are part of a greater ITSM strategy, including ServiceNow and BMC Remedy. These tools may be used as the SoT for inventory or general asset management but are usually not used to model network configuration data due to a lack of data models, lack of skills, and how these teams are often disconnected from the network teams. These tools are often built off auto-discovery engines with a general trend toward showing what is versus the intended state.
  • Device42: This is usually seen and adopted for data center infrastructure management (DCIM) with a focus on inventory, data center design, rack layouts, and IPAM with automated discovery. Similar to CMDBs, there is a focus on auto-discovery with a general trend toward showing what is versus the intended state, but usually not used to model actual network configurations such as routing, interfaces, and more and powering network automation solutions.
  • Infoblox and BlueCat: Arguably the most widely deployed IPAM solutions, their focus is on IPAM. They also have discovery capabilities. They have some SoT branding and marketing, but usually, it’s on discovering IPs versus defining the intent of IP schemes and having that drive automation.

These are just a select few tools that exist on the market and are being used by network teams. What we believe, and the premise for creating this book, is that Nautobot has grown immensely over the past 2 years and fills a gap in the market as an enterprise network SoT catered specifically for network automation. Through the remainder of this book, we hope you’ll see what Nautobot has to offer and how it can act as the SoT and nucleus to power your data-driven network automation stack on your network automation journey.

Finally, let’s dive into Nautobot.

Nautobot overview

Nautobot is an open source network SoT and automation platform that launched in February 2021. Being an open source company-sponsored project, its maintainers are from the official sponsor – Network to Code. Network to Code is a network automation solutions provider that helps clients around the world build and deploy network automation technology.

It’s now been over 2 years since the launch of Nautobot and there has been significant growth, traction, and development by the Nautobot core team, as well as the community. There have been nine minor releases since inception with the second major release, 2.0, that just launched in September 2023. Nautobot 2.0 is a major milestone for the project bringing many new features and improved usability to Nautobot.

Nautobot forked NetBox in February 2021. This was due to the industry’s need for a network SoT that had an immense focus on network automation with great flexibility and extensibility capabilities. Nautobot was also created to foster an ecosystem around an open source network automation platform. The details of the fork can be found at https://blog.networktocode.com/post/why-did-network-to-code-fork-netbox/.

Some statistics, as of March 2024, regarding the project and community are as follows:

  • Over 120 releases, including two major releases, nine minor releases, and 100+ patch releases (on a defined biweekly cadence)
  • Over 1,600 members in the #nautobot channel in NTC Slack (self-signup at https://slack.networktocode.com)
  • Over 110 Nautobot blog posts on the NTC blog (blog.networktocode.com)
  • Over 60 Nautobot YouTube videos in the All Things Nautobot playlist on the Network to Code YouTube channel

We’ll highlight several key Nautobot features in this chapter but will spend a lot more time on them throughout this book.

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

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

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

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

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.

Nautobot ecosystem

The Nautobot ecosystem is comprised of Nautobot apps that solve a variety of use cases. There are already 15+ open source Nautobot apps written by Network to Code and numerous others written by individuals in the community. Keep in mind that a Nautobot app can be as lightweight or as robust as needed to address the requirements at hand. Here are some examples of different types of applications that could be built using the Nautobot App developer API:

  • Lightweight examples:
    • Create a database table, UI views, and API to manage NTP
    • Create a new page (UI view) to aggregate data from devices and VLANs the way you want to see it based on relationships
    • Create Nautobot jobs that are distributed through a Nautobot app
    • Create a command runner that fires off commands to selected devices that are already in Nautobot
  • Robust examples:
    • Create an application to store, manage, and deploy firewall policies (inclusive of database tables, views, and APIs).
    • Create an application to discover and crawl the network (inclusive of database tables, views, and APIs).
    • Create an application that performs network configuration backups, generates intended configurations, and performs compliance (which, by the way, exists already in the Golden Config app!). You’ll get a deep dive into Golden Config (https://github.com/nautobot/nautobot-app-golden-config) with Nautobot in Appendix 3.

Note

There is also a Nautobot app template in the form of a cookie-cutter GitHub repository (https://github.com/nautobot/cookiecutter-nautobot-app) that helps anyone create a new app.

If you can’t see it already, the opportunities are endless with Nautobot apps.

As mentioned previously, the Nautobot ecosystem already consists of many Nautobot Apps. We’ll take a look at a summary of a few of them while diving into a few of these in Chapter 13:

Summary

This chapter provided a general overview of data-driven network automation with Nautobot. It started by reviewing key use cases for network automation before highlighting the important relationship between data and network automation. It should be evident that getting an understanding of the data that drives network automation should not be understated and that having good, clean data will simplify the overall network automation journey. Finally, this chapter provided an overview of Nautobot and its two key use cases – SoT and network automation platform, and how both are further enhanced through its developer API and the Nautobot ecosystem that continues to grow with open source apps such as Firewall Models and Golden Config.

In the next chapter, we’ll explore and start to understand the data models at the core of Nautobot.

Left arrow icon Right arrow icon
Download code icon Download Code

Key benefits

  • Learn how documenting your network in Nautobot can accelerate your network automation journey
  • Apply NetDevOps to your network by leveraging Nautobot as a network source of truth
  • Minimize tool sprawl by extending, using, or building Nautobot Apps
  • Purchase of the print or Kindle book includes a free PDF eBook

Description

Nautobot enables network teams to build a scalable and extensible network source of truth that provides a foundation to power any network automation stack. With the help of this guide, you’ll learn how to deploy, manage, and integrate Nautobot as a source of truth and network automation platform. As you progress, you’ll learn what a network source of truth is, the relationship between data and network automation, and network data models. You’ll also gain a broad understanding of Nautobot and its robust features that allow maximum flexibility. A dedicated section will show you how to construct a single source of truth with Nautobot and help you explore its programmatic APIs, including REST APIs, GraphQL, webhooks, and Nautobot Job Hooks. Later, you’ll develop custom data models and custom apps for Nautobot and experience its extensibility and powerful developer API. In the last part of this book, you'll discover how to deploy configuration compliance and automated remediation once Nautobot is deployed as a network source of truth. By the end of this book, you’ll be able to design and manage Nautobot as a network source of truth, understand its key features, and extend Nautobot by creating custom data models and apps that suit your network and your team.

Who is this book for?

This book is for network engineers, network automation engineers, and software engineers looking to support their network teams by building custom Nautobot Apps. A basic understanding of networking (e.g. CCNA) and knowledge of the fundamentals of Linux, Python programming, Jinja2, YAML, and JSON are needed to get the most out of this book.

What you will learn

  • Understand network sources of truth and the role they play in network automation architecture
  • Gain an understanding of Nautobot as a network source and a network automation platform
  • Convert Python scripts to enable self-service Nautobot Jobs
  • Understand how YAML files in Git can be easily integrated into Nautobot
  • Get to grips with the NetDevOps ecosystem around Nautobot and its app ecosystem
  • Delve into popular Nautobot Apps including Single Source of Truth and Golden Config
Estimated delivery fee Deliver to Mexico

Standard delivery 10 - 13 business days

Mex$149.95

Premium delivery 3 - 6 business days

Mex$299.95
(Includes tracking information)

Product Details

Country selected
Publication date, Length, Edition, Language, ISBN-13
Publication date : May 28, 2024
Length: 816 pages
Edition : 1st
Language : English
ISBN-13 : 9781837637867
Languages :
Tools :

What do you get with Print?

Product feature icon Instant access to your digital eBook copy whilst your Print order is Shipped
Product feature icon Paperback book shipped to your preferred address
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Product feature icon AI Assistant (beta) to help accelerate your learning
Estimated delivery fee Deliver to Mexico

Standard delivery 10 - 13 business days

Mex$149.95

Premium delivery 3 - 6 business days

Mex$299.95
(Includes tracking information)

Product Details

Publication date : May 28, 2024
Length: 816 pages
Edition : 1st
Language : English
ISBN-13 : 9781837637867
Languages :
Tools :

Packt Subscriptions

See our plans and pricing
Modal Close icon
$19.99 billed monthly
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Simple pricing, no contract
$199.99 billed annually
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just Mex$85 each
Feature tick icon Exclusive print discounts
$279.99 billed in 18 months
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just Mex$85 each
Feature tick icon Exclusive print discounts

Frequently bought together


Stars icon
Total Mex$ 2,492.97 3,077.97 585.00 saved
Network Automation with Nautobot
Mex$1128.99
Generative AI for Cloud Solutions
Mex$645.99 Mex$922.99
ChatGPT for Cybersecurity Cookbook
Mex$717.99 Mex$1025.99
Total Mex$ 2,492.97 3,077.97 585.00 saved Stars icon

Table of Contents

22 Chapters
Part 1: Introduction to Source of Truth and Nautobot Chevron down icon Chevron up icon
Chapter 1: Introduction to Nautobot Chevron down icon Chevron up icon
Chapter 2: Nautobot Data Models Chevron down icon Chevron up icon
Part 2: Getting Started with Nautobot Chevron down icon Chevron up icon
Chapter 3: Installing and Deploying Nautobot Chevron down icon Chevron up icon
Chapter 4: Understanding the User Interface and Bootstrapping Nautobot Chevron down icon Chevron up icon
Chapter 5: Configuring Nautobot Core Data Models Chevron down icon Chevron up icon
Chapter 6: Using Nautobot’s Extensibility Features Chevron down icon Chevron up icon
Chapter 7: Managing and Administering Nautobot Chevron down icon Chevron up icon
Part 3: Network Automation with Nautobot Chevron down icon Chevron up icon
Chapter 8: Learning about Nautobot APIs – REST, GraphQL, and Webhooks Chevron down icon Chevron up icon
Chapter 9: Understanding Nautobot Integrations for NetDevOps Pipelines Chevron down icon Chevron up icon
Chapter 10: Embracing Infrastructure as Code with Nautobot, Git, and Ansible Chevron down icon Chevron up icon
Chapter 11: Automating Networks with Nautobot Jobs Chevron down icon Chevron up icon
Chapter 12: Data-Driven Network Automation Architecture Chevron down icon Chevron up icon
Part 4: Nautobot Apps Chevron down icon Chevron up icon
Chapter 13: Learning about the Nautobot App Ecosystem Chevron down icon Chevron up icon
Chapter 14: Intro to Nautobot App Development Chevron down icon Chevron up icon
Chapter 15: Building Nautobot Data Models Chevron down icon Chevron up icon
Chapter 16: Automating with Nautobot Apps Chevron down icon Chevron up icon
Index Chevron down icon Chevron up icon
Other Books You May Enjoy Chevron down icon Chevron up icon