SDN Plus Workbook

Introduction

Enterprise networks are undergoing a fundamental transformation. Traditional box-by-box CLI management is giving way to controller-based architectures that deliver automation, segmentation, and centralized policy enforcement at scale. For networking professionals preparing for the CCNP Enterprise certification, mastering both Software-Defined Access (SDA) and Software-Defined WAN (SD-WAN) is no longer optional -- it is the price of admission. The SDN Plus Workbook addresses this head-on by providing 55 structured, hands-on labs that walk you through every phase of building, provisioning, and securing a modern software-defined network.

This article breaks down the full scope of the SDN Plus Workbook, covering its two major tracks -- SDA with 29 labs and SD-WAN with 26 labs. You will learn what each module covers, see real configuration examples drawn directly from the lab exercises, and understand the logical progression from controller integration all the way through route leaking and SDA-to-SD-WAN interconnectivity. Whether you are building your first fabric or connecting a campus to remote branch sites, this guide gives you a clear roadmap for hands-on practice.

If you want to follow along with guided video instruction, explore the CCNP SD-WAN Lab Course and the CCNP SDA Fabric Lab Course on NHPREP for a companion learning experience.

What Does the SDN Plus Workbook Cover?

The SDN Plus Workbook is organized into two major domains, each subdivided into focused modules. The SDA track spans four modules totaling 29 labs, while the SD-WAN track spans four modules totaling 26 labs. Here is a high-level overview:

Domain	Module	Labs	Focus Area
SDA	Module 1	Labs 1-11	DNAC-ISE Integration & LAN Automation
SDA	Module 2	Labs 12-18	Fabric Provisioning
SDA	Module 3	Labs 19-23	ISE Configuration & Macro Segmentation
SDA	Module 4	Labs 24-29	Micro Segmentation & L2 Handoff
SD-WAN	Module 1	Labs 1-8	Underlay Network & Controller Onboarding
SD-WAN	Module 2	Labs 9-14	WAN Edge Onboarding
SD-WAN	Module 3	Labs 15-23	Configuring WAN Edges Using Templates
SD-WAN	Module 4	Labs 24-26	Route Leaking & SDA Interconnectivity

The progression is deliberate. You start by integrating controllers and identity services, build out the underlay and overlay, provision fabric nodes, apply segmentation policies, and then tie the campus fabric to remote SD-WAN branches. By the final lab, your SDA campus and SD-WAN branch sites share routes and communicate end-to-end through a fusion router.

How Does the SDN Plus Workbook Handle DNAC-ISE Integration?

The SDA journey begins with controller integration. Before you can automate device discovery or deploy a fabric, your DNA Center (DNAC) must communicate securely with Identity Services Engine (ISE). Module 1 of the SDA track dedicates its opening lab to establishing this integration through three ISE services: RADIUS, ERS, and pxGrid.

Enabling ISE Services

On the ISE side, you navigate to Administration -> System -> Settings -> Protocols -> RADIUS and uncheck the options to reject repeated failures and suppress repeated clients. This ensures that DNAC discovery and authentication attempts are not silently dropped during the integration phase.

Next, you enable the External RESTful Services (ERS) API by navigating to Administration -> System -> Settings -> API Settings -> API Service Settings and checking both "ERS (Read/Write)" and "Open API (Read/Write)." This allows DNAC to programmatically create and manage ISE objects like authorization profiles and security groups.

Finally, you enable pxGrid on the ISE deployment node. This is the context-sharing protocol that allows DNAC and ISE to exchange security group tags, endpoint data, and policy information in real time.

Configuring DNAC to Communicate with ISE

On the DNAC side, you navigate to Settings -> System -> Authentication & Policy Servers -> Add -> ISE and provide the ISE server details:

Server IP Address: 10.10.101.239
Shared Secret: Lab@123
Username: admin
Password: Lab@123
FQDN: dnac-ise.lab.nhprep.com

After saving, you accept the certificate and verify that the ISE server status shows "Active" on DNAC. On the ISE side, you confirm integration by navigating to pxGrid Services -> Diagnostics and checking for a connected pxGrid client at the DNAC IP address (10.10.101.250).

