1.0 Problem Summary

A common and critical use case for Cisco SD-WAN is the implementation of a hub-and-spoke topology. In this design, all communication between spoke sites must be routed through a central hub site. This is typically done to enforce centralized security policies, perform traffic inspection, or provide access to shared services located at the hub or data center.

The issue encountered involved a correctly configured centralized control policy in vManage that failed to enforce this traffic pattern. Despite applying a policy intended to restrict direct spoke-to-spoke communication, spoke sites were still able to form direct IPsec data plane tunnels and communicate with each other. Verification via ping and traceroute confirmed that traffic was not transiting the designated hub site.

Initial troubleshooting on the spoke routers using commands such as show omp routes revealed the core symptom: spoke routers were successfully learning the OMP routes (vRoutes) and TLOCs (Transport Locators) of other spoke sites directly. This indicates that the vSmart controller, the policy enforcement point for the control plane, was not filtering these route advertisements as intended by the policy.

2.0 Root Cause Analysis

The root cause of this issue lies in a fundamental misunderstanding of the directionality of control policy application on the vSmart controller. In Cisco SD-WAN, a centralized control policy can be applied in two primary directions relative to the vSmart controller:

1. Inbound Direction (From Service / from-service): The policy is applied to OMP updates as they are received by vSmart from the SD-WAN edge routers (vEdges or cEdges). This allows an administrator to filter, modify, or influence routing information before it is processed by vSmart and entered into its routing database for potential redistribution.

2. Outbound Direction (From Control / from-control): The policy is applied to OMP updates as they are advertised by vSmart to the SD-WAN edge routers. This allows an administrator to filter or modify routing information on a per-site or per-router basis as it leaves the controller.

In the reported problem, the control policy was mistakenly applied in the outbound direction to the site list containing the spoke locations. Let’s analyze why this approach is incorrect for enforcing a hub-and-spoke topology:

When the policy is applied outbound, the vSmart controller has already accepted and processed all OMP updates from all spoke sites. Its database contains the prefixes and TLOCs for every site in the topology. When vSmart sends an OMP update to Spoke-A, the outbound policy is triggered. This policy would correctly filter out routes from Spoke-B and Spoke-C from being advertised to Spoke-A. While this seems correct, it is an inefficient and often incomplete method. The fundamental goal is to prevent vSmart from ever distributing spoke routes to other spokes.

The correct and standard method is to apply the policy in the inbound direction. By applying the policy as OMP updates arrive from the spokes, we instruct vSmart on how to handle that information at the point of ingress. The policy logic effectively tells vSmart: “When you receive routes from a spoke site, accept them, but do not re-advertise them to other spokes. Instead, advertise a route to those prefixes that points to the hub’s TLOC.” This centrally modifies the next-hop attribute for all inter-spoke traffic, forcing it toward the hub. By controlling the information as it enters vSmart, we ensure that the routing information propagated throughout the overlay is already compliant with our desired topology.

3.0 Detailed Implementation and Solution Steps

To correctly implement a hub-and-spoke topology and resolve the issue, the centralized control policy must be reconfigured to be applied in the inbound direction from the spoke sites.

Step 1: Define Required Lists in vManage

Navigate to Configuration > Policies > Centralized Policy > Lists. Ensure you have the following lists defined:

• Site List (Spokes): A list containing the site IDs of all spoke locations.
• Site List (Hubs): A list containing the site ID(s) of the hub location(s).
• TLOC List (Hub): A list containing the TLOCs of the hub router(s). This includes the hub’s system-IP, color, and encapsulation.
• Prefix List (Spoke Prefixes): A list of the prefixes being advertised from the spoke sites that need to be controlled.

Step 2: Construct the Control Policy

Navigate to Configuration > Policies > Centralized Policy and edit or create your topology policy.

1. Go to the Topology tab and select Custom Control (Route & TLOC).
2. Create a new Route Policy. The logic should be as follows:
   • Sequence 1:
     • Match Condition: Match routes originating from the Spoke Site List.
     • Action: Accept the route, but set the TLOC to the Hub TLOC List. This action is the key to redirecting traffic. It changes the next-hop for spoke-learned prefixes to be the hub router.
   • Default Action: Ensure the default action for the policy is Accept. This is crucial to allow hub routes and other necessary control information to be exchanged without being dropped.

Step 3: Apply the Policy to vSmart (The Correct Direction)

This is the critical step that resolves the problem.

1. After defining the policy, go to the Policy Application tab within the centralized policy configuration.
2. Select the Topology section.
3. Click New Site List and VPN List.
4. Find your route policy in the Outbound Site List section. This is the incorrect location from the original problem.
5. Instead, apply the policy under the Inbound Site List section.
   • Route Policy: Select the route policy created in Step 2.
   • Site List: Select the Spoke Site List.
   • Direction: The UI will show this as applying the policy in the inbound direction (or From Service).

Step 4: Activate and Verify the Policy

1. Save and activate the policy. vManage will push the updated configuration to the vSmart controller(s).
2. Allow a few moments for OMP to reconverge.
3. Verification:
   • SSH into a spoke router (e.g., Spoke-A).
   • Execute the command: show omp routes vpn <vpn-id>.
   • Observe the routes for a prefix located at another spoke (e.g., Spoke-B). The TLOC column for that route should now show the System IP and color of the hub router, not Spoke-B’s router. The STATUS should be C,I,R (Chosen, Installed, Resolved).
   • Execute show ip route vpn <vpn-id>. The next hop for the remote spoke prefix should be the IPsec tunnel interface associated with the hub.
   • Execute a traceroute from a host behind Spoke-A to a host behind Spoke-B. The first hop within the overlay should be the hub router’s IP address.

4.0 Conclusion and Best Practices

The directionality of control policy application is a cornerstone of designing and troubleshooting Cisco SD-WAN topologies. For enforcing a hub-and-spoke traffic pattern, the definitive best practice is to apply the control policy in the inbound direction to the vSmart controller from the spoke sites. This approach is efficient, scalable, and ensures that the control plane information distributed across the fabric is accurate from the source, preventing edge routers from ever learning topology information that violates the intended design.