Cisco Nexus VRF and OSPF Lab Configuration

Originally, this exercise was performed on the Cisco Nexus 7000 (N7K) Titanium emulator, a tool that was instrumental for hands-on learning over a decade ago. While the foundational concepts of Virtual Routing and Forwarding (VRF) and Open Shortest Path First (OSPF) configuration on Cisco Nexus remain highly relevant, the network landscape, platforms, and operational methodologies have evolved significantly. This updated guide transitions the lab environment to modern alternatives like Cisco Modeling Labs (CML) 2.x or EVE-NG, and incorporates best practices relevant for the current-generation Cisco Nexus 9000 Series switches. We’ll cover not just the traditional CLI configuration but also introduce how network automation tools are used today.

For this lab, I’m emulating two Nexus switches (N7K-1 and N7K-2) to demonstrate VRF and OSPF interaction. Back when this guide was first written, I used VMware Workstation to host the Titanium N7K virtual machines. The original setup involved connecting virtual network adapters in VMware to emulate physical interfaces on the N7K.

The principle of mapping virtual interfaces (e.g., Eth2/1 on the Nexus) to underlying host network interfaces (e.g., Vmnet4 in VMware Workstation, or virtual bridges in CML/EVE-NG) is still crucial. I would confirm this mapping by toggling interface states and observing changes with show interface brief on the Nexus console.

In our setup, Eth2/1 on both Nexus switches is logically connected via a shared virtual network (Vmnet4 in the original context, or a shared bridge in CML/EVE-NG). Ensuring they are on the same virtual segment is critical for them to establish connectivity. Now, let’s dive into the configuration.

Step 1: Initial Device Configuration – Hostnames and Interface IPs

First, I’ll assign hostnames to distinguish our two Nexus devices. This is a fundamental step for clarity in any network environment.

N7K# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
N7K(config)# hostname N7K-1

I would repeat this for the second machine, assigning it the hostname N7K-2.

Next, I’ll assign IP addresses to the Eth2/1 interfaces on both Nexus switches and bring them up. This establishes the basic Layer 3 connectivity between our two devices.

# On N7K-1:
N7K-1(config)# interface Ethernet2/1
N7K-1(config-if)# ip address 12.12.12.1/24
N7K-1(config-if)# no shutdown

# On N7K-2:
N7K-2(config)# interface Ethernet2/1
N7K-2(config-if)# ip address 12.12.12.2/24
N7K-2(config-if)# no shutdown

After configuring the IP addresses, I’ll verify basic connectivity by pinging across the interfaces. This is a crucial first check.

N7K-1(config)# ping 12.12.12.2
PING 12.12.12.2 (12.12.12.2): 56 data bytes
64 bytes from 12.12.12.2: icmp_seq=0 ttl=254 time=1.747 ms
64 bytes from 12.12.12.2: icmp_seq=1 ttl=254 time=1.262 ms
64 bytes from 12.12.12.2: icmp_seq=2 ttl=254 time=1.423 ms
64 bytes from 12.12.12.2: icmp_seq=3 ttl=254 time=1.396 ms
64 bytes from 12.12.12.2: icmp_seq=4 ttl=254 time=1.58 ms

--- 12.12.12.2 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 1.262/1.481/1.747 ms

Step 2: Configuring VRF Instances and Interface Assignments

VRF (Virtual Routing and Forwarding) is a powerful technology that allows a single router or switch to host multiple independent routing tables. This is fundamental for network segmentation and multi-tenancy. By default, most interfaces on a Nexus device are assigned to the “default” VRF, except for the mgmt0 interface, which belongs to the “management” VRF for out-of-band access.

I’ll create a new VRF instance called OSPF-VRF. Then, I’ll create a Loopback0 interface on N7K-1 (10.10.10.10/32) and assign both Eth2/1 and Loopback0 to this new VRF. Loopback interfaces are often used as stable router IDs and for advertising internal networks within routing protocols.

