Start with the transport path
A new branch router, BR-01, is plugged in and does not appear in the Manager (formerly vManage). The first instinct is to look at certificates or templates. Possible causes include a missing WAN interface address, no route to a required endpoint, or an inactive provider circuit. SD-WAN is an overlay, so it only works once the underlay can carry a packet from the router to the controllers and to other sites.
This lesson covers the transport side only. How tunnels are built on top of it is in the overlay lesson.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Gi1 is BR-01’s provider-facing port; 203.0.113.10/30 is its source address on this lab link. The provider gateway is 203.0.113.9. A system IP identifies the device inside SD-WAN and does not replace this interface address. The remote control and WAN Edge endpoints need separate reachability checks.
What a transport interface needs
On small screens, swipe sideways or focus the diagram and use the arrow keys.
The transport address is a normal interface address. It is not the system IP, which identifies the router inside the fabric and is explained in System IP, Site ID and Device Identity.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
A transport interface in configuration
interface GigabitEthernet1
description to ISP-A (internet)
ip address 203.0.113.10 255.255.255.252
no shutdown
!
ip route 0.0.0.0 0.0.0.0 203.0.113.9Global-configuration fragment for Cisco IOS XE Catalyst SD-WAN 17.x on BR-01; verify the exact image and interface names. The addresses are documentation examples. Most networks push the interface settings from a Manager template or configuration group, and the transport VPN is VPN 0, which on this platform is the global routing table. The tunnel-interface settings that turn the interface into a TLOC are covered in the TLOC lesson.
Nothing here is specific to SD-WAN. That is the point: the transport side is ordinary routed IP, and ordinary tools find its faults.
This example uses a default route because the provider carries the remote destinations. It is not a universal requirement for 0.0.0.0/0. Check a destination-specific route and its next hop before changing routing. In a Manager-managed deployment, use the approved template or configuration-group workflow; a direct CLI change can be rejected or overwritten.
Checking the transport side
On small screens, swipe sideways or focus the diagram and use the arrow keys.
show ip route 198.51.100.31
show ip route 203.0.113.9
show sdwan control connections
show sdwan control connection-historyPrivileged EXEC on BR-01, IOS XE Catalyst SD-WAN 17.x. Inspect the route to this lab Controller and its gateway, current control peers and recorded connection failures. Command fields vary by release.
BR-01#show ip interface brief Interface IP-Address OK? Method Status Protocol GigabitEthernet1 203.0.113.10 YES manual up up GigabitEthernet2 172.16.1.2 YES manual up up GigabitEthernet3 unassigned YES unset administratively down down
unassigned, or a Protocol column of down, is a fault to fix before looking at anything else.BR-01#ping 198.51.100.1 source GigabitEthernet1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 198.51.100.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5)
Order of checks
On small screens, swipe sideways or focus the diagram and use the arrow keys.
- Physical and link. Is the interface up, and does the provider hand-off match (speed, VLAN tag, address method)?
- Address and mask. Is the address correct, from DHCP or static, and is it in the same subnet as the provider gateway?
- Endpoint routes. Does VPN 0 resolve each required control and remote tunnel address through a usable next hop?
- Outside reachability. Test the intended source and destination, inspect DNS if names are used, and compare ICMP results with actual control connection state.
- Only then the SD-WAN layers. Control connections, certificates, then tunnels.
Learn more: TLOC Components and Transport ReachabilityLogical Overlay and Encrypted Tunnel ConstructionNAT Traversal, DNS and Firewall Dependencies
Mistakes on the transport side
- Troubleshooting certificates when no route reaches the required control endpoint. Fix that route or return path first; absence of a default route alone does not prove this fault.
- Assuming that a working internet connection for users means a working transport. The WAN Edge uses its own source address and VPN 0, which can differ from what a laptop sees.
- Forgetting the private transport. An MPLS circuit that reaches other sites may not reach the controllers, which are often on a public address, so the router may need the internet link for control traffic.
- Ignoring MTU. Small packets pass while larger tunnel packets are dropped, which makes a link look unstable.
Investigate without widening access
In an isolated lab, record Gi1 status, the Controller route and control-connection state. If ICMP is deliberately filtered while a control connection remains up, explain why the failed ping does not contradict that connection. If the required route is genuinely absent, restore only the approved route and verify its return path, then recheck the control peer. Do not remove firewall rules or clear all sessions to make a ping pass.
A ping tests ICMP for one source and destination. It does not certify or disprove every SD-WAN path. A working controller connection also does not prove reachability to a remote WAN Edge.
Technical basis: Cisco Catalyst SD-WAN design guide, transport routing and firewall considerations. These examples have not been executed on a router.
Test yourself on the transport side
BR-01 Gi1 is up at 203.0.113.10/30. The route lookup for Controller 198.51.100.31 finds no route, and this lab design uses ISP gateway 203.0.113.9. Which change addresses the verified routing gap?
Which VPN normally carries the WAN Edge's transport interfaces?
A ping from BR-01's internet interface to an outside host succeeds, yet no control connection forms. What does the ping prove?