Managing Network Resources

Objective

In this lesson you will learn how to model and manage interfaces, VLANs, routing, and ACLs as network resources (the kinds of objects you normally declare in Terraform). You will perform the equivalent configuration on Cisco IOS XE devices using the CLI, then inspect the device's YANG-modeled configuration via RESTCONF/NETCONF conversions. This matters in production because model-driven APIs (NETCONF/RESTCONF/gNMI) are how IaC tools like Terraform eventually interact with devices — validating the intended state before automation pushes changes reduces outages. Real-world scenario: an enterprise is onboarding a new access VLAN, a gateway interface, a static route to a DMZ, and an ACL to limit management access — all of which you would declare as Terraform resources in an automated deployment.

Quick Recap

Refer to the topology presented in Lesson 1 for device names, physical connections, and primary IP addressing. This lesson does not add new devices or IP addresses to that topology; instead, it focuses on resource types you would declare in Terraform and demonstrates the equivalent CLI configuration and YANG/RESTCONF visibility.

Tip: Throughout this lesson we will use the device CLI to make configurations and the CLI helper "show run | format restconf -json" (or "show run | format netconf -xml") to view the modeled configuration a programmability tool would consume.

Key Concepts

• Model-driven configuration (YANG) — YANG models define the schema for device objects (interfaces, VLANs, ACLs). When you declare a Terraform resource for an interface, the end goal is to produce the same structured configuration that a YANG model expects.
  • In production, this lets orchestration systems validate and compare the desired state to device state before committing changes.
• NETCONF vs RESTCONF vs gNMI — NETCONF uses XML and supports candidate datastores and confirm-commit; RESTCONF is REST-like and uses JSON for IOS XE native models; gNMI is binary/efficient and supports telemetry subscriptions.
  • Terraform providers (or intermediate tooling) often use RESTCONF/NETCONF/gNMI to apply or read resources from devices.
• Interfaces and forwarding behavior — Configuring an interface with an IP brings the interface to the L3 forwarding table; the device sends ARP and participates in routing protocols or responds to directly-connected traffic immediately when up.
  • For example, when you enable an IP on an interface, the device creates a connected route in the RIB and advertises adjacency information to local neighbors (ARP/NDP).
• VLANs and SVI mapping — VLAN objects (on switches) and SVIs (Switched Virtual Interfaces) map layer 2 segmentation to layer 3 interfaces. In production, VLANs separate tenant networks, and SVIs provide default gateways.
• ACLs as resources — Access control lists are policy objects that affect packet flow at layer 3/4. When applied to interfaces or as control-plane ACLs, they filter matching traffic — order and specificity matter.

Step-by-step configuration

Step 1: Configure the access VLAN and SVI (VLAN interface)

What we are doing: Create a VLAN (logical Layer 2 segment) and configure an SVI to provide a gateway for hosts. This is what you would declare as a VLAN resource and a corresponding interface resource in Terraform.

configure terminal
vlan 10
 name NHPREP_USERS
exit
interface Vlan10
 description User VLAN SVI for NHPREP
 ip address 192.168.10.1 255.255.255.0
 no shutdown
exit
write memory

What just happened:

• vlan 10 created VLAN ID 10 in the VLAN database and assigned the name NHPREP_USERS. This establishes the L2 segment.
• interface Vlan10 configured the SVI (logical interface). Adding ip address creates a connected route (192.168.10.0/24) in the routing table; the device will respond to ARP requests for 192.168.10.1 and forward traffic between VLANs if routing is enabled. no shutdown activates the SVI provided VLAN 10 exists and at least one layer 2 port is in VLAN 10 (or the switch virtual interface will be administratively up).

Real-world note: In production, SVIs are used as tenant gateways in multi-tenant fabrics. Ensure VLANs are consistently named across your inventory to avoid confusion when generating Terraform state.

Verify:

show vlan id 10
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
10   NHPREP_USERS                     active

show ip interface Vlan10
Vlan10 is up, line protocol is up
  Internet address is 192.168.10.1/24
  Broadcast address is 255.255.255.255
  Address determined by configuration
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA
  Keepalive not set
  Last input never, output never, output hang never
  Last clearing of "show interface" counters never
  IP fast switching is enabled
  Directed broadcast forwarding is disabled

