Cisco SD-Access VRF Segmentation: How to Isolate Device Groups Across a Multi-Site SD-WAN Fabric Using VRF and BGP

This guide walks through how to add a fully isolated network segment to an existing Cisco SD-Access fabric connected across multiple sites via Cisco SD-WAN. The working example uses an IP camera system, but the design pattern applies to any scenario where you need to carve out a group of devices and give them their own traffic path, their own routing table, and their own WAN access — completely separated from your main network.

What Is This Design Actually Doing?

At its core, this is a VRF segmentation deployment inside a Cisco SD-Access fabric with SD-WAN as the WAN transport.

A VRF (Virtual Routing and Forwarding) instance is essentially a separate routing table that lives inside your existing router or switch. Devices in one VRF cannot talk to devices in another VRF unless you explicitly allow it. This means you can have multiple completely isolated networks running on the same physical hardware — no extra cables, no extra switches, no separate internet connection.

In a Cisco SD-Access environment, VRFs are called Layer 3 Virtual Networks (L3VNs). The fabric uses VXLAN to carry traffic and LISP for endpoint location. When you add a new VRF to the fabric, you are telling SD-Access: “This group of devices gets its own routing table, its own VLAN, and its own path through the network.”

The SD-WAN layer (Cisco Catalyst SD-WAN, formerly vManage) then extends that isolation all the way to the WAN edge routers at each site, so traffic from your isolated segment never mingles with corporate traffic — not on the LAN, not on the WAN.

This design uses two VRFs working together:

• IOT-LAN — the LAN-facing VRF. This is where your isolated devices live. Catalyst Center automates most of the configuration for this VRF.
• IOT-WAN — the WAN-facing VRF. This holds the point-to-point links between the distribution switch and the SD-WAN edge routers, and runs BGP to exchange routes between the fabric and the SD-WAN overlay. This is configured manually on the distribution switch.

Together they create a complete end-to-end isolated path: device → VLAN → IOT-LAN VRF → IOT-WAN VRF → BGP → SD-WAN router → internet or cloud.

Where Else Can You Use This Design?

The camera network is just one use case. The exact same design pattern applies to:

• IoT device segmentation — badge readers, environmental sensors, smart locks, any device that needs network access but should not be on your corporate LAN
• POS and payment systems — isolate card-processing devices to their own VRF to reduce PCI-DSS scope
• Medical devices — infusion pumps, imaging systems, and other clinical devices that need isolation for HIPAA compliance
• OT and industrial networks — factory floor equipment, PLCs, SCADA systems that need to reach specific controllers but be isolated from IT
• Guest WiFi — give guest traffic its own VRF and its own WAN path so it never touches your internal network
• Third-party vendor access — contractor devices on-site get their own segment with limited, auditable access
• Managed security services — a system managed by a third party gets direct cloud access without touching your environment

The key principle: one physical network, multiple isolated logical networks, each with its own routing table, DHCP scope, and WAN path.

The Environment

This guide assumes:

• Cisco SD-Access fabric managed by Catalyst Center (formerly DNA Center)
• Cisco SD-WAN managed by Catalyst SD-WAN Manager (formerly vManage) with Cisco C8300 series routers at each site
• Multi-site deployment — multiple branch or store locations connected via SD-WAN, all managed centrally
• An existing fabric site with switches already provisioned and managed by Catalyst Center

High-Level Workflow

1. Add the BGP/VPN service template to the SD-WAN edge routers and push the config
2. Reserve the IP pool for the new segment in Catalyst Center
3. Add the new Layer 3 Virtual Networks (VRFs) to the fabric site
4. Attach the VRFs to the fabric zone
5. Create Anycast Gateways for the new VLANs
6. Verify the new VRF and VLAN appeared on the switch
7. Manually configure the IOT-WAN VRF and BGP on the distribution switch
8. Verify routing is working in both VRFs
9. Assign the device-facing port to the new VLAN
10. Final verification