The final step is migrating policy data from ISE into DNAC by navigating to Policy -> Group-based Access Control and clicking "Start Migration." This synchronizes existing security groups and access contracts between the two platforms.

Pro Tip: Always verify pxGrid connectivity from both sides -- DNAC and ISE -- before proceeding to fabric provisioning. A broken pxGrid connection will cause silent policy synchronization failures that are difficult to troubleshoot later.

How Do You Build the Underlay for Software-Defined Access?

Before DNAC can automate fabric deployment, you need a functional underlay. The SDN Plus Workbook walks through configuring the border switch and fusion router, building the network hierarchy, and running LAN automation to discover and onboard fabric switches.

Border Switch and Fusion Router Configuration

The border switch (9300CB) requires basic connectivity toward the fusion router. The lab configures a trunk port on GigabitEthernet 1/0/1, creates VLAN 199 for the transit link, and assigns an IP address on the SVI:

hostname 9300CB
!
Interface Gig 1/0/1
 switchport mode trunk
!
vlan 199
!
ip routing
!
interface VLAN 199
 ip address 192.168.100.2 255.255.255.0
 no shut
!
ip route 0.0.0.0 0.0.0.0 192.168.100.1

SSH credentials and SNMP communities are also configured on the border switch, as DNAC uses these for device discovery:

username admin privilege 15 secret Lab@123
!
line vty 0 4
 login local
!
snmp-server community public RO
snmp-server community private RW

The fusion router mirrors this setup on the other end of the trunk, with its VLAN 199 SVI at 192.168.100.1:

hostname Fusion
!
Interface Gig 1/0/10
 switchport trunk encapsulation dot1q
 switchport mode trunk
!
vlan 199
!
ip routing
!
interface VLAN 199
 ip address 192.168.100.1 255.255.255.0
 no shut

Network Hierarchy and Design Settings

With physical connectivity in place, you build the DNAC network hierarchy. The lab creates an area called "Los Angeles" under Global, then adds a building called "HQ" under Los Angeles. This hierarchy is critical because DNAC uses it to scope IP pools, credentials, and device assignments.

Server configuration follows, where you define the infrastructure services that fabric devices will use:

Service	Address
AAA (ISE)	10.10.101.239
DHCP	10.10.101.230
NTP	10.10.101.230
DNS	10.10.101.230
Domain	lab.nhprep.com

Device credentials are configured under Design -> Network Settings -> Device Credentials with a CLI credential set named "FabricAdmin" using the admin username and Lab@123 as the password, along with SNMPv2c read ("public") and write ("private") communities.

IP Address Pools

The workbook defines two global-level IP pools that serve as parent pools for all site-level reservations:

Pool Name	Subnet	Prefix	Purpose
LA-DATA-POOL	172.16.0.0	/16	Overlay data traffic
LA-CONTROL-POOL	172.20.0.0	/16	Underlay and control plane

These global pools are later subdivided into site-specific reservations for individual departments and infrastructure functions.

LAN Automation

LAN automation is the mechanism by which DNAC automatically discovers, onboards, and configures fabric switches. The process begins with discovering the border switch at 192.168.100.2 using the previously defined CLI and SNMP credentials. Once discovered, the border switch is assigned to the HQ building under Provision -> Network Devices -> Inventory.

Before initiating LAN automation, you reserve a pool called "LA-LAN-AUTOMATION" from the LA-CONTROL-POOL with a /24 prefix at 172.20.0.0. The fusion router also needs a static route pointing the LAN automation pool toward the border switch:

ip route 172.20.0.0 255.255.0.0 192.168.100.2

LAN automation is then initiated from Provision -> Inventory -> Action -> Provision -> LAN Automation with the border switch (9300CB) as the primary device, using ports GigabitEthernet 1/0/2 and 1/0/3 for discovery. The IS-IS domain password is set to Lab@123, and multicast is enabled. Once the discovered switches reach "Completed" status, you stop LAN automation and verify that all devices show as "Managed" in the inventory.

What Is Fabric Provisioning in the SDN Plus Workbook?