Step 2: Configure a physical interface and access port mapping

What we are doing: Configure a physical switch port as an access port in VLAN 10. In Terraform you would declare the interface and its VLAN membership as resources so host interfaces are consistently configured.

configure terminal
interface GigabitEthernet1/0/1
 description Access port to lab workstation
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast
 no shutdown
exit
write memory

What just happened:

• The interface GigabitEthernet1/0/1 was set to Layer 2 access mode and assigned to VLAN 10. Packets received on this interface will be placed into VLAN 10 and forwarded according to VLAN 10’s L2 forwarding.
• spanning-tree portfast reduces STP convergence delay for access ports, allowing end hosts to start sending traffic quickly.

Real-world note: When automating, make sure interface naming conventions in Terraform match device inventory. Mapping physical ports to VLANs is a frequent source of mistakes when converting spreadsheets to IaC.

Verify:

show interface GigabitEthernet1/0/1 switchport
Name: Gi1/0/1
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Access Mode VLAN: 10 (NHPREP_USERS)
Voice VLAN: none

Step 3: Configure a static route (routing resource)

What we are doing: Add a static route to reach the DMZ network via the edge router. In Terraform this becomes a routing resource (route) attached to the device's routing table.

configure terminal
ip route 192.168.20.0 255.255.255.0 10.1.1.254
exit
write memory

What just happened:

• ip route installed a static route to 192.168.20.0/24 via next-hop 10.1.1.254. The router will forward packets destined for that network to the next hop. If the next-hop is not reachable (no ARP entry or route to next-hop), the static route will be installed but traffic will be dropped until next-hop becomes reachable.

Real-world note: Static routes are often used for DMZ reachability or as a deterministic fallback in enterprise networks. When automating, ensure route resources include next-hop health checks or are complemented by dynamic routing where appropriate.

Verify:

show ip route 192.168.20.0
Routing entry for 192.168.20.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 10.1.1.254
      Route metric is 0, traffic share count is 1

Step 4: Configure an extended ACL for management access

What we are doing: Create an ACL that permits SSH from a management subnet and denies other host-originated TCP to the management plane; apply the ACL in an appropriate context. In Terraform this is modeled as an ACL resource plus an application-binding (for interface or VTY).

configure terminal
ip access-list extended MGMT_FILTER
 permit tcp 192.168.100.0 0.0.0.255 host 192.168.10.1 eq 22
 deny ip any host 192.168.10.1
 permit ip any any
exit
line vty 0 4
 access-class MGMT_FILTER in
 login local
 exit
write memory

What just happened:

• The extended ACL MGMT_FILTER allows SSH (TCP/22) from 192.168.100.0/24 to the device SVI 192.168.10.1, denies other IP traffic to that host (preventing web or other access), then permits the rest of traffic (so ACL is not implicitly deny all on other matches).
• access-class MGMT_FILTER in on vty lines applies the ACL to inbound VTY (management) sessions. This ensures only authorized management hosts can establish SSH sessions. Order matters: ACLs are processed top-to-bottom and the first match wins.

Real-world note: When automating ACLs, always consider implicit denies and the position of ACL entries. Using named ACLs makes resource management easier in IaC.

Verify:

show access-lists MGMT_FILTER
Extended IP access list MGMT_FILTER
    10 permit tcp 192.168.100.0 0.0.0.255 host 192.168.10.1 eq 22
    20 deny ip any host 192.168.10.1
    30 permit ip any any

show running-config | section ip access-list
ip access-list extended MGMT_FILTER
 permit tcp 192.168.100.0 0.0.0.255 host 192.168.10.1 eq 22
 deny ip any host 192.168.10.1
 permit ip any any

Step 5: Convert/configuration visibility — show modeled (RESTCONF/NETCONF) output

What we are doing: Use the CLI helper to convert the device running configuration into the modeled format that programmatic tools read (RESTCONF JSON / NETCONF XML). This is how Terraform (or an intermediate provider) would confirm the device state matches the declared resources.

show run | format restconf -json

What just happened:

• The CLI produced a JSON representation of the native YANG-modeled parts of the configuration. This output is machine-friendly and shows modeled objects such as interfaces, VLANs, and ACLs in a structured schema that tooling consumes.

