Why Terraform for Network Engineers?

Part 1 of the “Terraform for Network Engineers” series

CLI Drudgery

As network engineers, our days often consist of repetitive commands, endless copy-pasting, and the constant fear that a typo could disrupt a critical service. I remember an incident from my first job as a Network Administrator. I needed to add a VLAN to a trunk on a Cisco switch. The command, switchport trunk allowed vlan, requires the crucial add keyword to append new VLANs without overwriting existing ones. In my inexperience, I hastily pasted the command, omitting “add.” Suddenly, the management VLAN disappeared, and I lost access to the switch on the far end. Fortunately, it didn’t cause a production outage, but it did cause an unplanned trip to the hub to physically regain access and correct the mistake.

The Shift in Networking

The network world has been evolving rapidly. We’re transitioning from a purely command-line interface (CLI) driven reality to one increasingly defined by APIs, software-defined networking (SDN), and automation. The cloud network platforms offer templates to aid in standardization and reduce repetitive tasks, but the chances that your entire network stack is under one platform is slim. To keep pace, network engineers need new tools and a new mindset. This is where Infrastructure as Code (IaC) steps in, and in this post specifically, Terraform.

More and more, companies expect their network teams to achieve more with less resources – whether that means managing larger, more complex environments with the same headcount, or accelerating deployments without additional budget. The modern network is no longer a static entity; it must constantly adapt to new real-time applications, evolving security threats, and business needs. Devices are increasingly API-driven, offering programmatic interfaces that unlock new levels of control and observability. This shift requires network engineers to expand their skillset – not to abandon their networking fundamentals, but to enhance them with automation, scripting, and coding capabilities. It’s about working smarter, not just harder, and leveraging tools that can manage complexity at scale.

Among the various IaC tools, HashiCorp Terraform has emerged as a leader due to its versatility and platform-agnostic nature. While often associated with cloud provisioning, Terraform’s strength lies in its ability to manage any infrastructure with an API. This makes it incredibly powerful for controlling network devices, whether they’re in the cloud, on-premises, or managed via a vendor’s cloud platform.

Core Terraform Concepts (A Network Engineer’s Perspective):

To understand how Terraform speaks “network,” let’s break down its fundamental building blocks:

• Providers : Think of Providers as the essential drivers or plugins that enable Terraform to communicate with different network vendors and services. Just like a network driver allows your computer to talk to a NIC, a Terraform provider (like the Meraki or the Mist) translates your Terraform configuration into the specific API calls that your network device or cloud management platform understands. Each provider exposes a set of resources and data sources unique to its platform.
• Resources : These are the actual network objects or components you want to create, manage, or delete. In Terraform’s declarative language (HashiCorp Configuration Language or HCL), you define a desired state for these resources. For example, you might declare a meraki_network to create a new Meraki network, a mist_site_wlan for a Wi-Fi SSID, a netbox_vlan to define a VLAN in your IPAM, or a netbox_prefix to allocate an IP subnet. Terraform’s job is to ensure that the real-world resource matches your declared configuration.
• Data Sources : While resources manage infrastructure, data sources allow Terraform to read information about existing infrastructure or external systems without managing them. This is incredibly powerful for dynamic configurations. For example, you might use a data source to query your Meraki Organization ID, your Mist org inventory, fetch a list of Netbox VLANs, or even retrieve an IP reservation from your IPAM system. These existing facts can be used in your Terraform configuration to build new resources or make decisions.
• State File (.tfstate): This is perhaps the most critical concept for managing network changes. The Terraform state file is a JSON file that acts as Terraform’s memory. It records a mapping between your Terraform configuration and the actual real-world resources that have been deployed. This file is crucial because it allows Terraform to:
  • Know which existing resources it manages (someone can still create configurations that Terraform doesn’t know about!)
  • Understand what changes need to be made (plan).
  • Prevent accidental modifications or unintended resource creation.
  • Track dependencies between resources. For team environments, this state file is typically stored remotely (e.g., in Terraform Cloud or a cloud storage bucket) and locked to prevent conflicts during concurrent operations.
• Modules : Think of modules as reusable, self-contained blueprints of Terraform code. Instead of writing the same configuration block repeatedly for common network patterns (e.g., “a standard branch office VLAN block,” “a basic firewall policy set”), you can define it once as a module. This promotes consistency, reduces code duplication (the “Don’t Repeat Yourself” or DRY principle), and accelerates deployments. Modules can be sourced locally, from a version control system like Git, or from a public/private registry.
• Terraform’s core strength lies in its declarative nature. You define what you want the network to look like, and Terraform figures out how to get there, handling dependencies and performing changes in the correct order. This is a significant shift from imperative scripting, where you explicitly define every step that needs to happen.

The Basic Terraform Workflow:

• While we’ll dive deeper into this in subsequent posts, understanding the core commands will give you a head start:
  • terraform init: Initializes a working directory containing Terraform configuration files. This command downloads the necessary provider plugins and sets up the backend for state storage. You run this command once when starting a new configuration or when updating providers/modules.
  • terraform plan: This command creates an “execution plan.” It compares your desired configuration with the current state of your real-world infrastructure (as recorded in the state file and by querying providers). It then shows you exactly what Terraform will create, modify, or destroy. This is your safety net – always review the plan!
  • terraform apply: This is the command that executes the changes proposed in the plan. Terraform will prompt you for confirmation before making any modifications to your live network infrastructure. Once confirmed, Terraform makes the necessary API calls to bring your infrastructure into the desired state.
  • terraform state: This is a set of commands to view or perform basic modifications of the state.
  • terraform destroy: (Used with caution!) This command is a convenient way to tear down all the remote objects managed by a particular Terraform configuration. It’s great for lab environments or ephemeral resources, but should be used with extreme care in production.

Beyond the Cloud: IaC for On-Prem & Vendor-Specific Networks

• When you hear “Infrastructure as Code,” the first images that often come to mind are cloud resources: spinning up EC2 instances, configuring Azure Virtual Networks, or deploying Google Cloud Functions. And while Terraform excels in these environments, its power isn’t limited to the hyperscalers. This series is different.
• Our focus is squarely on real-world network devices and services that network engineers interact with daily. We’re not going to spend our time building cloud VPCs (though Terraform is great for that!). Instead, we’ll demonstrate how Terraform can directly manage:
  • Cloud-Managed Network Gear: We’ll dive into practical examples with solutions like Cisco Meraki (for firewalls) and Juniper Mist (for switches and wireless access points). These platforms offer robust APIs that Terraform can leverage to configure networks, VLANs, SSIDs, and more.
  • Network Source of Truth (Netbox): Crucially, a network isn’t just about devices; it’s about the data that defines it. We’ll deeply integrate with Netbox (specifically using the e-breuninger/netbox provider) to automate IP address management (IPAM), VLAN allocation, and ensure your network documentation is always up-to-date and consistent with your deployed infrastructure. Netbox will serve as our authoritative source for all network numbering and inventory.
  • On-Premises Devices (even without a native provider!): This is where we’ll tackle a truly complex scenario. We’ll explore different ways to manage devices that don’t have a direct Terraform provider. This will push the boundaries of what’s possible, showing you how to integrate directly with a device’s API and creatively manage its state within Terraform. This is an advanced skill for any network engineer dealing with a diverse vendor landscape.
• This approach will give you tangible, directly applicable skills for automating tasks in your existing network environments, bridging the gap between traditional networking and modern IaC practices.

Getting Started: What You’ll Need

• Embarking on your network automation journey with Terraform is straightforward. To follow along with this series and begin hands-on practice, here’s what you’ll primarily need:
  • Terraform CLI : This is the command-line interface tool that you’ll use to write, plan, and apply your Terraform configurations. It’s lightweight and easy to install across various operating systems. We’ll provide specific installation instructions and links in our next post, but you can always find the latest version on the official HashiCorp Terraform website.
  • A Code Editor: While you can technically use any text editor, I use Visual Studio Code (VS Code). It’s free, cross-platform, and has excellent community support. Be sure to install the HashiCorp Terraform extension for VS Code, which provides syntax highlighting, auto-completion, and other helpful features specifically for Terraform’s configuration language.
  • Access to Meraki & Mist Accounts (with API Keys): For our practical examples in upcoming posts, you’ll need API access keys configured in your respective Cisco Meraki and Juniper Mist dashboards. Ensure these keys have appropriate permissions for creating and modifying network resources. If you don’t have production access, you can look for developer portals that give you a sandbox environment. Alternatively, you can still follow along by reading the code and output, understanding the concepts, and adapting them to your own network environment.
  • A Netbox Instance : A working instance of Netbox will be absolutely essential for managing our IPAM and network inventory. This can be a local lab setup (e.g., using Docker), a virtual machine, or a cloud-hosted instance. Having a dedicated lab environment for Netbox will allow you to experiment freely without impacting production data.

Conclusion: Your Network’s Future is Code

• Adopting Infrastructure as Code with Terraform isn’t just another trend; it’s a fundamental shift that empowers network engineers to build more resilient, agile, and consistent networks. It frees you from the tedious manual tasks, allowing you to focus on high-value activities like network design, optimization, and innovation. Embracing IaC means moving towards a proactive, programmatic approach to network management, reducing errors, and accelerating deployments.
• In this post, we’ve laid the theoretical groundwork, explaining the “why” behind IaC for networks and introducing Terraform’s core concepts. In the next post, we’ll roll up our sleeves, get our development environment set up, and provision our very first network resources using Terraform with Cisco Meraki and Juniper Mist. Get ready to write some code and take your first practical step toward a fully automated network!