NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Objective

In this lesson you will create macro-segmentation by building multiple Virtual Routing and Forwarding (VRF) instances, map each VRF to a VLAN and a subnet (SVI), and configure route-targets to enable selective route-leaking between VRFs. This matters in production because VRFs allow overlapping IP spaces and strict segmentation — for example, separating Users and IoT networks while still permitting controlled service reachability via a shared services VRF. In a real enterprise SD-Access deployment, this pattern is used to host multiple virtual networks (VNs) on the same physical infrastructure while maintaining isolation and selective connectivity.

Quick Recap

Refer to the topology created in Lesson 1. This lesson does not add new physical devices; we will modify the fabric edge device (the switch acting as the VN gateway) by:

Creating VRFs named A, B, and GLOBAL.
Mapping VLAN 10 and VLAN 20 SVIs to VRF A and VRF B respectively, both using the subnet 1.2.3.1/24 (demonstrating overlapping/equivalent gateway IPs in different VRFs).
Using route-distinguisher (RD) and route-target (RT) values shown in the reference to enable controlled route import/export.

Device names remain as in Lesson 1. The only new configuration objects are the VRFs and SVIs.

Topology (relevant segment)

ASCII diagram below shows the fabric edge device with two virtual networks (VNs) mapped to VLAN SVIs. Each SVI uses the IP 1.2.3.1/24 in its own VRF — illustrating overlapping addressing separated by VRF.

Switch: Fabric-Edge-1

Vlan10 (VRF A): 1.2.3.1/24
Vlan20 (VRF B): 1.2.3.1/24

                             +----------------------+
                             |     Fabric-Edge-1    |
                             |  (VN Gateway / SVI)  |
                             |                      |
                             |  Vlan10 (VRF A)      |
                             |    1.2.3.1/24        |
                             |                      |
                             |  Vlan20 (VRF B)      |
                             |    1.2.3.1/24        |
                             +----------------------+

Important: Both SVIs use the same IP 1.2.3.1/24 but are isolated by their VRF contexts. This is a common design in SD-Access where VN boundaries allow address reuse.

Device Table

Device name	Role
Fabric-Edge-1	VN Gateway / SVI host

IP Addressing

Interface / SVI	VRF	IP Address
Vlan10	A	1.2.3.1/24
Vlan20	B	1.2.3.1/24

Key Concepts (theory + practical)

VRF (Virtual Routing and Forwarding): A VRF provides a separate routing table on the same device so multiple tenants or virtual networks can have overlapping address spaces. In practice, VRFs are how SD-Access implements Virtual Networks (VNs) for macro-segmentation.

Think of VRFs like separate filing cabinets — the same folder name can exist in different cabinets without conflict.
SVI (Switched Virtual Interface): An SVI is the L3 interface for a VLAN on a switch. When you combine an SVI with ip vrf forwarding <name>, the SVI belongs to that VRF and uses that VRF's routing table. Packets arriving on the VLAN are routed according to the VRF's routes.
Route Distinguisher (RD) and Route Target (RT): RD makes prefixes unique in MP-BGP environments; RT controls import/export of routes between VRFs. RTs are the mechanism used to leak routes selectively (for shared services or global routing tables). In production, RTs are planned to allow only required route leaks (e.g., letting Users reach Shared Services but not IoT).
Overlapping Subnets: Multiple VNs can use identical subnets (like 1.2.3.0/24). VRF separation means two SVIs can each bind the same gateway IP (1.2.3.1) without IP conflict, because the device maintains separate routing/forwarding contexts.
Verification behavior: When you enable ip vrf forwarding on an interface, the interface is bound to the VRF and will appear in show ip vrf and show ip interface brief under its VRF context. show ip route vrf <name> shows the VRF-specific routing table.

Step-by-step configuration

Step 1: Create the VRFs and configure RD/RT

What we are doing: Define three VRFs — A, B, and GLOBAL — with the RD and RT values taken from the reference. These values determine the unique RD and which route-targets are exported/imported for selective route leaking. Proper RT planning is critical in production to control reachability between VNs and the shared/global routing table.