# On N7K-1:
N7K-1(config)# vrf definition OSPF-VRF
N7K-1(config-vrf)# address-family ipv4 unicast
N7K-1(config-vrf-af)# exit
N7K-1(config-vrf)# exit

N7K-1(config)# interface Ethernet2/1
N7K-1(config-if)# vrf member OSPF-VRF
N7K-1(config-if)# ip address 12.12.12.1/24  # Re-apply IP after VRF assignment
N7K-1(config-if)# no shutdown

N7K-1(config)# interface Loopback0
N7K-1(config-if)# vrf member OSPF-VRF
N7K-1(config-if)# ip address 10.10.10.10/32
N7K-1(config-if)# no shutdown

To verify the VRF assignments, I use the show vrf interface command. This confirms which interfaces are associated with OSPF-VRF.

I can also inspect the running configuration for the specific VRF to see its associated interfaces.

Now, I’ll apply the same VRF configuration on N7K-2, but with a different Loopback IP address (20.20.20.20/32).

# On N7K-2:
N7K-2(config)# vrf definition OSPF-VRF
N7K-2(config-vrf)# address-family ipv4 unicast
N7K-2(config-vrf-af)# exit
N7K-2(config-vrf)# exit

N7K-2(config)# interface Ethernet2/1
N7K-2(config-if)# vrf member OSPF-VRF
N7K-2(config-if)# ip address 12.12.12.2/24  # Re-apply IP after VRF assignment
N7K-2(config-if)# no shutdown

N7K-2(config)# interface Loopback0
N7K-2(config-if)# vrf member OSPF-VRF
N7K-2(config-if)# ip address 20.20.20.20/32
N7K-2(config-if)# no shutdown

Step 3: OSPF Configuration within the VRF

With our VRF instances and interface assignments complete, I’ll proceed with the OSPF configuration. This lab specifically runs OSPF within the OSPF-VRF context to demonstrate its functionality alongside VRFs. In NX-OS, similar to Cisco IOS, we first enable the OSPF feature globally and then configure the OSPF process within the VRF.

# Enable OSPF feature globally on both N7K-1 and N7K-2
N7K-1(config)# feature ospf

# On N7K-1:
N7K-1(config)# router ospf 1 vrf OSPF-VRF
N7K-1(config-router)# router-id 10.10.10.10
N7K-1(config-router)# interface Ethernet2/1
N7K-1(config-router-if)# ip ospf network point-to-point
N7K-1(config-router-if)# ip ospf area 0
N7K-1(config-router-if)# exit
N7K-1(config-router)# interface Loopback0
N7K-1(config-router-if)# ip ospf area 1
N7K-1(config-router-if)# exit

# On N7K-2:
N7K-2(config)# router ospf 1 vrf OSPF-VRF
N7K-2(config-router)# router-id 20.20.20.20
N7K-2(config-router)# interface Ethernet2/1
N7K-2(config-router-if)# ip ospf network point-to-point
N7K-2(config-router-if)# ip ospf area 0
N7K-2(config-router-if)# exit
N7K-2(config-router)# interface Loopback0
N7K-2(config-router-if)# ip ospf area 2
N7K-2(config-router-if)# exit

Here, Eth2/1 is assigned to OSPF Area 0 (the backbone area), while the Loopback0 interfaces are assigned to different areas (Area 1 on N7K-1 and Area 2 on N7K-2). This demonstrates a multi-area OSPF design within a VRF. Assigning the network type as point-to-point on Eth2/1 simplifies neighbor discovery and reduces overhead in a direct link scenario.

Step 4: Verification and Troubleshooting OSPF

After configuring OSPF, the next critical step is to verify neighborship and route advertisements. I use various show commands, always remembering to specify the VRF context to see VRF-specific information.

# On N7K-1:
N7K-1# show ip ospf neighbor vrf OSPF-VRF
N7K-1# show ip route vrf OSPF-VRF
N7K-1# show ip ospf interface brief vrf OSPF-VRF

