{"id":2854,"date":"2025-10-08T10:23:10","date_gmt":"2025-10-08T10:23:10","guid":{"rendered":"https:\/\/www.testkings.com\/blog\/?p=2854"},"modified":"2025-10-08T10:23:10","modified_gmt":"2025-10-08T10:23:10","slug":"cisco-sd-wan-series-step-by-step-lab-setup","status":"publish","type":"post","link":"https:\/\/www.testkings.com\/blog\/cisco-sd-wan-series-step-by-step-lab-setup\/","title":{"rendered":"Cisco SD-WAN Series: Step-by-Step Lab Setup"},"content":{"rendered":"

In our previous post, we explored the foundational architecture of Cisco’s SD-WAN solution. That included a deep dive into the four primary control components that define the fabric: vManage, vSmart, vBond, and the vEdge routers. While we originally planned to move directly into the fabric bring-up sequence, we\u2019re taking a purposeful detour. This installment focuses entirely on the lab environment that will underpin the rest of this series.<\/span><\/p>\n

Building and using a lab is more than just a technical requirement\u2014it\u2019s the bridge between theory and practice. It\u2019s where architectural diagrams take shape, and where the features of SD-WAN come to life through packet flows, routing decisions, and device interactions. For this reason, it is critical to understand both the design and the reasoning behind the structure of the lab itself.<\/span><\/p>\n

This lab is crafted to replicate a production-grade SD-WAN deployment with enough variety and complexity to demonstrate real-world behavior. Over the course of this series, the lab will evolve to include policies, traffic engineering, segmentation, and failure scenarios.<\/span><\/p>\n

Let\u2019s begin with a logical overview of the lab.<\/span><\/p>\n

Logical Topology and Site Roles<\/b><\/h3>\n

At its core, the lab is comprised of five distinct sites. Each site has a unique connectivity profile and role within the overall SD-WAN topology.<\/span><\/p>\n

Site 1 serves as the hub or data center. It acts as the aggregation point for traffic between branch sites and legacy infrastructure.<\/span><\/p>\n

Sites 2, 3, and 4 serve as SD-WAN branch sites, each with various LAN and WAN configurations.<\/span><\/p>\n

Site 5 is a legacy MPLS-only site, representing traditional WAN environments that haven\u2019t yet transitioned to SD-WAN.<\/span><\/p>\n

This structure enables us to test scenarios such as hub-and-spoke routing, full mesh overlays, and transitions between legacy and SD-WAN segments.<\/span><\/p>\n

The logical topology diagram shows the interconnectivity of the sites over three types of WAN transports:<\/span><\/p>\n

MPLS<\/span>
\n<\/span> Internet A<\/span>
\n<\/span> Internet B<\/span><\/p>\n

Each WAN segment has its own addressing scheme and emulated behaviors, allowing us to simulate real-life network dynamics such as jitter, packet loss, and latency.<\/span><\/p>\n

The LAN-side address space across all sites is taken from the 10.0.0.0\/8 private range. The addressing follows a structured pattern:<\/span><\/p>\n

The second octet identifies the site number.<\/span>
\n<\/span> The third octet identifies the VPN number (a concept analogous to a VRF).<\/span><\/p>\n

For example:<\/span>
\n<\/span> VPN 1 at site 1: 10.1.1.0\/24<\/span>
\n<\/span> VPN 3 at site 2: 10.2.3.0\/24<\/span><\/p>\n

This addressing strategy simplifies lab design and routing while clearly delineating segments of traffic as the environment scales.<\/span><\/p>\n

WAN Transport Addressing<\/b><\/h3>\n

The WAN side is where the SD-WAN overlay really comes into play. Each vEdge router connects to at least two WAN transport networks. Here\u2019s how we have structured these:<\/span><\/p>\n

MPLS WAN uses the private address space: 192.168.0.0\/16<\/span>
\n<\/span> Internet A and B use the shared address space: 100.64.0.0\/10 as defined in RFC 6598<\/span><\/p>\n

Each WAN subnet is a \/24, with:<\/span>
\n<\/span> The third octet representing the site number<\/span>
\n<\/span> The fourth octet representing the device number<\/span><\/p>\n

The final IP in each range (.254) is always reserved for the provider device, which is simulated in our lab by a WAN emulation host.<\/span><\/p>\n

Example:<\/span>
\n<\/span> Site 1 MPLS IP: 192.168.1.1\/24<\/span>
\n<\/span> Site 1 MPLS next-hop: 192.168.1.254<\/span>
\n<\/span> Site 1 Internet A IP: 100.64.1.1\/24<\/span>
\n<\/span> Site 1 Internet A next-hop: 100.64.1.254<\/span><\/p>\n

This clean and consistent WAN addressing pattern helps us easily trace paths and troubleshoot issues later in the series.<\/span><\/p>\n

WAN Emulation for Realism<\/b><\/h3>\n

Two dedicated Linux virtual machines are used to emulate our WAN connections:<\/span><\/p>\n

One emulates the MPLS cloud<\/span>
\n<\/span> The other emulates Internet A<\/span><\/p>\n

These machines run open-source WAN emulation software known as WANem. This powerful tool allows us to introduce controlled impairments such as:<\/span><\/p>\n

Latency<\/span>
\n<\/span> Packet loss<\/span>
\n<\/span> Jitter<\/span>
\n<\/span> Bandwidth throttling<\/span><\/p>\n

By tuning these parameters, we can simulate degraded circuits, failover scenarios, and application-performance testing in a realistic way without needing actual physical WAN links.<\/span><\/p>\n

This emulation is critical when evaluating SD-WAN\u2019s performance routing and application-aware routing features.<\/span><\/p>\n

Cloud-Based Controllers<\/b><\/h3>\n

The three core SD-WAN control components\u2014vManage, vBond, and vSmart\u2014are hosted in the cloud. In a real deployment, these may reside in public or private cloud infrastructure. For our lab, these controllers are reachable only via the two internet connections.<\/span><\/p>\n

This mirrors the production recommendation that control plane elements remain reachable via high-availability paths and remain logically separate from data plane activities.<\/span><\/p>\n

The IP reachability from the vEdge devices to the cloud controllers is made possible by NAT through the WANem machines and a home network firewall. These NAT translations ensure that the lab remains isolated from the actual internet while still simulating public connectivity.<\/span><\/p>\n

The NAT boundary is essential for testing the SD-WAN control plane bring-up process, which depends on devices discovering and authenticating with controllers across a WAN.<\/span><\/p>\n

Lab Physical Infrastructure<\/b><\/h2>\n

Physically, the lab runs on a single VMware ESXi 6.0 host. This host carries:<\/span><\/p>\n

Five vEdge Cloud Routers<\/span>
\n<\/span> Four Cisco CSR1000v Routers<\/span>
\n<\/span> Two WANem Linux appliances<\/span><\/p>\n

Each virtual machine is assigned to the appropriate virtual networks (port groups) on ESXi to align with the lab’s logical topology. This separation of port groups is crucial to ensure clean segmentation of LAN, WAN, and management traffic.<\/span><\/p>\n

Management and control of these devices is performed through virtual serial console ports, allowing direct CLI access from a laptop. These connections are established using telnet over the local network. The laptop is configured to reach the ESXi host and connect to serial ports mapped to each VM.<\/span><\/p>\n

This management setup mirrors out-of-band access in a real deployment and provides a reliable way to reach the console for each device\u2014even in the case of configuration errors or boot failures.<\/span><\/p>\n

ESXi Virtual Network Mapping<\/b><\/h3>\n

Each vEdge router in the lab has four network interfaces:<\/span><\/p>\n

ge0\/0 \u2013 LAN<\/span>
\n<\/span> ge0\/1 \u2013 WAN 1 (MPLS or Internet A)<\/span>
\n<\/span> ge0\/2 \u2013 WAN 2 (Internet B)<\/span>
\n<\/span> ge0\/3 \u2013 Management<\/span><\/p>\n

Each interface is mapped to a different ESXi port group. These port groups correspond to isolated virtual switches, keeping traffic logically and physically distinct. For example:<\/span><\/p>\n

LAN traffic stays within the site<\/span>
\n<\/span> WAN traffic traverses the WANem virtual appliances<\/span>
\n<\/span> Management traffic is routed through a NAT boundary to the public network<\/span><\/p>\n

This careful mapping ensures that the behavior of the lab accurately reflects the separation and policy enforcement seen in real SD-WAN environments.<\/span><\/p>\n

Summary and Transition<\/b><\/h3>\n

At this point, we have a fully defined and structured lab environment. The logical and physical design supports a wide range of test scenarios and mimics the challenges and opportunities of real-world SD-WAN deployments.<\/span><\/p>\n

This foundation sets the stage for all future configuration work. By understanding the roles of each site, the WAN layout, and the tools used to simulate impairments and monitor devices, we\u2019re equipped to move on to practical implementation.<\/span><\/p>\n

Deploying the vEdge Cloud Router<\/b><\/h3>\n

With the lab environment fully prepared, it’s time to deploy a virtual edge router and bring it into our SD-WAN fabric. This section focuses on the deployment of a vEdge Cloud router at Site 4, referred to as e4. This site will connect to two WAN transports and serve as a practical example of onboarding a new SD-WAN site.<\/span><\/p>\n

This deployment involves downloading the necessary software, setting up the virtual machine on ESXi, configuring its basic settings, and completing the registration process using the SD-WAN control infrastructure.<\/span><\/p>\n

Preparing the Image and Authorization Files<\/b><\/h3>\n

Before deploying the router, two files are required:<\/span><\/p>\n

The first file is the vEdge Cloud image in OVA format. This is the software package used to create the virtual router on VMware ESXi. The image must match the version of software running on your cloud-based controllers. For this lab, version 17.2.7 is used.<\/span><\/p>\n

The second file is the vEdge authorized device list. This file contains the serial numbers and chassis IDs of the vEdge devices that are allowed to join the overlay. This file must be uploaded into vManage before a new device can be activated.<\/span><\/p>\n

Both files are downloaded from your vendor support portal and stored locally in preparation for deployment.<\/span><\/p>\n

Deploying the vEdge Virtual Machine<\/b><\/h3>\n

Using the vSphere client, the OVA image is deployed on the ESXi host. The deployment wizard walks through the process of selecting the image, naming the virtual machine, choosing the compute resource, storage, and network configuration.<\/span><\/p>\n

The virtual machine will be created with four network interfaces. These interfaces are assigned as follows:<\/span><\/p>\n

The first interface is connected to the LAN segment of Site 4.<\/span><\/p>\n

The second and third interfaces are connected to Internet A and Internet B WAN segments.<\/span><\/p>\n

The fourth interface is reserved for out-of-band management.<\/span><\/p>\n

Each network interface is mapped to a specific ESXi port group that represents a different segment of the network topology. Proper interface assignment is critical to ensure the router connects to the correct parts of the simulated environment.<\/span><\/p>\n

After deployment, a virtual serial port is added to the virtual machine. This allows console access via telnet from the administrator\u2019s laptop. This serial access method is useful for initial configuration and troubleshooting.<\/span><\/p>\n

Uploading the Authorized List to vManage<\/b><\/h3>\n

Before the router can join the fabric, it must be recognized by vManage. This is done by uploading the authorized vEdge list.<\/span><\/p>\n

In vManage, under the configuration section, the device list is accessed. The authorized list file is uploaded and validated. An option is selected to distribute the list to all control nodes, including vBond and vSmart.<\/span><\/p>\n

Once uploaded, the dashboard displays additional entries representing the new vEdge routers included in the list. Each entry includes a chassis number and a one-time password. These are used during the activation phase to securely authenticate the router.<\/span><\/p>\n

Configuring the vEdge for Bootstrap<\/b><\/h3>\n

With the virtual machine running and console access established, the router is configured with its initial settings.<\/span><\/p>\n

The configuration includes the hostname, a unique system IP, site ID, the organization name, and the address of the vBond orchestrator.<\/span><\/p>\n

The WAN interfaces are configured with IP addresses and marked as tunnel interfaces, enabling them to participate in SD-WAN overlay tunnels. Each interface is assigned a color to represent its transport type, such as private1 or private2. These colors are later used to apply policy and routing preferences.<\/span><\/p>\n

A default route is added pointing to the gateway of each WAN segment. This ensures that the router can reach the internet and locate the SD-WAN controllers hosted in the cloud.<\/span><\/p>\n

After applying the configuration, interface status is verified to ensure both WAN links are operational.<\/span><\/p>\n

A simple connectivity test is performed by pinging an external IP address such as a public DNS server. This confirms that the router can reach outside the lab environment, a requirement for controller discovery and registration.<\/span><\/p>\n

Verifying Initial Control Plane Status<\/b><\/h3>\n

Once the configuration is complete, the control connection status is checked using built-in diagnostic commands.<\/span><\/p>\n

At this stage, no active connections are expected. The router does not yet have a valid certificate and has not been activated. The output confirms this by showing no established control plane sessions and an invalid token status.<\/span><\/p>\n

The router is now ready to be activated using the one-time password.<\/span><\/p>\n

Activating the Router<\/b><\/h3>\n

The activation process involves assigning the chassis number and one-time token to the router. These values are taken from the vManage dashboard, where the uploaded authorized list is displayed.<\/span><\/p>\n

Using the router\u2019s command interface, a request is made to activate the device using the provided credentials.<\/span><\/p>\n

After submitting the activation command, the router contacts the vBond orchestrator. If successful, it receives an identity certificate from vManage. This certificate is used to authenticate all future control connections.<\/span><\/p>\n

A follow-up check of the control properties shows a valid certificate is now installed. The token status changes to valid, and timestamps indicate the issue and expiry dates of the certificate.<\/span><\/p>\n

Establishing Control Connections<\/b><\/h3>\n

With the certificate in place, the router attempts to establish connections to vSmart and vManage.<\/span><\/p>\n

A command is issued to list the current control connections. Active sessions are displayed for both WAN transports. The output shows remote IP addresses, system IPs of peer devices, and the type of controller connected.<\/span><\/p>\n

In our example, two sessions are established over private1 and three sessions over private2. These include connections to two vSmart controllers and one vManage node. The router is now fully registered and operational within the SD-WAN fabric.<\/span><\/p>\n

The vManage dashboard also reflects this change. The device now appears as active and trusted, with a valid certificate and active tunnels.<\/span><\/p>\n

Deploying a vEdge Cloud router involves several carefully ordered steps. These include downloading the correct software, deploying the virtual machine, configuring interfaces, uploading the authorization list, activating the router, and confirming connectivity.<\/span><\/p>\n

This process is essential to bring any new site online in an SD-WAN deployment. A secure onboarding procedure ensures that only trusted devices participate in the overlay, and the use of certificates and tokens prevents unauthorized access.<\/span><\/p>\n

With the Site 4 router now deployed and integrated, the lab is ready for further testing and policy implementation.<\/span><\/p>\n

Validating and Troubleshooting Control Plane Connectivity<\/b><\/h2>\n

With our vEdge Cloud router successfully deployed and integrated into the SD-WAN overlay, it is time to turn our attention to validation and troubleshooting. The control plane is the foundation of SD-WAN functionality. Without stable control connections, there is no policy distribution, no route learning, and no secure tunnels. Therefore, ensuring its proper operation is essential before moving forward with any data-plane or policy-related configurations.<\/span><\/p>\n

In this section, we will cover how to verify the control plane status of a vEdge router, interpret common command outputs, and address typical onboarding issues. The goal is to provide a practical guide that can be followed in any SD-WAN deployment, whether in a lab or a production environment.<\/span><\/p>\n

Understanding the Control Plane in SD-WAN<\/b><\/h3>\n

The SD-WAN control plane is responsible for exchanging routing information, managing security credentials, and maintaining state across all edge and core devices. The three control plane components include:<\/span><\/p>\n

vManage, which handles configuration, monitoring, and certificate issuance.<\/span><\/p>\n

vBond, which orchestrates initial communication between devices.<\/span><\/p>\n

vSmart, which distributes routing, policy, and security information across the overlay.<\/span><\/p>\n

When a vEdge device boots and applies its bootstrap configuration, it uses the vbond IP or hostname to discover the rest of the control infrastructure. The device then attempts to establish DTLS or TLS connections with vSmart and vManage. These tunnels are authenticated using certificates, which must be valid and trusted across all components.<\/span><\/p>\n

Confirming Local Control Properties<\/b><\/h3>\n

The first step in validation is to examine the local control properties of the vEdge device. This confirms whether the device is aware of its system information, certificate status, organization affiliation, and vbond configuration.<\/span><\/p>\n

The key values to check include:<\/span><\/p>\n

The system IP and site ID, which should match the configured values.<\/span><\/p>\n

The organization name, which must exactly match the value used on the control components.<\/span><\/p>\n

The vbond IP or hostname, which should be resolvable and reachable.<\/span><\/p>\n

The certificate status, which must be marked as valid and installed.<\/span><\/p>\n

The token status, which should indicate whether the one-time password has been accepted or is no longer required.<\/span><\/p>\n

If the certificate is not installed or the token is still invalid, the vEdge will not proceed to form control connections.<\/span><\/p>\n

Validating Control Connections<\/b><\/h3>\n

The next step is to inspect current control connections. This provides visibility into which controllers the vEdge is connected to, how many sessions are active, and over which interfaces those sessions are formed.<\/span><\/p>\n

A properly functioning vEdge should have multiple control connections, including at least one to each of vSmart and vManage. These connections may occur over multiple WAN transport interfaces for redundancy.<\/span><\/p>\n

Each connection record includes the following:<\/span><\/p>\n

The peer system IP and site ID.<\/span><\/p>\n

The public IP address used to reach the controller.<\/span><\/p>\n

The interface and transport color used for the session.<\/span><\/p>\n

The connection status, such as up, init, or down.<\/span><\/p>\n

The number of retries and uptime for the session.<\/span><\/p>\n

A control connection marked as up with a stable uptime confirms a working session. If the status is stuck in init or remains down, further investigation is needed.<\/span><\/p>\n

Common Causes of Control Plane Failure<\/b><\/h3>\n

When control connections do not come up, the issue often lies in one of a few common areas:<\/span><\/p>\n

The organization name is mismatched between the vEdge and the controller. This must be exact, including spaces and punctuation.<\/span><\/p>\n

DNS resolution of the vbond hostname fails, preventing discovery of vSmart and vManage.<\/span><\/p>\n

Static routes or default routes are missing from the vEdge, preventing reachability to the internet or cloud controllers.<\/span><\/p>\n

The one-time activation token was not applied or was entered incorrectly.<\/span><\/p>\n

The system clock is incorrect, causing certificate validation to fail due to time mismatch.<\/span><\/p>\n

The firewall or NAT device between the vEdge and the internet is blocking required ports such as UDP 12346 for DTLS.<\/span><\/p>\n

By addressing each of these points methodically, most onboarding issues can be resolved quickly.<\/span><\/p>\n

Verifying Time and DNS Settings<\/b><\/h3>\n

Time synchronization and name resolution are often overlooked but are critical to SD-WAN operation.<\/span><\/p>\n

If the vEdge device\u2019s clock is significantly out of sync, certificate validation will fail. Ensure that the device has either a manually set time or a working NTP configuration.<\/span><\/p>\n

Similarly, DNS must be configured correctly, either on the WAN interface or under the VPN 0 configuration. If DNS is not working, the device will be unable to resolve vbond hostnames, preventing connection initiation.<\/span><\/p>\n

Testing DNS with simple name lookups and pinging known external addresses helps confirm basic functionality before diagnosing deeper issues.<\/span><\/p>\n

Checking WAN Interface and Routing Configuration<\/b><\/h3>\n

Control connections occur over interfaces defined under VPN 0. These interfaces must be configured with correct IP addresses, tunnel interfaces enabled, and marked with an appropriate color. The device also requires a reachable gateway, typically defined via a static default route.<\/span><\/p>\n

Inspecting interface status and IP assignments confirms whether traffic can leave the device. Verifying that each WAN transport is up and has a path to the internet is essential before assuming a control failure is due to a configuration problem on the controller side.<\/span><\/p>\n

Adding ICMP tests, traceroute, or monitoring tools can help confirm basic path reachability between the vEdge and cloud controllers.<\/span><\/p>\n

Monitoring the Control Plane from vManage<\/b><\/h3>\n

From the controller side, vManage provides tools to monitor device status and control connection health.<\/span><\/p>\n

After successful activation, the vEdge device appears in the dashboard with its name, system IP, site ID, and uptime. Its control connection status is shown as green if the device is connected and has an active certificate.<\/span><\/p>\n

If the device does not appear or is marked in red, the control connection is likely down or the device is not authenticated.<\/span><\/p>\n

vManage also allows querying real-time status of vEdge devices, reviewing logs, and checking the device inventory. This provides a second layer of verification to confirm whether an issue lies with the edge device or the controller infrastructure.<\/span><\/p>\n

Practical Troubleshooting Scenario<\/b><\/h3>\n

Suppose that after booting the vEdge and applying the bootstrap configuration, the device cannot establish any control connections. Running the control status commands shows no active sessions. The token status remains invalid, and the certificate is not installed.<\/span><\/p>\n

In this case, the likely cause is a missing activation command. Revisiting the authorized device list on vManage confirms that a one-time password is available. Entering the activation request command on the vEdge allows the device to register, receive a certificate, and initiate proper control sessions.<\/span><\/p>\n

If instead the device has a certificate but control connections remain stuck in init, then the issue may lie in transport reachability or NAT traversal. Confirming interface configuration, route paths, and access through firewalls can help resolve the problem.<\/span><\/p>\n

Each scenario requires examining the entire path between the vEdge and the control nodes, including local settings, transport behavior, and controller status.<\/span><\/p>\n

Best Practices<\/b><\/h3>\n

To effectively validate and troubleshoot control plane connectivity, follow these best practices:<\/span><\/p>\n

Always confirm that the organization name matches exactly across all devices.<\/span><\/p>\n

Ensure DNS and NTP are working before attempting activation.<\/span><\/p>\n

Check that WAN interfaces are configured with proper IP addresses and default routes.<\/span><\/p>\n

Apply the one-time activation token before expecting control connections.<\/span><\/p>\n

Verify certificate status and time settings to avoid authentication issues.<\/span><\/p>\n

Use control status commands to monitor the current state and diagnose problems.<\/span><\/p>\n

Confirm from the vManage dashboard that the device is visible and marked as healthy.<\/span><\/p>\n

By following a consistent checklist and verifying each component in order, most control plane issues can be identified and resolved efficiently.<\/span><\/p>\n

With the control plane validated and the vEdge registered and connected, the foundation is now in place to begin more advanced configurations. In the next section, we will introduce the concept of overlay routing and explore how route advertisements are exchanged, controlled, and influenced by policy.<\/span><\/p>\n

Understanding how the control plane enables and regulates the overlay is key to unlocking the full potential of SD-WAN. From route learning and propagation to segmentation and service chaining, everything relies on this control layer.<\/span><\/p>\n

Overlay Routing and Preparing for Advanced SD-WAN Policy<\/b><\/h2>\n

With the vEdge routers registered and control plane connections fully established, we now transition into one of the most critical aspects of any SD-WAN deployment: overlay routing. This phase marks the point where the devices begin to function as part of an integrated wide area network, sharing route information, discovering remote networks, and exchanging traffic securely through encrypted tunnels.<\/span><\/p>\n

This section introduces how overlay routing works in Cisco SD-WAN, the mechanisms behind route distribution, and how the control plane facilitates dynamic and scalable connectivity across the enterprise. We will also lay the groundwork for applying traffic policies in upcoming sessions.<\/span><\/p>\n

Understanding the SD-WAN Overlay<\/b><\/h3>\n

An overlay network is a logical network built on top of an existing physical infrastructure. In the case of Cisco SD-WAN, the overlay is established between vEdge routers using secure tunnels over the underlying WAN transports. These tunnels are built and maintained using control information received from vSmart controllers.<\/span><\/p>\n

The overlay enables any-to-any connectivity between sites, simplifies routing, and provides the basis for applying sophisticated application-aware policies. It abstracts the physical WAN topology, allowing administrators to focus on business intent rather than static path definitions.<\/span><\/p>\n

Each site, identified by a unique system IP and site ID, participates in this fabric. Devices advertise their local routes to vSmart, which then redistributes them to other devices based on configured policies.<\/span><\/p>\n

Role of vSmart in Route Propagation<\/b><\/h3>\n

The vSmart controller is responsible for the route exchange and enforcement of policy across the SD-WAN fabric. When a vEdge router comes online and forms a control connection with vSmart, it advertises all of its local route information. This includes routes from directly connected networks, static routes, and routes learned from local routing protocols like OSPF or BGP.<\/span><\/p>\n

vSmart collects these routes from all sites and redistributes them according to policy. This redistribution is highly scalable and secure, as all route exchanges occur through authenticated control connections.<\/span><\/p>\n

Routes in Cisco SD-WAN are transported using a protocol called Overlay Management Protocol. This protocol is optimized for SD-WAN and includes route attributes that support advanced traffic control features, including service insertion, VPN segmentation, and preferred pathing.<\/span><\/p>\n

VPNs and Segmentation<\/b><\/h3>\n

One of the key architectural elements in Cisco SD-WAN is the use of VPNs to separate and segment traffic. In this context, VPN is similar to a virtual routing and forwarding instance. Each VPN represents a separate routing domain and can be used to segregate user, guest, and management traffic.<\/span><\/p>\n

In our lab, the third octet of the LAN IP address indicates the VPN. For example, at Site 1, 10.1.1.0 is used for VPN 1, and at Site 2, 10.2.3.0 represents VPN 3. This consistent addressing scheme makes it easier to manage segmentation.<\/span><\/p>\n

Each VPN is isolated from the others unless explicitly connected through route leaking or service chaining policies. When a vEdge router advertises its routes to vSmart, it includes the VPN identifier, ensuring that the correct routing domains receive the appropriate updates.<\/span><\/p>\n

This segmentation model enables secure and policy-driven routing between departments, services, or business units.<\/span><\/p>\n

Establishing the Overlay Tunnels<\/b><\/h3>\n

Once routes are exchanged via vSmart, each vEdge router is aware of remote networks across the SD-WAN fabric. At this point, the routers can begin to form direct IPsec tunnels to other sites, depending on the routing information received.<\/span><\/p>\n

These tunnels are formed dynamically, and their endpoints are determined based on reachability and transport preference. Each tunnel is established using pre-shared or certificate-based authentication and encrypts all user traffic flowing between sites.<\/span><\/p>\n

The overlay tunnels provide:<\/span><\/p>\n

Data-plane security through encryption<\/span><\/p>\n

Transport independence across MPLS, broadband, or LTE<\/span><\/p>\n

Fast convergence using centralized control updates<\/span><\/p>\n

Efficient route scaling through centralized policy enforcement<\/span><\/p>\n

These features eliminate the need for traditional mesh topologies built using static GRE or DMVPN configurations and allow the SD-WAN to adapt to network changes in real-time.<\/span><\/p>\n

Observing Overlay Routing in the Lab<\/b><\/h3>\n

In our lab, each vEdge router has advertised its local LAN subnets to vSmart. For example, Site 4 advertises its 10.4.1.0 subnet for VPN 1. vSmart redistributes this route to other sites such as Site 1 and Site 2, where the routers install the route in their own VPN 1 routing tables.<\/span><\/p>\n

This route visibility can be confirmed using built-in show commands to view received and installed routes per VPN. These routes will include next-hop information pointing to the system IP of the advertising router and will be marked as learned via OMP.<\/span><\/p>\n

The overlay tunnel endpoints are also visible. For each peer site, a vEdge device will build a tunnel interface using its WAN IP and establish a secure session to the corresponding IP at the remote site. These tunnels may be formed across different transport types, depending on reachability and preferences.<\/span><\/p>\n

Overlay Routing and Transport Independence<\/b><\/h3>\n

Cisco SD-WAN supports true transport independence. This means that overlay tunnels can be established over any available WAN path, including MPLS, broadband internet, or cellular networks.<\/span><\/p>\n

Each transport is identified by a color attribute. For example, private1 might represent MPLS and private2 could represent internet. These colors are assigned to tunnel interfaces in the configuration and are used by policy engines to make forwarding decisions.<\/span><\/p>\n

When a vEdge router forms overlay tunnels, it does so over each active transport, allowing for multiple parallel tunnels between the same pair of sites. This design allows for:<\/span><\/p>\n

Load balancing<\/span><\/p>\n

Path redundancy<\/span><\/p>\n

Application-aware routing<\/span><\/p>\n

Failover and recovery within seconds<\/span><\/p>\n

In our lab, each vEdge is connected to two WAN transports. As a result, we can observe dual tunnels to each peer, one over private1 and one over private2. This setup allows us to test routing behaviors during link failure, latency shifts, and application performance changes.<\/span><\/p>\n

Planning for Policy Application<\/b><\/h3>\n

Now that routes are visible and tunnels are formed, the foundation is laid for applying policies. Cisco SD-WAN uses a centralized policy model, with the vSmart controller distributing policies to edge devices.<\/span><\/p>\n

Policy categories include:<\/span><\/p>\n

Control policies, which determine how routes are advertised and accepted<\/span><\/p>\n

Data policies, which govern how traffic is forwarded once it arrives on the vEdge<\/span><\/p>\n

Application-aware routing policies, which influence path selection based on application type and transport conditions<\/span><\/p>\n

Security policies, which enforce access control, segmentation, and service chaining<\/span><\/p>\n

To implement a policy, administrators define match and action criteria in vManage, associate the policy with a site or VPN, and push it to the relevant vSmart controllers. Once received, the policy is enforced by the edge routers in near real-time.<\/span><\/p>\n

Our lab is now ready to test these features. With multiple sites, diverse transports, and defined addressing, we have the flexibility to create and validate a wide range of policy scenarios.<\/span><\/p>\n

Verifying Routing Tables and Tunnel Status<\/b><\/h3>\n

Before diving into policy, it’s important to verify that overlay routing is behaving as expected. Each vEdge device should have:<\/span><\/p>\n

Routes to remote LAN subnets in the appropriate VPNs<\/span><\/p>\n

Overlay tunnels established to all relevant peer sites<\/span><\/p>\n

Correct identification of primary and backup transport paths<\/span><\/p>\n

Reachability to all controllers and peers via OMP<\/span><\/p>\n

These elements can be validated through the device command line or the vManage dashboard. Routing tables should list remote subnets with a next-hop pointing to the system IP of the advertising peer. Tunnel statistics should show stable sessions with low latency and error rates.<\/span><\/p>\n

Where multiple tunnels exist between sites, administrators can observe which tunnel is active and whether traffic is flowing as intended. This sets a benchmark for later testing when policies are introduced that may influence tunnel selection or route preferences.<\/span><\/p>\n

Preparation for Policy Testing<\/b><\/h3>\n

Overlay routing is the operational heart of Cisco SD-WAN. It transforms static, complex WAN environments into dynamic, secure, and flexible fabrics. The vSmart controller manages route exchange and tunnel formation, enabling each site to discover and communicate with every other site in a consistent and scalable manner.<\/span><\/p>\n

By understanding how routing and segmentation work in the overlay, we are now ready to move beyond infrastructure and begin implementing intent-based policies. These policies will allow us to prioritize applications, enforce business logic, and steer traffic intelligently across available paths.<\/span><\/p>\n

Final Thoughts<\/b><\/h2>\n

The journey through our SD-WAN lab setup has taken us from foundational architecture to hands-on deployment, validation, and preparation for policy application. By walking through this process step by step, we\u2019ve built not just a technical environment, but a platform for experimentation, learning, and future growth.<\/span><\/p>\n

What began with an introduction to logical site roles and transport types has evolved into a fully functional overlay network. We’ve configured vEdge routers, established control-plane trust, formed dynamic overlay tunnels, and verified that remote routing domains are reachable. Each stage of this lab has been designed to mirror real-world complexity while maintaining clarity for learning and testing.<\/span><\/p>\n

There are a few key reflections that stand out:<\/span><\/p>\n

SD-WAN is far more than just a replacement for traditional WAN. It introduces a centralized and scalable control model that simplifies management while enhancing flexibility, security, and application performance.<\/span><\/p>\n

A well-designed lab environment is not just a convenience\u2014it is essential for mastering the technology. It enables low-risk testing, troubleshooting, and exploration of advanced features before implementing them in production.<\/span><\/p>\n

Understanding the control plane and overlay routing is critical. These are the core mechanisms that make SD-WAN adaptive and secure. Without a strong foundation in these areas, policy application and traffic steering will be guesswork.<\/span><\/p>\n

Transport independence is not a theoretical feature\u2014it is practical and powerful. By simulating multiple WAN paths and introducing emulated network conditions, we\u2019ve demonstrated how SD-WAN maintains performance and availability across dynamic networks.<\/span><\/p>\n

Looking ahead, the next logical step is to implement policies. That\u2019s where SD-WAN truly differentiates itself: offering granular control over how, when, and where traffic flows. Policies allow you to align your network behavior with your business priorities\u2014ensuring critical applications get the performance they need, regardless of underlying transport conditions.<\/span><\/p>\n

As we continue the series, we\u2019ll build on everything covered so far. From crafting control and data policies to applying security frameworks and service chaining, each topic will deepen your understanding of how to turn intent into action within the SD-WAN fabric.<\/span><\/p>\n

Until then, take time to explore your lab, experiment with additional sites or VPNs, and become comfortable interpreting routing behavior and control-plane status. A well-practiced engineer in the lab becomes a confident one in production.<\/span><\/p>\n

May your tunnels remain stable, your policies efficient, and your troubleshooting sharp.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

In our previous post, we explored the foundational architecture of Cisco’s SD-WAN solution. That included a deep dive into the four primary control components that […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-2854","post","type-post","status-publish","format-standard","hentry","category-post"],"_links":{"self":[{"href":"https:\/\/www.testkings.com\/blog\/wp-json\/wp\/v2\/posts\/2854","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.testkings.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.testkings.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.testkings.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.testkings.com\/blog\/wp-json\/wp\/v2\/comments?post=2854"}],"version-history":[{"count":1,"href":"https:\/\/www.testkings.com\/blog\/wp-json\/wp\/v2\/posts\/2854\/revisions"}],"predecessor-version":[{"id":2855,"href":"https:\/\/www.testkings.com\/blog\/wp-json\/wp\/v2\/posts\/2854\/revisions\/2855"}],"wp:attachment":[{"href":"https:\/\/www.testkings.com\/blog\/wp-json\/wp\/v2\/media?parent=2854"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.testkings.com\/blog\/wp-json\/wp\/v2\/categories?post=2854"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.testkings.com\/blog\/wp-json\/wp\/v2\/tags?post=2854"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}