Part 1 — Configure the SD-WAN Edge Routers

This is done in Catalyst SD-WAN Manager. Both edge routers at the site receive the same template changes — only the per-device variable values differ.

Navigate to Configuration → Templates → Device Templates, filter for your site, locate the device template for each router, and choose Edit.

1.1 — Add the Service VPN

Scroll to the Service VPN section, click Add VPN, and select your BGP/VPN service VPN template for the new isolated segment. Move it to Selected VPN Templates and click Next.

1.2 — Attach Sub-Templates

On the Select Sub-Templates step, attach the following to the service VPN:

• Cisco BGP template for the new segment
• Cisco VPN Interface Ethernet for the P2P LAN sub-interface (VLAN 100)
• Cisco VPN Interface Ethernet for the P2P TLOC sub-interface (VLAN 101)

1.3 — Fill in the Per-Device Variables

Click Update. SD-WAN Manager will prompt for per-device variable values. For each router you will need:

• Hostname and System IP
• VLAN 100 LAN IP — the P2P link toward the distribution switch
• VLAN 101 P2P TLOC IP
• BGP AS number — unique per site
• BGP Router ID
• Network prefixes to advertise — the device subnet and the P2P /29s
• BGP neighbor addresses — the distribution switch SVIs for VLAN 100 and 101
• Loopback IP

1.4 — Push the Configuration

Click Next to preview the diff, confirm, and click Configure Devices to push. Repeat for the second router.

1.5 — Verify Routes on the Router

After the push completes, SSH into each WAN router and verify the new service VRF has routes from the rest of the SD-WAN fabric:

show ip route vrf 2

You should see a default route learned via OMP from the SD-WAN system interface, and per-site P2P /29 prefixes from other locations in the fabric. If the table is empty, the template push did not apply cleanly — re-check the sub-template attachment and re-push before continuing.

Part 2 — Reserve the IP Pool in Catalyst Center

Navigate to Design → Network Settings → IP Address Pools. Browse to your fabric site, click Reserve, and fill in the pool details:

• Pool Name: Descriptive name tied to the site and segment purpose (e.g. SITE-IOT-670)
• Type: Generic
• IP Address Space: IPv4
• Global Pool: Your parent supernet
• Prefix Length: /25 — 128 addresses, right-sized for a device segment
• IPv4 Subnet: The specific subnet for this site and segment
• Gateway: Last usable address in the subnet
• DHCP Servers: Your enterprise DHCP server IPs
• DNS Servers: Your DNS server IPs

Click Reserve.

Part 3 — Add the Layer 3 Virtual Networks to the Fabric Site

Navigate to Provision → SD-Access → Fabric Sites and open your site. Go to the Layer 3 Virtual Networks tab and click Add Existing Layer 3 Virtual Networks. Select both VRFs — IOT-LAN and IOT-WAN — and click Add. Then click Deploy / Save Intent.

This tells SD-Access that these VRFs are now part of this fabric site and should be considered when making forwarding decisions.

Part 4 — Attach VRFs to the Fabric Zone

Stay in the Layer 3 Virtual Networks tab. Select both VRFs using the checkboxes, click More Actions → Edit Fabric Zone Associations, and add your site’s fabric zone to both VRFs. Click Save / Deploy Intent.

The fabric zone association ties the VRF to the physical fabric infrastructure at this specific site location. Without this step, the VRF exists in the system but is not bound to any physical deployment.

Part 5 — Create the Anycast Gateways

Open the Anycast Gateways tab on the fabric site. Click Create Anycast Gateways and select both VRFs. For the IOT-LAN VRF, configure:

• IP Address Pool: The pool reserved in Part 2
• VLAN Name: Descriptive name tied to site and purpose
• VLAN ID: Your assigned VLAN for this segment
• Traffic Type: Data
• Auto generate VLAN name: Unchecked

Add the Anycast Gateway to your fabric zone, then click Deploy.

