Course contents

Unit 2: Core Cisco componentsLesson 2.5 (5 of 6 in this unit)12 of 27 in the Cisco SD-WAN course

DTLS/TLS secure control connections

Which SD-WAN devices build control connections with which, how DTLS and TLS differ, and how to read show sdwan control connections to find the missing one.

Intermediate · 12 min read

You'll learn to say what a control connection is, which devices build one with which, how DTLS and TLS differ, and read the output of show sdwan control connections to find which connection is missing.

Technical definition

Control connection is a secure, authenticated session between two Cisco SD-WAN devices, carrying control and management information such as OMP routes and configuration. It is encrypted with DTLS (Datagram Transport Layer Security, which runs over UDP) or with TLS (Transport Layer Security, which runs over TCP). User traffic does not use it.

A branch that is up but invisible

BR-01 forwards traffic normally, yet the Manager lists it as unreachable and a template change does not reach it. Another branch on the same transports looks healthy. The difference is in the control connections: BR-01 has the one to the Controller on both transports, but the one to the Manager is missing. This is why the control connection output is the first command in most SD-WAN troubleshooting: it shows, in a few lines, which parts of the control plane a router can actually reach.

Who connects to whom

FromToUsed for
WAN EdgeValidatorFirst contact and introduction; see the Validator lesson
WAN EdgeControllerOMP: routes, TLOCs, services and policy
WAN EdgeManagerConfiguration, monitoring and statistics
Controller, ManagerValidator, and each otherControllers learn about devices and share what they need

Edges do not build control connections to each other. They build IPsec tunnels, which is a separate mechanism. The Validator connection is mainly a start-up step: after that, an edge normally works through its Controller and Manager connections.

Who connects to whom
Who connects to whomAn edge connects to the Validator first, then to the Controller and the Manager.EdgestartsValidatortemporaryControllerpermanentManagerpermanent

On small screens, swipe sideways or focus the diagram and use the arrow keys.

The Validator connection is temporary.

One per transport

A WAN Edge can connect to the controllers over each of its transports. BR-01 has an MPLS circuit and an internet line, so it can have a Controller connection on each, and one to the Manager. If one transport fails, the control connection on the other keeps the router in the fabric. The settings of the tunnel interface decide which transports are allowed to build them, so a transport can be used for user tunnels without carrying control connections, or the reverse. The next lesson in this unit puts the roles together: control component workflow.

One per transport
One per transportEach transport interface can have its own control connections.One transportOne set of connectionsTwo transportsTwo setsMore resiliencevs

On small screens, swipe sideways or focus the diagram and use the arrow keys.

A second transport gives control redundancy.

DTLS and TLS

DTLSTLS
Runs overUDPTCP
ReliabilityUDP does not retransmit; the protocol copes with loss itselfTCP retransmits and orders data
Firewall viewA UDP flow; some networks restrict or time out UDP fasterA TCP connection; often easier to pass or inspect
Chosen byA setting on the devices; both ends must use the same protocol. Check your release for the default and the exact option.

Both protect the connection in the same way: each end proves its identity with a certificate, the session is encrypted, and the content cannot be read or altered on the way. If the certificates are not accepted, no connection comes up, whatever the network allows. How certificates are issued and trusted is the topic of a later lesson.

DTLS and TLS
DTLS and TLSDTLS runs over UDP. TLS runs over TCP.DTLSUDP, defaultLower overheadTLSTCPEasier through some firewallsor

On small screens, swipe sideways or focus the diagram and use the arrow keys.

DTLS is the default. Use TLS where UDP is a problem.

How a connection is built

Building a connection
Building a connectionConnect, exchange certificates, authenticate, then keep alive.Connectto the addressCertificatesexchangedAuthenticateboth sidesUphello messages

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Both sides check the other.
  1. The edge has a path. The transport interface has an address and a route to the controller's address.
  2. A DTLS or TLS session starts. The edge connects to the controller on the chosen protocol, and the usual handshake begins.
  3. Each side shows a certificate. The edge and the controller check each other against the trust they hold. A device that fails this is refused.
  4. The device is checked against the fabric's device list. A valid certificate for a device that the fabric does not list is also not accepted.
  5. The connection comes up. The edge then starts OMP with the Controller and exchanges management data with the Manager over their connections.

Reading the output

show sdwan control connections

On an IOS XE edge: one line per connection. Look at the peer type, the colour it uses, and the state.