I can also clear the OSPF process to troubleshoot or force a re-convergence. For instance, to clear a specific neighbor relationship or restart the entire OSPF process within the VRF:

N7K-1# clear ip ospf neighbor 20.20.20.20 vrf OSPF-VRF
N7K-1# restart ospf 1 vrf OSPF-VRF

Monitoring OSPF traffic can provide insights into protocol operation, including hello packet exchanges and database synchronization.

N7K-1# show ip ospf traffic vrf OSPF-VRF

OSPF authentication is crucial for securing routing updates and preventing unauthorized routers from participating in the OSPF domain. While basic MD5 authentication has been common, modern deployments should prioritize stronger methods like SHA-256 via key chains for enhanced security. The configuration syntax is largely consistent between Cisco IOS and NX-OS.

# Example for OSPF authentication using MD5 (for legacy compatibility)
# On interface level for Eth2/1 within OSPF-VRF:
N7K-1(config-if)# ip ospf authentication message-digest
N7K-1(config-if)# ip ospf message-digest-key 1 md5 "MySecretKey"

# For modern deployments, prefer SHA-256 with key chains:
N7K-1(config)# key chain OSPF_AUTH_KEY
N7K-1(config-keychain)# key 1
N7K-1(config-keychain-key)# key-string "StrongSHA256Key"
N7K-1(config-keychain-key)# cryptographic-algorithm hmac-sha256
N7K-1(config-keychain-key)# exit
N7K-1(config-keychain)# exit

N7K-1(config)# interface Ethernet2/1
N7K-1(config-if)# ip ospf authentication key-chain OSPF_AUTH_KEY

Modernizing VRF and OSPF: From N7K to Nexus 9000 and Automation

While the core VRF and OSPF configurations demonstrated above remain valid, modern data center networks, particularly those built on the Cisco Nexus 9000 Series, leverage advanced capabilities and automation. Here’s a look at how these concepts are applied and extended today:

Cisco Nexus 7000 vs. Nexus 9000: A Platform Evolution

• Nexus 7000 Series: While still supported in many legacy environments, the N7K is largely superseded by the N9K for new deployments. N7K was known for its modularity and high performance in its era.
• Nexus 9000 Series: These platforms offer significantly higher density, lower power consumption, and support for 400G and beyond. Crucially, they are the foundation for Cisco Application Centric Infrastructure (ACI) and robust VXLAN EVPN fabrics, which have become the standard for modern data centers.

VRF and OSPF in Modern Data Centers: Beyond Basic Segmentation

The basic VRF setup is the starting point. In complex multi-tenant or hybrid cloud environments, we often see:

• BGP-based VRF Segmentation: Route Targets (RTs) are used with BGP EVPN to import and export VRF routes across a VXLAN overlay, enabling seamless multi-tenancy across the entire data center fabric.
• VRF Route Leaking: Controlled sharing of routes between different VRFs for specific service needs (e.g., shared services VRF), implemented with route-maps and BGP policies.
• OSPF vs. BGP EVPN: While OSPF is excellent for intra-area routing and smaller networks, BGP with EVPN is the dominant choice for scalable data center fabrics. It provides better control over route distribution, supports multi-tenancy natively through VXLAN, and integrates well with external networks and cloud environments. Understanding both is key for a modern network engineer.

Automation: From CLI to Infrastructure as Code (IaC)

Manually configuring devices via CLI, as shown in the original steps, introduces human error and doesn’t scale. Modern network operations rely heavily on automation:

• Ansible: Playbooks using the cisco.nxos collection can declaratively define VRF, OSPF, and interface configurations. This allows for idempotent, repeatable deployments.
• Terraform: With the cisco-nxos provider, Terraform can manage the lifecycle of Nexus configurations as Infrastructure as Code, integrating network changes into a broader cloud or data center provisioning workflow.
• NETCONF/YANG: Nexus switches support model-driven programmability using NETCONF and YANG data models (e.g., OpenConfig). This allows for programmatic configuration and telemetry streaming, moving away from screen-scraping CLI output.

