How a traditional router decides
A router receiving a packet looks at the destination address and finds the longest matching prefix in its routing table. If several routes match equally, an administrative distance and a metric break the tie. The packet leaves by the chosen next hop. Nothing in this process looks at who sent the packet, what application it belongs to, or how the path has been behaving.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
- Routing protocols fill the table. OSPF, EIGRP or BGP exchange prefixes with neighbours and each router computes its own result.
- The longest match wins. A more specific prefix beats a less specific one.
- Ties go to distance and metric. These are numbers, built into the protocol or set by the administrator.
- Equal results can share load. Equal-cost paths may be used together, but the split is by flow hash, not by what suits the application.
This works well on a LAN, where the paths are similar. On a WAN with an MPLS line and an internet line, it gives a blunt result: one path is preferred by metric, and the other waits as a backup.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
What changes in a policy-led design
An SD-WAN edge still performs a route lookup. Around it, three kinds of extra information come into the decision.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Two kinds of policy
Cisco SD-WAN separates policy by what it changes. The words differ between releases and documentation, so check the names in your own release, but the idea is stable.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
- Control policy acts on the routing information the Controller holds. It decides what routes and TLOCs (the addresses of an edge's attachments to a transport) each edge is told about. A hub-and-spoke topology is built this way: the spokes are shown only the hub's routes.
- Data policy acts on user traffic as it passes through an edge. It matches packet fields and can send a flow out a specific transport, mark it, or send it directly to the internet.
- Application-aware routing uses the probe measurements to keep a flow on a path that meets stated limits for loss, delay and jitter. A later lesson covers it in detail.
The idea underneath all three is the same: the administrator writes intent once, and the fabric turns it into behaviour at every edge.
The overlay still needs routing
Policy does not replace routes. If an edge does not know that 10.20.0.0/16 (an example prefix) is behind another site, no policy can send traffic there. Cisco SD-WAN uses its own protocol, OMP (the Overlay Management Protocol), to carry the routes between edges and Controllers. It is described in a later lesson. For now, treat it as a routing protocol for the overlay that runs between each edge and the Controller.
At the edge of the LAN, ordinary routing still applies. A branch may use OSPF or BGP with its LAN switch, and the SD-WAN edge brings those prefixes into the overlay and the overlay's prefixes back to the LAN.
One flow, compared
A user at BR-01 starts a voice call to a server behind HUB-01, with two transports available.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
The example is simplified. Real behaviour depends on the policy written, the thresholds set and your release, so treat the table as a model of the idea and not as a record of what any device does.
Where the trade-off sits
- Central control means central mistakes. One wrong policy reaches every edge it is applied to, so changes need care and a plan to undo them.
- Policy adds things to debug. When traffic takes an unexpected path, the answer may be in a policy, not in the routing table.
- More choice needs more measurement. Probes use a little bandwidth, and thresholds set too tight can make flows move more often than users would like.
Mistakes when comparing the two
- Describing SD-WAN as having no routing. It has routing tables and the OMP protocol. Policy works on top of them.
- Thinking policy can reach a prefix the edge does not know. Routes come first, policy shapes the choice.
- Treating control policy and data policy as one thing. One changes what routes are advertised, the other changes how packets are forwarded.
Test yourself on routing and policy
Which input does a plain routing table lookup on a traditional router use to choose a next hop?
An administrator wants spoke sites to learn routes only from the hub, so spoke-to-spoke traffic goes through the hub. Which kind of policy fits?
An edge has no route to a remote prefix because the Controller did not send it. A data policy says to send that traffic via the internet transport. What happens?