The Anycast Gateway is how SD-Access provides a distributed default gateway — every switch in the fabric acts as the gateway for the VLAN, so devices always talk to the closest switch rather than a centralized router. This eliminates the traditional default gateway bottleneck and is one of the key architectural advantages of SD-Access over traditional campus designs.

Part 6 — Verify the New VRF and VLAN Appeared on the Switch

After a successful Catalyst Center deploy, SSH to your distribution switch and confirm the configuration was pushed correctly:

show run vrf IOT-LAN
show ip arp vrf IOT-LAN
show ip route vrf IOT-LAN

You should see:

• The VLAN created with your descriptive name
• The SVI with the correct IP, VRF forwarding, DHCP helper addresses, and LISP mobility binding
• The VRF definition with the correct route-distinguisher and route-target values
• BGP advertising the subnet into the fabric

At this stage show ip route vrf IOT-LAN will only show the local connected route. Remote routes will not appear yet — that is expected. They arrive after Part 7.

Part 7 — Configure the IOT-WAN VRF and BGP on the Distribution Switch

This is the most hands-on part of the deployment. While SD-Access automates the IOT-LAN VRF, the IOT-WAN VRF must be configured manually via CLI on the distribution switch.

This VRF is the bridge between the SD-Access fabric and the SD-WAN overlay. It holds the point-to-point links to the WAN routers, runs BGP to exchange routes, and uses a border loopback as the gateway address for the segment as seen from the WAN side.

SSH to the MDF distribution switch and apply the following, substituting your site-specific values:

vrf definition IOT-WAN
 rd 65000:200
 !
 address-family ipv4
  route-target export 65000:200
  route-target import 65000:200
 exit-address-family
!
interface Vlan100
 vrf forwarding IOT-WAN
 ip address [SWITCH-VLAN100-IP] 255.255.255.248
 no ip redirects
 no ip proxy-arp
 ip policy route-map EXTRANET_POLICY
!
interface Vlan101
 vrf forwarding IOT-WAN
 ip address [SWITCH-VLAN101-IP] 255.255.255.248
 no ip redirects
 no ip proxy-arp
 ip policy route-map EXTRANET_POLICY
!
interface LISP0
!
interface LISP0.100
 vrf forwarding IOT-WAN
 ip policy route-map EXTRANET_POLICY
!
interface Loopback100
 description IOT Border Loopback
 vrf forwarding IOT-WAN
 ip address [SEGMENT-GATEWAY-IP] 255.255.255.255
!
router bgp [SITE-AS]
 !
 address-family ipv4 vrf IOT-WAN
  bgp aggregate-timer 0
  network [P2P-LAN-SUBNET] mask 255.255.255.248
  network [P2P-TLOC-SUBNET] mask 255.255.255.248
  network [SEGMENT-SUBNET] mask 255.255.255.128
  network [SEGMENT-GATEWAY-IP] mask 255.255.255.255
  aggregate-address [SEGMENT-SUBNET] 255.255.255.128 summary-only
  redistribute lisp metric 10 route-map LISP_REDISTRIBUTE
  neighbor IOT-SDW peer-group
  neighbor IOT-SDW remote-as [SITE-AS]
  neighbor [R1-VLAN100-IP] peer-group IOT-SDW
  neighbor [R1-VLAN100-IP] activate
  neighbor [R2-VLAN100-IP] peer-group IOT-SDW
  neighbor [R2-VLAN100-IP] activate
 exit-address-family
!
end
write memory

7.1 — Create the P2P VLANs

vlan 100
 name IOT-P2P-LAN
vlan 101
 name IOT-P2P-TLOC
end
write memory

7.2 — Create the DHCP Pool

If handling DHCP locally on the switch rather than relaying to an external server:

ip dhcp pool IOT-SEGMENT
 vrf IOT-LAN
 network [SEGMENT-SUBNET] 255.255.255.128
 default-router [SEGMENT-GATEWAY-IP]
 dns-server 8.8.8.8 4.2.2.2
