AutomationCCNA 200-301

Terraform IOS XE Provider Not Applying Configuration

Presenting Symptom

Terraform apply completes successfully but the intended IOS XE configuration (e.g., VLAN, interface IP) is not present on the device after the run.

Network Context

A small branch office with a Cisco Catalyst 9300 running IOS XE 17.3. The network engineer uses Terraform with the Cisco IOS XE provider to automate configuration. The Terraform plan shows changes, but after apply, the device configuration remains unchanged. The engineer has verified network connectivity to the device and that the device is reachable via SSH.

Diagnostic Steps

Check Terraform state and plan output

terraform show

Output showing the current state resources and their attributes. For example, a VLAN resource might show `vlan_id = 10` but `name = ""` if not applied.

Compare the state with the intended configuration. If the state shows the desired values but the device does not, the issue is likely in the provider's ability to push config. If the state is empty or shows no changes, the provider may not be detecting drift.

Enable Terraform debug logging

export TF_LOG=DEBUG; terraform apply -auto-approve

Detailed logs showing HTTP requests to the device's RESTCONF/NETCONF API. Look for lines like `POST /restconf/data/Cisco-IOS-XE-native:native/vlan` with response codes.

If the request is sent but returns a 200 OK with no errors, the device accepted the config but may not have applied it (e.g., due to commit behavior). If the request is not sent, the provider may have skipped it due to no diff.

Check device configuration via CLI

show running-config | section vlan

If VLAN 10 was intended, output might show nothing or an incomplete configuration.

If the running config lacks the intended changes, the Terraform provider may have sent the config to candidate datastore but not committed it, or the device rejected the config due to syntax errors not caught by the provider.

Verify NETCONF/RESTCONF commit behavior

show netconf-yang datastores | include candidate

If candidate datastore is supported, output shows `candidate` in the list. If not, only `running` and `startup` are shown.

If the device supports candidate datastore, Terraform may be writing to candidate without committing. If only running is supported, the provider should write directly to running. Check provider configuration for `commit` parameter.

Root Cause

The Terraform provider is configured to use the candidate datastore (default for NETCONF) but the device requires an explicit commit operation to apply changes to running config. The provider's `commit` parameter is set to `false` or not set, so changes remain in candidate and are never applied.

Resolution

Update the Terraform provider configuration to set `commit = true` or ensure the provider uses the running datastore. Example: provider "iosxe" { host = "192.168.1.1" username = "admin" password = "password" commit = true } Alternatively, if using RESTCONF, ensure the provider uses `PUT` or `PATCH` directly to running datastore by setting `restconf = true` and `commit = false` (since RESTCONF writes directly to running).

Verification

Run `terraform apply` again and then check the device: `show running-config | section vlan`. Expected output should now show the VLAN configuration, e.g., `vlan 10\n name Engineering`.

Prevention

1. Always test Terraform changes in a lab environment first. 2. Understand the device's NETCONF/RESTCONF capabilities and configure the provider accordingly. 3. Use Terraform's `plan` to verify changes before apply, and enable debug logging during initial setup.

CCNA Exam Relevance

On the CCNA 200-301 exam, this scenario tests understanding of automation tools and device management protocols. Questions may present a troubleshooting scenario where a configuration push via RESTCONF/NETCONF fails, and the candidate must identify that the commit operation is missing. The exam expects knowledge of NETCONF datastores (candidate vs. running) and the need for explicit commit.

Exam Tips

Remember that NETCONF uses candidate datastore by default and requires a commit; RESTCONF writes directly to running.

The exam may ask which protocol is best for transactional changes: NETCONF (with commit/rollback) vs RESTCONF (immediate).

Know that `show netconf-yang datastores` reveals available datastores; if candidate is missing, the device only supports direct writes to running.

Commands Used in This Scenario

show running-config

Displays the current active configuration in DRAM, showing all non-default settings.

Test Your CCNA Knowledge

Practice with scenario-based questions to prepare for the CCNA 200-301 exam.

Practice CCNA Questions