Cisco Catalyst SD-WAN: Understanding Control and Data Paths

Article

Cisco Catalyst SD-WAN: Understanding Control and Data Paths

Read management components, WAN Edge roles and MPLS/internet transports together in Cisco’s example topology.

Cisco Catalyst SD-WAN
01

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.

02

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 · Figure 10

Cisco SD-WAN: published example topology

Zoom in to explore the roles and connections in the source figure.

Private Cloud · Site 101Control components · Site 1IaaS CloudSite 102DC hostsData-center servers are grouped in one rack in the source.DC switchSwitch connecting the data-center server group to two WAN Edge routers.WAN Edge10.101.0.1First WAN Edge at Site 101; biz-internet and mpls transports match the source.WAN Edge10.101.0.2Second WAN Edge at Site 101; no absent intra-site IPsec tunnel is added.ManagerManagement component shown within Site 1.Controller AOne of the two SD-WAN Controllers shown in the source.Controller BSecond SD-WAN Controller shown in the source.ValidatorOnboarding/orchestration role grouped with control components in the source.Endpoint of the first dashed connection within the source's control-component area.Group endpoint for the second data-center WAN Edge control connection in the source.Group endpoint of the Site 102 control connection in the source.biz-internetPublic internet transport in the source. Grey paths represent its IPsec data plane.mplsPrivate MPLS transport in the source; orange paths depict its data plane.IaaS router AFirst router shown between the IaaS area and internet transport.IaaS router BSecond router in the same IaaS area in the source.WAN Edge10.102.0.1Site 102 WAN Edge. Public and private transport connections are preserved.SwitchSwitch between the Site 102 WAN Edge and endpoint in the source.ClientEndpoint shown within Site 102 in the source.SaaS CloudThe source SaaS cloud includes Office 365, Google, Dropbox and Salesforce, with a direct internet-transport connection.Google Cloud · Microsoft AzureAmazon Web ServicesOffice 365 · Google · Dropbox · SalesforceSource System IPs · Site IDs · biz-internet / mpls transport colors
  • IPsec · biz-internet
  • IPsec · mpls
  • Control plane · DTLS / TLS
Explore the diagram

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.

03

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.

04

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.

05

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.

06

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.

07

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.

08

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.

Technical sources

RELATED CONTENT

View all