Module 2 of the SDA track transitions from underlay automation to overlay fabric deployment. This is where you reserve site-specific IP pools, create Virtual Networks (VNs), establish the fabric site and transit network, configure host onboarding, and provision the control plane, border, and edge nodes.

Site-Specific IP Pool Reservations

From the LA-DATA-POOL, you reserve four department-specific pools for the HQ site:

Pool Name	Subnet	Default Gateway	Purpose
IT-DATA-1-POOL	172.16.1.0/24	172.16.1.254	IT Department Pool 1
IT-DATA-2-POOL	172.16.2.0/24	172.16.2.254	IT Department Pool 2
SALES-DATA-1-POOL	172.16.3.0/24	172.16.3.254	Sales Department Pool 1
SALES-DATA-2-POOL	172.16.4.0/24	172.16.4.254	Sales Department Pool 2

A FUSION-BORDER-POOL (172.20.1.0/24) is also reserved from the LA-CONTROL-POOL for L3 handoff between the border switch and the fusion router.

Virtual Networks and Fabric Site

Two Virtual Networks are created for departmental segmentation: IT_VN and SALES_VN. These VNs provide macro-level segmentation -- devices in IT_VN cannot communicate with devices in SALES_VN by default, even if they share the same physical infrastructure.

The fabric site is created at Global -> Los Angeles -> HQ using "Close Authentication" as the authentication template. A transit network named "L3HANDOFF" is configured as an IP-based transit using BGP with AS number 65001 (the fusion router's AS).

Provisioning the Border and Edge Nodes

The border switch (9300CB) is provisioned as both the Control Plane Node (using LISP/BGP) and the Border Node with L3 handoff. The border configuration includes:

Local AS: 65002
Default to all virtual networks: Checked
Transit Site: Fusion
External Interface: GigabitEthernet 1/0/1
VN-to-VLAN Mapping: INFRA_VN = VLAN 3001, IT_VN = VLAN 3002, SALES_VN = VLAN 3003
IP Pool: FUSION-BORDER-POOL

The edge nodes (HQ-1 and HQ-2) are provisioned by simply enabling the "Edge Node" slider on each switch under the Fabric Infrastructure tab.

Fusion Router VRF and BGP Configuration

The fusion router requires VRF definitions and BGP peering to match the border node's L3 handoff configuration:

vrf definition IT_VN
 rd 1:4099
 address-family ipv4
  route-target export 1:4099
  route-target import 1:4099
 exit-address-family
!
vrf definition SALES_VN
 rd 1:4100
 address-family ipv4
  route-target export 1:4100
  route-target import 1:4100
 exit-address-family

VLAN SVIs are created for each VN handoff, and BGP sessions are established per VRF:

interface Vlan3001
 ip address 172.20.1.2 255.255.255.252
 no shut
!
interface Vlan3002
 vrf forwarding IT_VN
 ip address 172.20.1.6 255.255.255.252
 no shut
!
interface Vlan3003
 vrf forwarding SALES_VN
 ip address 172.20.1.10 255.255.255.252
 no shut
!
router bgp 65001
 neighbor 172.20.1.1 remote-as 65002
 neighbor 172.20.1.1 update-source Vlan3001
 address-family ipv4
  neighbor 172.20.1.1 activate
  neighbor 172.20.1.1 default-originate
  network 10.10.101.0 mask 255.255.255.0
 address-family ipv4 vrf IT_VN
  neighbor 172.20.1.5 remote-as 65002
  neighbor 172.20.1.5 update-source Vlan3002
  neighbor 172.20.1.5 activate
  neighbor 172.20.1.5 default-originate
  network 10.10.101.0 mask 255.255.255.0
 address-family ipv4 vrf SALES_VN
  neighbor 172.20.1.9 remote-as 65002
  neighbor 172.20.1.9 update-source Vlan3003
  neighbor 172.20.1.9 activate
  neighbor 172.20.1.9 default-originate
  network 10.10.101.0 mask 255.255.255.0

Route leaking between the global routing table and VRFs is configured using prefix lists and route maps to ensure that shared infrastructure services (like DHCP and DNS on the 10.10.101.0/24 network) are reachable from within each VN.

How Does the SDN Plus Workbook Implement Segmentation?

Segmentation is the core value proposition of SDA, and the workbook dedicates two full modules to it: Module 3 for macro segmentation and Module 4 for micro segmentation.

Macro Segmentation with Virtual Networks

Macro segmentation is achieved through Virtual Networks. Users in IT_VN and SALES_VN are isolated by default -- they exist in separate VRFs on the fabric infrastructure. The workbook demonstrates this by configuring ISE with user identity groups (IT-DATA-1, IT-DATA-2, SALES-DATA-1, SALES-DATA-2) and corresponding users, each assigned Lab@123 as their password.

Authorization profiles are created on ISE to map each user group to the appropriate VLAN name, and authorization policies use Wired_802.1x as the authentication method. When a user authenticates through dot1x, ISE assigns them to the correct VLAN (and therefore the correct VN), achieving macro segmentation:

Policy Name	Identity Group	Auth Method	Profile	VN
IT-DATA-1-POLICY	IT-DATA-1	Wired_802.1x	IT-DATA-1-PROF	IT_VN
IT-DATA-2-POLICY	IT-DATA-2	Wired_802.1x	IT-DATA-2-PROF	IT_VN
SALES-DATA-1-POLICY	SALES-DATA-1	Wired_802.1x	SALES-DATA-1-PROF	SALES_VN
SALES-DATA-2-POLICY	SALES-DATA-2	Wired_802.1x	SALES-DATA-2-PROF	SALES_VN

Verification involves logging into workstations with IT credentials and confirming that two IT users can ping each other. When one workstation changes its credentials to SALES1, it moves to SALES_VN and can no longer communicate with IT_VN users. This demonstrates macro segmentation in action.

Micro Segmentation with Security Group Tags

Micro segmentation goes further by applying policy within a single VN. The workbook creates Security Group Tags (SGTs) on DNAC:

IT_DATA_1: SGT 6001, mapped to IT_VN
IT_DATA_2: SGT 6002, mapped to IT_VN

These SGTs are automatically propagated from DNAC to ISE through the pxGrid integration established in Lab 1. Authorization policies are then updated on ISE to assign SGTs alongside the existing authorization profiles.

The workbook demonstrates three micro segmentation scenarios:

Deny IP Contract: A built-in "Deny IP" contract is applied between IT_DATA_1 and IT_DATA_2 in the DNAC policy matrix. Users in both groups exist within IT_VN but cannot communicate. You verify this using show cts role-based permissions on the egress switch.
Custom SG-ACL Contract: The deny contract is removed, and a custom access contract named "IT_DATA_2_TO_IT_DATA_1" is created with specific rules:
- Permit TCP port 80
- Permit TCP port 443
- Permit CIFS
- Default Action: Deny
Verification: After applying the custom contract, you verify that only HTTP, HTTPS, and CIFS traffic passes between the two security groups while all other traffic (including ICMP ping) is blocked.

Pro Tip: When troubleshooting micro segmentation, always check the egress switch -- that is where SG-ACLs are enforced. Use show authentication sessions interface Gig1/0/10 details to confirm the SGT assignment and show cts role-based permissions to verify the downloaded policy.

L2 Handoff

The final SDA lab configures L2 handoff, which extends a fabric VLAN to a non-fabric device. L2 flooding is enabled on the IT-DATA-1 pool in IT_VN, the border switch is set to VTP transparent mode, and a Layer-2 handoff is configured on GigabitEthernet 1/0/1 for IT_VN with an external VLAN of 555.

On the fusion router, VLAN 555 is created with an SVI at 172.16.1.55/24:

vlan 555
!
interface vlan 555
 ip add 172.16.1.55 255.255.255.0
 no shut

This allows non-fabric devices connected to the fusion router to communicate directly with fabric endpoints in the IT-DATA-1 pool at Layer 2.

How Does the SDN Plus Workbook Approach SD-WAN Controller Setup?

The SD-WAN track begins with the underlay network and controller onboarding. This involves configuring non-SD-WAN routers (HQ, MPLS CE, Internet Edge, and branch routers), installing an enterprise certificate server, and initializing the three SD-WAN controllers: vManage, vSmart, and vBond.

Non-SD-WAN Router Configuration

The underlay consists of an HQ router running OSPF across three interfaces, an MPLS CE router with BGP peering to the service provider (AS 111) and mutual redistribution with OSPF, an Internet edge router with BGP peering to the ISP (AS 222), and four branch routers (BR-1-1, BR-2-1, BR-3-1, BR-3-2) each running OSPF on their loopback and LAN interfaces.

The HQ router configuration illustrates the pattern used throughout:

hostname HQ
!
Interface E0/0
 ip address 172.16.100.1 255.255.255.0
 no shut
!
Interface E0/1
 ip address 10.10.101.150 255.255.255.0
 no shut
!
Interface Loopback1
 ip address 172.16.101.1 255.255.255.0
 ip ospf network point-to-point
!
router ospf 1
 network 172.16.100.0 0.0.0.255 area 0
 network 172.16.101.0 0.0.0.255 area 0
 network 10.10.101.0 0.0.0.255 area 0

Controller Initialization via CLI

Each SD-WAN controller is initialized with system parameters via CLI before being configured through the GUI. The vManage initialization demonstrates the pattern:

config
!
system
 host-name vManage1
 system-ip 10.1.1.101
 site-id 100
 organization-name NHPREP
 clock timezone Asia/Muscat
 vbond 199.1.1.3
!
commit

VPN 0 (the transport VPN) is configured with the management interface, a tunnel interface, and allowed services:

config
!
vpn 0
  interface eth0
  ip address 199.1.1.1/28
  tunnel-interface
   allow-service netconf
   allow-service sshd
   no shut
 ip route 0.0.0.0/0 199.1.1.14
!
commit

The vSmart controller follows the same pattern with system-ip 10.1.1.102 and interface address 199.1.1.2/28, while vBond uses system-ip 10.1.1.103 and 199.1.1.3/28 with the local keyword appended to the vbond command to identify it as the local orchestrator.

Controller	System IP	Interface IP	Site ID
vManage1	10.1.1.101	199.1.1.1/28	100
vSmart1	10.1.1.102	199.1.1.2/28	100
vBond1	10.1.1.103	199.1.1.3/28	100

Certificate Management via GUI

After CLI initialization, the controllers are configured through the vManage GUI. Enterprise root certificate authorization is configured by downloading the root certificate from the CA server at http://199.1.1.5/certsrv, then pasting it into vManage under Administration -> Settings -> Controller Certificate Authorization. CSR parameters include a domain of lab.nhprep.com, a validity of 3 years, and organizational details.

For each controller, you generate a CSR, submit it to the enterprise CA, issue the pending certificate, download the Base64-encoded certificate, and install it back on vManage. This process is repeated for vBond and vSmart after they are added to vManage under Configuration -> Devices -> Controllers.

What Does WAN Edge Onboarding Look Like in the SDN Plus Workbook?

Module 2 of the SD-WAN track covers onboarding three different WAN edge platforms: Catalyst 8000v, CSR 1000v, and vEdge Cloud. Each platform requires CLI initialization followed by GUI-based certificate installation and activation.

Catalyst 8000v Initialization

The Catalyst 8000v requires switching to controller mode first with controller-mode enable. After reboot, system parameters and tunnel interfaces are configured:

config-transaction
!
hostname HQ-8000v
!
system
 system-ip 10.2.2.200
 site-id 1
 organization-name NHPREP
 vbond 199.1.1.3
 exit
!
clock timezone GST 4
commit

The WAN-facing interface and SD-WAN tunnel are then configured:

interface GigabitEthernet1
 no shutdown
 ip address 192.168.111.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.111.254
!
interface Tunnel1
 no shutdown
 ip unnumbered GigabitEthernet1
 tunnel source GigabitEthernet1
 tunnel mode sdwan
exit
!
sdwan
 interface GigabitEthernet1
  tunnel-interface
   encapsulation ipsec
   color default
   allow-service all
   allow-service sshd
   allow-service netconf
  exit
 exit
commit

Root certificate installation uses TFTP to transfer the certificate file, followed by the platform-specific install command:

copy tftp://199.1.1.5/RootCert.cer flash:
request platform software sdwan root-cert-chain install bootflash:RootCert.cer

Activation uses the chassis number and token from vManage:

request platform software sdwan vedge_cloud activate chassis-number CSR-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX token XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

vEdge Initialization

The vEdge platform uses a different CLI syntax. System configuration uses host-name instead of hostname, and VPN configuration nests the interface under the vpn 0 block:

config
!
system
 host-name BR-2-vEdge
 system-ip 10.2.2.220
 site-id 20
 organization-name NHPREP
 clock timezone Asia/Dubai
 vbond 199.1.1.3
!
commit
!
vpn 0
 interface ge0/1
  ip address 100.1.1.22/30
  tunnel-interface
   encapsulation ipsec
   allow-service netconf
   allow-service sshd
   no shut
 ip route 0.0.0.0/0 100.1.1.21
!
commit

Root certificates on vEdge devices are transferred via SFTP/WinSCP and installed with request root-cert-chain install /home/admin/RootCert.cer. Activation uses request vedge-cloud activate instead of the platform software command.

For a deeper walkthrough of SD-WAN edge onboarding, check out the CCNP SD-WAN Lab Course on NHPREP.

How Are WAN Edges Configured Using Templates in the SDN Plus Workbook?

Module 3 is the most extensive section of the SD-WAN track, spanning Labs 15 through 23. It introduces the template-based configuration model that is central to SD-WAN scalability.

Feature Templates

Feature templates define individual configuration components. The workbook creates templates for three device families: Catalyst 8000v, CSR 1000v, and vEdge Cloud. System templates define device-specific variables (hostname, system IP, site ID, timezone), while VPN templates define transport (VPN 0), management (VPN 512), and service VPNs (VPN 10, 20, 100).

For the HQ site, VPN interface templates specify static IP addresses, tunnel parameters, and allowed services. For example, the GigabitEthernet1 template for HQ configures:

IP Address: 192.168.111.1/24
Tunnel Interface: On
Color: MPLS
Allowed Services: NETCONF, SSH, OSPF

The GigabitEthernet2 template uses:

IP Address: 199.1.1.17/28
Tunnel Interface: On
Color: Biz-Internet
Allowed Services: NETCONF, SSH

OSPF templates are created for both VPN 0 (transport) and VPN 100 (service), with the service VPN redistributing OMP routes into OSPF to advertise SD-WAN learned routes to the local site.

Device Templates

Device templates combine feature templates into a complete device configuration. The HQ device template (C8v-HQ-DEV-TEMP) assembles:

Section	Template
System	C8v-System
VPN 0	C8v-VPN-0-HQ
VPN 0 Interface (G1)	C8v-VPNINT-G1-HQ
VPN 0 Interface (G2)	C8v-VPNINT-G2-HQ
VPN 0 OSPF	C8v-OSPF-VPN0
VPN 512	C8v-VPN-512-HQ
VPN 512 Interface (G4)	C8v-VPNINT-G4-HQ
VPN 100	C8v-VPN-100-HQ
VPN 100 Interface (G3)	C8v-VPNINT-G3-HQ
VPN 100 OSPF	C8v-OSPF-VPN100

When you attach a device to the template, you provide the device-specific variable values: default gateway (199.1.1.30), hostname (HQ-8000v), system IP (10.2.2.200), and site ID (1). After configuration push, you verify the OSPF neighbor relationship with the MPLS router using show ip ospf neighbor.

The BR-1 site uses a CSR 1000v with BGP peering to the MPLS provider (AS 111) instead of OSPF for the transport VPN. The BR-2 site uses a vEdge Cloud with BGP in AS 65002. The BR-3 site uses a Catalyst 8000v with subinterfaces (GigabitEthernet3.10 and GigabitEthernet3.20) for service VPNs 10 and 20, with IP MTU set to 1496 to accommodate SD-WAN overhead.

Pro Tip: When using subinterfaces on Catalyst 8000v for SD-WAN service VPNs, always set the IP MTU to 1496. The 4-byte reduction from the standard 1500 accounts for the 802.1Q VLAN tag encapsulation overhead and prevents fragmentation issues.

How Does Route Leaking Work Between SD-WAN VPNs?

Module 4 of the SD-WAN track addresses one of the most common real-world requirements: enabling communication between endpoints in different service VPNs. By default, SD-WAN service VPNs are isolated -- VPN 10, VPN 20, and VPN 100 do not share routes. The route leaking lab uses centralized policy on vSmart to selectively export routes between VPNs.

Configuring Groups of Interest

The first step is creating prefix lists and VPN lists under Configuration -> Policies -> Custom Options -> Centralized Policy -> Lists:

List Type	Name	Contents
Prefix	VPN-10-Routes	172.16.11.0/24, 172.16.12.0/24, 172.16.31.0/24, 172.16.32.0/24
Prefix	VPN-20-Routes	172.16.21.0/24, 172.16.22.0/24, 172.16.36.0/24
Prefix	VPN-100-Routes	172.16.1.0/24, 172.16.2.0/24, 172.16.3.0/24, 172.16.4.0/24, 172.16.100.0/24
VPN	VPN10	ID: 10
VPN	VPN20	ID: 20
VPN	VPN-10-20	ID: 10, 20
VPN	VPN100	ID: 100
Site	HQ	ID: 1
Site	BR1-BR3	ID: 10, 30
Site	BR2-BR3	ID: 20, 30

Building the Route Leaking Policy

A custom control topology policy named "Route-Leaking" is created with three sequences:

Sequence 1: Match site BR1-BR3 and prefix list VPN-10-Routes, export to VPN-100
Sequence 2: Match site BR2-BR3 and prefix list VPN-20-Routes, export to VPN-100
Sequence 3: Match site HQ and prefix list VPN-100-Routes, export to VPN-10-20

The default action is Accept. This policy is wrapped in a centralized policy named "Main-Central-Policy" and applied inbound to all sites (HQ, BR1, BR2, BR3). When activated, it pushes the policy to the reachable vSmart controller, which then manipulates the OMP route table to leak routes between the specified VPNs.

How Does the SDN Plus Workbook Connect SDA Campus to SD-WAN?

The final lab in the workbook is the crown jewel -- connecting the SDA campus fabric to SD-WAN branch sites through the fusion router. This achieves end-to-end connectivity between fabric endpoints and remote branch users.

The fusion router is configured with OSPF to exchange routes with the SDA fabric and BGP to advertise branch routes into the SDA overlay:

router ospf 1
 network 10.10.101.0 0.0.0.255 area 0
 redistribute static
!
router bgp 65001
 address-family ipv4
  network 172.16.11.0 mask 255.255.255.0
  network 172.16.12.0 mask 255.255.255.0
  network 172.16.21.0 mask 255.255.255.0
  network 172.16.22.0 mask 255.255.255.0
  network 172.16.31.0 mask 255.255.255.0
  network 172.16.32.0 mask 255.255.255.0
  network 172.16.36.0 mask 255.255.255.0
  network 172.16.37.0 mask 255.255.255.0

These branch routes are also advertised into the IT_VN and SALES_VN VRF address families on the fusion router, ensuring that SDA fabric endpoints in both VNs can reach remote branch sites through the SD-WAN overlay.

On the SD-WAN side, an OMP template (C8v-OMP-HQ) is created on vManage to advertise OSPF external routes into OMP. This template is attached to the HQ WAN Edge device template, enabling the HQ WAN edge to redistribute SDA fabric routes into the SD-WAN overlay and advertise them to all branch sites.

The result is full end-to-end connectivity: SDA campus users in IT_VN and SALES_VN can reach branch site users across VPN 10 and VPN 20 through the fusion router and SD-WAN overlay.

Frequently Asked Questions

What prerequisites do I need before starting the SDN Plus Workbook?

You should have a solid understanding of routing protocols (OSPF, BGP), switching (VLANs, trunking, VTP), VRFs, and basic network security concepts. Familiarity with the DNAC and vManage GUIs is helpful but not strictly required, as the workbook walks through every click. A lab environment with DNAC, ISE, vManage/vSmart/vBond controllers, and appropriate WAN edge devices is necessary to follow along with the exercises.

How long does it take to complete all 55 labs in the SDN Plus Workbook?

The 29 SDA labs and 26 SD-WAN labs together represent a substantial time investment. Plan for approximately 40-60 hours of focused lab time, depending on your existing experience level. The SDA track generally takes longer because it involves more GUI-based workflows with DNAC and ISE, while the SD-WAN track moves faster once you understand the template model. It is best to complete each track sequentially, as later labs depend on configurations from earlier ones.

What is the difference between macro segmentation and micro segmentation in SDA?

Macro segmentation separates traffic at the Virtual Network level. Devices in IT_VN cannot communicate with devices in SALES_VN because they exist in separate VRFs. This is a coarse-grained isolation model. Micro segmentation operates within a single VN using Security Group Tags (SGTs) and SG-ACL contracts. For example, two groups of IT users (IT_DATA_1 and IT_DATA_2) can both be in IT_VN but have granular access control policies between them -- such as permitting only HTTP, HTTPS, and CIFS while blocking everything else.

Why does the SDN Plus Workbook use both OSPF and BGP for SD-WAN transport?

The workbook demonstrates both protocols because real-world SD-WAN deployments use different transport types. The HQ site uses OSPF for MPLS transport peering, while branch sites use BGP. This mirrors production environments where the MPLS provider uses different peering protocols than the Internet provider. The workbook also shows how OMP (Overlay Management Protocol) abstracts these differences, allowing routes from any transport to be redistributed into the SD-WAN overlay regardless of the underlying protocol.

How does route leaking work in SD-WAN, and why is it needed?

Route leaking allows endpoints in different service VPNs (such as VPN 10, VPN 20, and VPN 100) to communicate with each other. Without route leaking, each VPN is completely isolated. The vSmart controller enforces centralized control policies that selectively export routes from one VPN into another based on prefix lists and site lists. This is typically needed when branch users in one department need to access shared resources (like printers or servers) hosted in a different VPN at the headquarters site.

Can I use the SDN Plus Workbook for CCIE Enterprise Infrastructure preparation?

Yes. The labs in the SDN Plus Workbook cover SDA and SD-WAN topics that are directly relevant to the CCIE Enterprise Infrastructure lab exam. The workbook goes deeper than what is strictly required for CCNP ENCOR and ENARSI by including advanced topics like micro segmentation with custom SG-ACL contracts, L2 handoff, multi-VPN route leaking, and SDA-to-SD-WAN interconnectivity. These are exactly the types of scenarios you would encounter in a CCIE lab environment.

Conclusion

The SDN Plus Workbook provides a structured, hands-on path through the two most important software-defined networking technologies in the enterprise: SDA and SD-WAN. Starting from controller integration and underlay preparation, progressing through fabric provisioning and template-based WAN edge deployment, and culminating in segmentation policies and cross-domain interconnectivity, the 55 labs cover the full lifecycle of a modern software-defined network.

The key takeaways from this workbook are:

DNAC-ISE integration through RADIUS, ERS, and pxGrid is the foundation for all SDA automation and policy enforcement
LAN automation streamlines device discovery and onboarding, eliminating manual CLI configuration for fabric switches
Macro segmentation with Virtual Networks and micro segmentation with SGTs provide layered access control within the fabric
Template-based configuration in SD-WAN enables scalable, consistent deployment across diverse WAN edge platforms
Centralized policy on vSmart enables route leaking between isolated service VPNs
Fusion router design bridges SDA campus and SD-WAN branches into a unified, end-to-end network

To continue building your skills with guided video instruction, explore the CCNP SD-WAN Lab Course for the SD-WAN track and the CCNP SDA Fabric Lab Course for the SDA track on NHPREP. These courses complement the workbook with detailed explanations, live demonstrations, and additional context that will accelerate your certification preparation.