Example: Ansible Playbook Snippet for VRF and OSPF

Here’s a conceptual Ansible playbook snippet that performs similar VRF and OSPF configurations:

---
- name: Configure Nexus VRF and OSPF
  hosts: nexus_switches
  gather_facts: false
  connection: network_cli

  tasks:
    - name: Configure VRF Definition
      cisco.nxos.nxos_vrf:
        name: OSPF-VRF
        state: present
      
    - name: Configure Loopback0 interface
      cisco.nxos.nxos_interfaces:
        config:
          - name: Loopback0
            description: "Loopback for OSPF-VRF"
            vrf: OSPF-VRF
            ipv4:
              address: "{{ (inventory_hostname == 'N7K-1') | ternary('10.10.10.10/32', '20.20.20.20/32') }}"
            state: present

    - name: Configure Ethernet2/1 interface for OSPF-VRF
      cisco.nxos.nxos_interfaces:
        config:
          - name: Ethernet2/1
            vrf: OSPF-VRF
            ipv4:
              address: "{{ (inventory_hostname == 'N7K-1') | ternary('12.12.12.1/24', '12.12.12.2/24') }}"
            state: present

    - name: Enable OSPF Feature
      cisco.nxos.nxos_feature:
        feature: ospf
        state: enabled

    - name: Configure OSPF Process within VRF
      cisco.nxos.nxos_ospf:
        ospf:
          1:
            vrf: OSPF-VRF
            router_id: "{{ (inventory_hostname == 'N7K-1') | ternary('10.10.10.10', '20.20.20.20') }}"
            interfaces:
              Ethernet2/1:
                area: 0
                network_type: point-to-point
              Loopback0:
                area: "{{ (inventory_hostname == 'N7K-1') | ternary('1', '2') }}"
      state: merged

vPC Integration with OSPF and VRF

In production Nexus environments, Virtual Port Channels (vPC) are ubiquitous for link and device redundancy. When combining vPC with OSPF and VRFs:

• vPC Peer Gateway: This feature is crucial when routing over a vPC, allowing the vPC peers to act as a single logical gateway for devices connected via the vPC.
• OSPF and vPC: OSPF adjacencies can form over vPC links. Careful design is needed, especially concerning Designated Router (DR) election and route advertisement, to ensure optimal traffic flow and fast convergence.

Model-Driven Telemetry and Observability

Instead of relying solely on manual show commands, modern networks use streaming telemetry (e.g., gNMI, pushing data to Kafka or analytics platforms). This provides real-time, granular visibility into OSPF neighbor states, VRF route changes, and interface statistics, enabling proactive monitoring and faster incident response.

Conclusion

This updated guide bridges the gap between foundational Cisco Nexus configuration concepts and the advanced methodologies employed in today’s data centers. While the original N7K and Titanium emulator provided an excellent learning platform for VRF and OSPF, the industry has shifted towards Nexus 9000 Series switches, BGP EVPN for scalability, and automation tools for efficiency and consistency.

As network engineers, embracing these modern tools and platforms, alongside a solid understanding of core routing principles, is essential for building and managing the complex, resilient networks of the future.

• About
• Latest Posts

Afroz Ahmad

I'm Afroz, a Network Engineer and CCIE with more than18 years of experience in Computer Networking, Data Centers, Telecom, Internet Services and ISPs. Currently, I work as a Network Designer for a leading ISP equipment vendor. I share my expertise through my blog and courses, aiming to share my knowledge and simplify complex networking concepts for both beginners and experienced professionals.

Latest posts by Afroz Ahmad (see all)

• How to Configure a Secure Site-to-Site VPN on Cisco Firepower Complete Guide - December 3, 2025
• Jobs for Network Engineers: Roles, Skills & Pay - December 3, 2025
• How to Change WiFi Password on Any Router : The Last Guide You Need - December 1, 2025