One overlay, distinct responsibilities
Cisco Catalyst SD-WAN separates orchestration, management, control and data-plane responsibilities. Validator assists initial onboarding and connectivity orchestration; Manager provides centralized management and monitoring; Controller handles control information; WAN Edge forwards traffic. A management session and the path carrying user traffic are therefore different concepts.
Read the published example
Figure 10 in the Cisco design guide shows two WAN Edges at Site 101 and one at Site 102. All three connect to biz-internet and mpls transports. Site 1 contains Manager, two Controllers and Validator. IaaS routers and a SaaS cloud are also illustrated. The Site IDs and System IPs are labels from the reference example, not addresses from a Trustnet customer environment.
Cisco SD-WAN: published example topology
Zoom in to explore the roles and connections in the source figure.
- IPsec · biz-internet
- IPsec · mpls
- Control plane · DTLS / TLS
Select a node to read its role. Drag to pan or use the buttons to zoom.
Cisco's Site 101, Site 102 and Site 1 reference figure. System IP values are preserved from the source. Dashed control connections terminate at the component group; individual controller cables absent from the source are not added.
Dashed control lines are not data paths
Dashed lines distinguish the DTLS/TLS control plane from IPsec data-plane paths. OMP exchanges routes, next hops, keys and policies between Controllers and edges. WAN Edge forwards user packets. The original control lines terminate within the component area rather than at individual Controller ports, so that extra detail has not been invented in the redraw.
Application policy depends on measurements
BFD monitors data-plane tunnel liveness and path characteristics. Loss, latency and jitter measurements are evaluated against SLA classes in application-aware routing. Multiple transports do not imply that every application uses the same path. Actual selection depends on configured policy and measurements; diagram lines alone provide no SLA or switchover-time guarantee.
Establish traffic needs for centers, branches and clouds
Before designing SD-WAN, identify which applications are used at each location and which resources they access. A central application, SaaS service and private cloud workload may need different egress decisions. MPLS, internet and mobile connectivity in the catalog are options to evaluate, rather than a mandatory transport set for every site. Record existing capacity, addressing, security controls and application owners together. The target topology then becomes more than appliance placement: it explains which path each application is expected to use under the relevant conditions, providing a concrete foundation for policy and acceptance decisions.
Read segmentation and security policy together
SD-WAN segmentation helps represent application or organizational needs in separate routing contexts. Defining a segment does not itself prove that communication is appropriately restricted. Evaluate user groups, application destinations, service dependencies and external-access policy together. Establish whether enforcement occurs at an edge or elsewhere in the selected architecture. Acceptance should show required flows working and unwanted inter-segment access denied. The reference drawing has not been populated with segment names assumed to belong to your organization; the actual segmentation model follows project requirements and verified product capabilities.
Plan onboarding, change and rollback
Centralized management supports consistent configuration, but change ownership is still necessary. Check identity and onboarding conditions, transport reachability, target configuration and management visibility when activating a branch. Exercise real user transactions and relevant failures in the first pilot. Then establish rollout order, maintenance windows and rollback conditions. Understand which locations and applications a policy change affects before applying it widely. Operations should know how to return to the previous configuration and which measurements support that decision. This connects the management workflow to the service behavior users depend on.
Assess operations beyond tunnel status
An established tunnel does not demonstrate that a user can complete a transaction. Evaluate application reachability, path quality, policy selection and event records together. Measure behavior during an MPLS or internet failure under the actual configuration and load. Trustnet's catalog describes assessment, design, implementation and operational support as the approach connecting these decisions to acceptance and handover. An operational record should identify the site, application owner and response owner. This links an alarm to the affected workflow and gives support evidence beyond an appliance's status indicator.



