Cisco SD-WAN policies: localised, centralised, hub-and-spoke and application-aware routing

Two places a policy can live

Policies are built in the Manager, but they take effect in two different places. Localised policies are attached to a device template and run on the edge itself. Centralised policies are activated on the Controller, which either acts on them itself (control policies) or sends them to the edges (data and application-aware policies). For the vendor-neutral view of path selection, see SD-WAN path selection.

Each policy is built from reusable lists: application lists, prefix lists, site lists, VPN lists, TLOC lists and colour lists. Getting the lists right is most of the work.

Localised policies

Localised policies cover what one router does with its own traffic and routes:

• Localised data policy: access lists that match traffic and permit, drop, mark (DSCP) or police it. A policer caps a traffic class at a rate, for example limiting guest Wi-Fi to 20 Mbps, dropping or re-marking the excess.
• QoS: class maps, queues and schedulers on WAN interfaces, plus shaping to the real line speed.
• Localised control policy: route policies (like route maps) applied to BGP or OSPF in a service VPN, for example setting local preference or filtering prefixes learnt from a data centre neighbour.

policy-map GUEST-LIMIT
 class class-default
  police 20000000 conform-action transmit exceed-action drop
interface GigabitEthernet4
 service-policy input GUEST-LIMIT

That IOS-style example shows the idea; in SD-WAN you would normally build the same policer in the Manager's localised policy wizard so it is applied consistently to every branch template.

Centralised control policy: shaping the topology

By default every edge learns every TLOC and builds a full mesh of tunnels. That is not always wanted. A centralised control policy changes what the Controller advertises to each site. For a hub-and-spoke topology, the policy tells the Controller to send spoke sites only the hub's TLOCs, and to set the hub as the next hop for routes from other spokes. Spokes then build tunnels only to the hub, and spoke-to-spoke traffic goes through it, often so a central firewall can inspect it. Because the change is made on the Controller, no edge configuration changes at all.

Other control policy uses include regional meshes, preferring one data centre over another, and inserting a service such as a firewall in the path (service chaining).

Data policy and application-aware routing

Centralised data policies match traffic by application, prefix or DSCP and take actions such as dropping it, sending it out locally to the internet (local breakout), or steering it to a TLOC or colour.

Application-aware routing (AAR) is the best-known SD-WAN feature. You define SLA classes with limits for loss, latency and jitter, then match applications to them. BFD probes inside every tunnel measure the real values. If the preferred colour falls out of SLA, AAR moves that application to a tunnel that meets it, and moves it back when the preferred path recovers.

A centralised policy is activated in the Manager, which pushes it to the Controller. The Controller must be managed by a template for activation to work.

Real-world example: a firewall in the middle

An insurance broker with 25 offices had a full mesh by default. The security team wanted all office-to-office traffic inspected by the head office firewall. The network engineer created a site list for spokes and one for the hub, then a centralised control policy that advertised only hub TLOCs to spoke sites. After activation, spoke-to-spoke tunnels disappeared and traffic passed through the hub. A month later, video calls between offices suffered, so she added an AAR policy that kept voice and video on the MPLS colour unless it breached the voice SLA, and a policer limiting backup traffic during office hours.