conf t
 ip vrf A
  rd 1:4099
  route-target export 1:4099
  route-target import 1:4099
  route-target import 1:4097
 !
 ip vrf B
  rd 1:4098
  route-target export 1:4100
  route-target import 1:4100
  route-target import 1:4097
 !
 ip vrf GLOBAL
  rd 1:4097
  route-target export 1:4097
  route-target import 1:4097
  route-target export 1:4099
  route-target export 1:4100
end

What just happened: Each ip vrf <name> block creates a distinct VRF instance. rd sets the route distinguisher (RD) which uniquely identifies routes from this VRF in BGP contexts. route-target export and route-target import control which route-target extended communities are attached to exported routes and which imported RTs this VRF accepts, enabling selective route sharing. Specifically:

VRF A exports RT 1:4099 and imports 1:4099 and 1:4097 (so it accepts routes from itself and from GLOBAL).
VRF B exports RT 1:4100 and imports 1:4100 and 1:4097 (accepts from itself and GLOBAL).
GLOBAL exports 1:4097 and also exports 1:4099 and 1:4100 so it makes selected routes available to A and B as planned.

Real-world note: Route-target planning should be done as part of a VPN/VRF design exercise; careless RT settings can unintentionally leak tenant routes.

Verify:

show ip vrf

Expected output:

Name                             Default RD            Interfaces
A                                1:4099
B                                1:4098
GLOBAL                           1:4097

VRF A:
  RD 1:4099; VPN ID not set
  Import: 1:4099, 1:4097
  Export: 1:4099
VRF B:
  RD 1:4098; VPN ID not set
  Import: 1:4100, 1:4097
  Export: 1:4100
VRF GLOBAL:
  RD 1:4097; VPN ID not set
  Import: 1:4097
  Export: 1:4097, 1:4099, 1:4100

Step 2: Create VLANs for the Virtual Networks

What we are doing: Create the VLANs that will carry the VN traffic (VLAN 10 for VN A, VLAN 20 for VN B). VLAN objects are required before creating SVIs.

conf t
 vlan 10
  name VN_A
 !
 vlan 20
  name VN_B
 !
end

What just happened: The vlan commands create Layer-2 VLANs on the switch. These VLANs provide the broadcast domains where endpoints for each VN will reside. Creating VLANs is necessary before bringing up SVIs.

Real-world note: In data center or campus fabric designs, VLAN IDs are carefully chosen to align with site VLAN pools and automation workflows.

Verify:

show vlan id 10

Expected output:

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
10   VN_A                             active

show vlan id 20

Expected output:

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
20   VN_B                             active

Step 3: Create SVIs and bind them to VRFs using the same gateway IP

What we are doing: Create SVI interfaces for VLAN10 and VLAN20, place each SVI into its VRF context using ip vrf forwarding, and assign the IP 1.2.3.1/24 to both SVIs (demonstrates overlapping addresses across separate VRFs).

conf t
 interface Vlan10
  description VN_A_SVI
  ip vrf forwarding A
  ip address 1.2.3.1 255.255.255.0
 !
 interface Vlan20
  description VN_B_SVI
  ip vrf forwarding B
  ip address 1.2.3.1 255.255.255.0
 !
end

What just happened: interface Vlan10 and interface Vlan20 create logical Layer-3 SVIs. The ip vrf forwarding <name> command binds the SVI to that VRF so the SVI uses the VRF's routing table. Assigning the same IP 1.2.3.1/24 to both SVIs is permitted because each SVI exists in a different VRF routing context; the device maintains separate forwarding tables for each VRF.

At the protocol level, each VRF will own its ARP table for that SVI, and ARP requests/replies on VLAN 10 will not be visible to VLAN 20.

Real-world note: Overlapping IP addresses are frequently used when micro-segmentation or multi-tenant services share physical infrastructure but must remain logically isolated.

Verify:

show ip interface brief

Expected output (indicating VRF assignment in the device will reflect separate contexts):