Example output written for this lesson, simplified; real output has more fields and a different layout
BR-01#show sdwan control connections
PEER TYPE  PROT  PEER SYSTEM IP  SITE ID  LOCAL COLOR   STATE
vsmart     dtls  10.255.0.11     1        mpls          up
vsmart     dtls  10.255.0.11     1        biz-internet  up
vmanage    dtls  10.255.0.10     1        biz-internet  connect
BR-01 has the Controller on both colours but the Manager only on biz-internet, and that line is in connect, not up: this Manager control connection is not established. The Controller lines are up, but this output alone does not prove OMP route exchange or user forwarding is healthy. The protocol column shows dtls here. State names and available fields depend on the release; use connection history to investigate the failed attempt.

Read it in three passes. Is there a line for each component the router should reach? Is each line up? Is it up on each transport that should carry it? The first line that fails the test is where to start.

Reading the output
Reading the outputThe control connection table shows each connection.Peer typevbond, vsmart or vmanageStateup, connect or challengeLocal and remote colourWhich transport carries it

On small screens, swipe sideways or focus the diagram and use the arrow keys.

The state and the last error matter most.

Verify the missing connection and the user path separately

show sdwan control connection-history show sdwan omp peers show sdwan bfd sessions

These read-only checks use IOS XE Catalyst SD-WAN 17.x command style. In connection history, correlate the peer and local colour with the recent failure reason. Check OMP peer state separately, then inspect BFD for the intended edge-to-edge path. An up BFD session verifies that monitored tunnel; test the actual application destination and its service-VPN route as well. Check the selected release for exact output fields. Do not clear healthy connections to obtain evidence.

Technical basis: Cisco control and data-plane troubleshooting and Cisco data-plane monitoring.

Common reasons a connection does not come up

Common reasons a connection does not come up
Common reasons a connection does not come upCause; What it looks like. No route or a blocked path to the controller: No line, or a line stuck in connect; other transports may be fine Firewall or NAT blocks the protocol: Works on one transport, fails on another; switching between DTLS and TLS can change the result Certificate not accepted: The session starts and is then dropped, on every transport Device not on the fabric's list: A valid certificate but no acceptance by the controller Wrong system IP, site ID or organisation name: The controller rejects the connection even though the network is fine Clock far from correct: Certificates look expired or not yet validCauseWhat it looks likeNo route or a blocked pathto the controllerNo line, or a line stuck in connect; other transports may be fineFirewall or NAT blocks theprotocolWorks on one transport, fails on another; switching between DTLS and TLScan change the resultCertificate not acceptedThe session starts and is then dropped, on every transportDevice not on the fabric'slistA valid certificate but no acceptance by the controllerWrong system IP, site ID ororganisation nameThe controller rejects the connection even though the network is fineClock far from correctCertificates look expired or not yet valid

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Each item on the left, with what it means on the right.

Compare a failing router with a working one on the same transport, but do not treat that comparison as proof of an identical path. The routers can have different source addresses, NAT mappings or firewall treatment. Use the failing router's history and endpoint reachability to narrow the cause.

Why a connection does not come up
Why a connection does not come upReachability, trust and identity.No connectionReachabilitypath or firewallCertificateexpired or untrustedIdentityorganisation or serial

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Check in that order.

Mistakes to avoid

  • Reading a healthy control connection as proof that user traffic works. The data plane has its own tunnels.
  • Checking one transport and calling the router healthy. A line can be up on one colour and missing on another.
  • Changing the protocol on one end only. DTLS and TLS do not interoperate.
  • Ignoring the clock on a new device. A wrong date is a common reason for certificate errors.

Test yourself on control connections

Predict · scenario 1

Which pair of devices does NOT normally build a control connection?

Predict · scenario 2

What is the main practical difference between DTLS and TLS for a control connection?

Predict · scenario 3

In the output above, BR-01's Manager line is in connect while OMP to the Controller is up. What is the effect?

Predict · scenario 4

A new edge has a valid route and firewall rules are open, yet no control connection comes up on any transport. The date on the router is two years wrong. What is the best next step?

FAQ

Is a control connection the same as an IPsec tunnel?
No. A control connection is a DTLS or TLS session to a controller and carries control and management information. An IPsec tunnel runs between two WAN Edges and carries user traffic. They are different sessions, built differently, and they fail for different reasons.
Why choose TLS instead of DTLS?
DTLS runs over UDP and TLS over TCP. Some networks pass or inspect one better than the other, for example a firewall that is happy with TCP but restricts UDP. The choice is a setting, and the controller and the edge need to agree. Check your release for the default and for where the option is configured.
How many control connections does a WAN Edge have?
It depends on how many controllers it uses and how many transports are allowed to connect. An edge with two transports and two Controllers can have several, because each transport can connect separately. Read the output of the show command on your own router rather than counting from a rule.