Real-world note: Many automation workflows fetch this JSON to perform a "read" of device state before deciding to "apply" or "update" the device configuration.

Verify (example output snippet):

{
  "path": [
    {
      "origin": "rfc7951",
      "elem": [
        { "name": "Cisco-IOS-XE-interfaces:interfaces" },
        { "name": "interface",
          "list": [
            {
              "name": "Vlan10",
              "description": "User VLAN SVI for NHPREP",
              "enabled": true,
              "ipv4": {
                "address": [
                  {
                    "ip": "192.168.10.1",
                    "netmask": "255.255.255.0"
                  }
                ]
              }
            },
            {
              "name": "GigabitEthernet1/0/1",
              "description": "Access port to lab workstation",
              "type": "ianaift:ethernetCsmacd",
              "enabled": true
            }
          ]
        }
      ]
    },
    {
      "origin": "rfc7951",
      "elem": [
        { "name": "Cisco-IOS-XE-acl:access-lists" },
        { "name": "acl",
          "list": [
            {
              "name": "MGMT_FILTER",
              "type": "extended",
              "aces": [
                { "sequence": 10, "action": "permit", "protocol": "tcp", "source": "192.168.100.0/24", "destination": "192.168.10.1", "dport": 22 },
                { "sequence": 20, "action": "deny", "protocol": "ip", "source": "any", "destination": "192.168.10.1" },
                { "sequence": 30, "action": "permit", "protocol": "ip", "source": "any", "destination": "any" }
              ]
            }
          ]
        }
      ]
    }
  ],
  "encoding": "JSON_IETF"
}

Verification Checklist

• Check 1: SVI 192.168.10.1 exists and is up — verify with show ip interface Vlan10 and ensure "up/up".
• Check 2: Access port mapped to VLAN 10 — verify with show interface GigabitEthernet1/0/1 switchport and confirm Access Mode VLAN 10.
• Check 3: Static route to 192.168.20.0/24 is present — verify with show ip route 192.168.20.0.
• Check 4: ACL MGMT_FILTER contains the expected entries and is applied — verify show access-lists MGMT_FILTER and show running-config | section ip access-list.

Common Mistakes

Symptom	Cause	Fix
SVI shows "administratively down"	VLAN 10 not created or no L2 port in VLAN 10	Ensure vlan 10 exists and at least one switchport is assigned to VLAN 10; re-create VLAN if necessary
Hosts cannot ping gateway 192.168.10.1	Interface in wrong VLAN or switchport misconfigured	Verify switchport access vlan 10 on port and confirm host is connected to the correct physical port
Static route not used (packet drops)	Next-hop 10.1.1.254 unreachable (no ARP/reachability)	Ensure connectivity to next-hop, or use ip route with interface-based next-hop if appropriate; verify ARP/adjacency
SSH blocked from management host	ACL order denies traffic before permit or ACL not applied to VTY	Check ACL sequence numbers and position; verify access-class MGMT_FILTER in is configured under line vty

Key Takeaways

• Model-driven APIs (YANG via RESTCONF/NETCONF/gNMI) are the programmatic representation of the same interface/VLAN/routing/ACL objects you configure in the CLI; IaC tools consume these modeled representations to enforce desired state.
• When automating with Terraform, you will declare resources for Interfaces, VLANs, Routes, and ACLs; always validate device state by converting running config to modeled JSON/XML (e.g., show run | format restconf -json or show run | format netconf -xml) before applying changes.
• Order and relationships matter: ACL entry ordering affects packet flow, VLAN existence affects SVI state, and route next-hop reachability affects the usefulness of static routes.
• In production, ensure your automation includes pre-validation (read modeled state), transaction safety (candidate/confirm-commit if available), and consistent naming conventions for resources to avoid drift.

Warning: Always test automation against a sandbox or candidate datastore before applying to production. NETCONF supports candidate datastores and confirm-commit workflows which can significantly lower risk when making bulk changes.

If you want, the next lesson will demonstrate how a Terraform provider could consume the RESTCONF JSON output and map it to declarative resources, with examples of the typical resource attributes and lifecycle considerations.