!
end
write memory

Important: SD-Access pushes from Catalyst Center do not automatically save manual CLI changes. Always run write memory after each block of manual config.

Part 8 — Verify IOT-WAN Routing and BGP

Run the following on the distribution switch:

show run vrf IOT-WAN
show ip arp vrf IOT-WAN
show ip route vrf IOT-WAN
show ip route vrf IOT-LAN

For show ip route vrf IOT-WAN, after BGP comes up with both WAN routers you should see:

• A default route via the WAN router — shown as B*
• Per-site P2P /29 prefixes from all other fabric locations — shown as B
• Route count should roughly match what you saw in show ip route vrf 2 on the WAN routers in Part 1

For show ip route vrf IOT-LAN, you should now see remote routes in addition to the local connected route — learned via BGP and LISP redistribution.

If BGP is not coming up:

show bgp vrf IOT-WAN summary

Neighbor state should show Established for all peer addresses. If a neighbor is stuck in Active or Idle, verify the IP addresses in your BGP config match the router variables from Part 1, and confirm the VLAN SVIs are up.

Part 9 — Assign the Device-Facing Port

With routing verified, assign the switch port connecting to your isolated device group to the new VLAN through Catalyst Center — this keeps the fabric aware of the port assignment.

Navigate to Provision → Fabric Sites → [Your Site] → Port Assignment. Locate the port, check the box, and click Configure. Set:

• Connected Device Type: User Devices and Endpoints
• VLAN Name (Data): Your new VLAN name
• Authentication Template: None
• Description: Something identifying the connected device

Click Update, then Deploy All.

Part 10 — Final Verification

Once the port is up, the connected device should receive a DHCP address from the new segment pool. Verify on the switch:

show run int [INTERFACE]
show int [INTERFACE] status
show ip arp vrf IOT-LAN

Expected results:

• Interface shows switchport access vlan [ID], status connected
• show ip arp vrf IOT-LAN shows the device MAC and IP address learned on the VLAN SVI
• The device has internet or cloud access through the SD-WAN fabric via the IOT-WAN VRF path
• The device cannot reach anything on corporate VRFs — isolation confirmed

Completion Checklist

• SD-WAN R1 — BGP/VPN service VPN and sub-templates attached and pushed
• SD-WAN R2 — BGP/VPN service VPN and sub-templates attached and pushed
• show ip route vrf 2 on both WAN routers shows OMP default route and per-site /29 prefixes
• IP pool reserved at the fabric site in Catalyst Center
• Layer 3 VNs (IOT-LAN and IOT-WAN) added to fabric site and deployed
• Fabric zone associations updated and deployed
• Anycast Gateway for the device VLAN deployed successfully
• IOT-WAN VRF, P2P SVIs (VLAN 100/101), border Loopback, and BGP configured on the distribution switch
• DHCP pool created
• show ip route vrf IOT-WAN shows BGP-learned default route and per-site prefixes
• show ip route vrf IOT-LAN shows remote routes via BGP/LISP in addition to local connected
• Device-facing port assigned to the new VLAN via Catalyst Center Port Assignment
• Device appears in show ip arp vrf IOT-LAN with correct IP
• write memory completed on the distribution switch

Quick Reference — Per-Site Variables

When deploying this to multiple sites, track your per-site values in a table like this:

Wrapping Up

Adding a fully isolated network segment to an enterprise Cisco SD-Access and SD-WAN environment is a well-defined, repeatable process. Once you have done it once, you have a template you can apply to any device group at any site.

The power of this design is that you are not buying new hardware, not running separate cables, and not managing a separate network. You are using the infrastructure you already have and carving out a logically isolated slice of it — with its own routing table, its own DHCP, its own WAN path, and its own security boundary.

Whether the use case is cameras, IoT sensors, payment terminals, or medical devices, the design is the same. Learn it once, apply it everywhere.

If you have questions or run into something not covered here, drop a comment below.