Interface              IP-Address      OK? Method Status                Protocol
Vlan10                 1.2.3.1         YES manual up                    up
Vlan20                 1.2.3.1         YES manual up                    up

show ip route vrf A

Expected output:

Routing Table: A
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
C    1.2.3.0/24 is directly connected, Vlan10

show ip route vrf B

Expected output:

Routing Table: B
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
C    1.2.3.0/24 is directly connected, Vlan20

Step 4: Confirm RT-based import/export behavior (logical verification)

What we are doing: We will confirm that the VRFs' RT import/export settings are as expected. This step verifies the configuration that enables controlled leaking between VRFs through the GLOBAL VRF RTs as defined earlier.

show ip vrf detail

What just happened: show ip vrf detail presents each VRF's RD, route-target import and export lists, and interface attachments. This output confirms the route-targets you configured are in the device configuration and can be used by MP-BGP or other mechanisms to control route advertisements/imports.

Real-world note: The real route leaking across VRFs typically occurs via MP-BGP in border/control-plane nodes. Ensure that BGP or the relevant control-plane is configured to carry RTs when implementing inter-VN connectivity.

Verify:

show ip vrf detail

Expected output (excerpt showing key fields for each VRF):

VRF A:
  RD: 1:4099
  VPN Routing/Forwarding: enabled
  Import RTs: 1:4099, 1:4097
  Export RTs: 1:4099
  Interfaces: Vlan10

VRF B:
  RD: 1:4098
  VPN Routing/Forwarding: enabled
  Import RTs: 1:4100, 1:4097
  Export RTs: 1:4100
  Interfaces: Vlan20

VRF GLOBAL:
  RD: 1:4097
  VPN Routing/Forwarding: enabled
  Import RTs: 1:4097
  Export RTs: 1:4097, 1:4099, 1:4100
  Interfaces: (none)

Verification Checklist

Check 1: VRFs exist and have the correct RD and RTs
- Verify with show ip vrf and show ip vrf detail (expected output includes RD and import/export RTs as shown above).
Check 2: SVIs are up and assigned to correct VRFs with the IP 1.2.3.1/24
- Verify with show ip interface brief and show ip route vrf A / show ip route vrf B.
Check 3: Route-targets configured for intended import/export
- Verify with show ip vrf detail and confirm RT lists include 1:4097, 1:4099, 1:4100 according to the table above.

Common Mistakes

Symptom	Cause	Fix
SVI fails to accept IP or shows unassigned in VRF	`ip vrf forwarding <name>` entered after `ip address` (order matters)	Remove IP, add `ip vrf forwarding <name>`, then re-add `ip address` on interface in that order
Two SVIs with same IP show conflict globally	SVI not bound to VRFs or VRF config missing	Ensure `ip vrf forwarding A/B` is present on each SVI and VRFs are created with correct RD/RT
Routes not visible between VRFs/Shared services	Route-target import/export misconfigured or BGP not carrying RTs	Verify RT values with `show ip vrf detail` and ensure control-plane (MP-BGP) is advertising RTs if route leaking requires it
Endpoints cannot reach SVI gateway	VLAN not created or access ports not in correct VLAN	Verify VLAN exists (`show vlan`) and access ports are assigned to VLAN 10/20 as required

Key Takeaways

VRFs provide isolated routing tables allowing overlapping IP spaces; binding SVIs to VRFs creates per-VN gateways.
Route-targets (RTs) are the mechanism for controlled route leaking — plan RTs carefully to avoid unintended exposure between VNs.
The order of commands matters: assign ip vrf forwarding before applying the ip address on an interface.
In production SD-Access, this pattern enables multiple Virtual Networks to coexist on a single physical fabric while allowing selective connectivity to shared/global services (via GLOBAL VRF and RT planning).

Tip: Always validate VRF import/export behavior in a lab before rolling RT changes into production. Misconfigured RTs can create broad route visibility that breaks tenant isolation.

This completes Lesson 4: Virtual Networks and Segmentation. Next lesson we will integrate MP-BGP and demonstrate how RTs propagate routes between the VRFs in a multi-site fabric.