SD-WAN Localized Policy: ACLs and Route Policies at the Edge

Centralised policy shapes the whole overlay from the Controller. But some things belong on the device itself - the ACL on a specific interface, the QoS treatment as packets leave a port, the route-map filtering what a branch redistributes into OMP. That is localised policy, and while it gets less attention than the centralised kind, forgetting it is how you end up with a beautifully engineered overlay that still drops the wrong packets at the edge.

This article covers localised policy: access lists, QoS, and route policy applied on the WAN Edge. It extends the complete SD-WAN guide. Command syntax is drawn from Cisco's current 20.x documentation, clearly labelled as a documented reference.

Centralised vs localised: the division of labour

The rule of thumb: if it is about the overlay's shape or which flows go where across the fabric, it is centralised. If it is about how a specific interface on a specific device treats packets, it is localised. An interface ACL, a queueing policy on an egress port, or filtering the routes a branch redistributes into OMP - all localised.

Localised ACLs

An access list applied to an interface on the WAN Edge - exactly what you would expect, in SD-WAN's policy syntax:

policy
 access-list BLOCK-GUEST-TO-CORP
  sequence 10
   match
    source-data-prefix-list GUEST-SUBNET
    destination-data-prefix-list CORP-SUBNET
   !
   action drop
    count guest-to-corp-drops       ! counter for visibility
   !
  !
  default-action accept
 !
!

Applied to the interface, in a direction:

sdwan
 interface GigabitEthernet2
  access-list BLOCK-GUEST-TO-CORP in
 !

These are for local, per-interface filtering - the kind of thing that does not belong in a fabric-wide data policy because it is specific to one site's topology. A guest subnet blocked from the corporate subnet at the branch, a management-plane ACL, an anti-spoofing filter on a WAN interface.

Localised QoS

QoS is inherently local - it is about how this interface queues and schedules packets as they leave. Centralised policy can mark traffic (set DSCP), but the actual queueing, shaping, and scheduling is localised policy on the egress interface:

policy
 class-map VOICE
  match dscp ef
 !
 class-map CRITICAL
  match dscp af41
 !
!
policy
 qos-scheduler VOICE-Q
  class    VOICE
  bandwidth-percent 20
  scheduling llq            ! low-latency queue for voice
  drops     tail-drop
 !
 qos-scheduler CRITICAL-Q
  class    CRITICAL
  bandwidth-percent 30
  scheduling wrr
 !
 qos-map BRANCH-QOS
  ...
 !
!

Applied to the WAN egress interface, this is what actually protects voice during congestion. The division is important: a centralised data policy might mark voice EF; the localised QoS map is what puts EF-marked traffic in the low-latency queue. Marking without queueing does nothing under congestion; queueing without marking has nothing to prioritise. You need both.

Note that on the internet transport, your QoS markings are honoured only up to the point packets leave your edge - the internet ignores DSCP. So localised QoS matters most on the egress shaping toward a congested WAN link, protecting your own outbound queue, which is exactly where it can help.

Localised route policy

Route policy on the edge controls the interaction between the service-side routing (BGP/OSPF/EIGRP to the LAN) and OMP. This is where you filter, tag, or set attributes on routes as they cross between the two:

policy
 route-policy REDISTRIBUTE-FILTER
  sequence 10
   match
    address CORPORATE-PREFIXES
   !
   action accept
    set
     omp-tag 100            ! tag routes redistributed into OMP
   !
  !
  sequence 20
   action reject             ! do not leak anything else into OMP
  !
 !
!

Applied to the redistribution from the service-side protocol into OMP (and vice versa), localised route policy controls exactly which of a branch's local routes become visible across the whole fabric. Get this wrong and either a branch leaks routes it should not (polluting the overlay) or fails to advertise routes it should (breaking reachability). It is the SD-WAN equivalent of a redistribution route-map, and the same discipline applies - tag on the way in, filter on the way out, never redistribute without a policy.

Verifying localised policy (documented reference)

Edge# show sdwan policy access-list-counters
NAME                    COUNTER NAME          PACKETS   BYTES
BLOCK-GUEST-TO-CORP     guest-to-corp-drops   1043      156450

Edge# show sdwan policy access-list-associations
Edge# show policy-map interface GigabitEthernet1     ! QoS, standard IOS XE

The ACL counter is the practical verification - it proves the ACL is not just configured but actually matching traffic. For QoS, the standard IOS XE show policy-map interface shows the queue statistics, because the localised QoS ultimately renders to ordinary MQC on the interface.

Where each policy type lives - the complete map

Keep this map in your head and SD-WAN policy stops being confusing. Every requirement lands in exactly one of these boxes. "I want branches to prefer MPLS" is centralised control. "I want voice steered by SLA" is centralised data. "I want this port to drop guest traffic" is localised. The mistake is trying to solve a local problem with a fabric-wide policy, or vice versa.

Key takeaways

• Localised policy is configured per device and affects that device's own interfaces and forwarding: ACLs, QoS, and route policy. Centralised policy shapes the overlay; localised policy handles the per-box treatment.
• ACLs filter per interface - the local, site-specific filtering that does not belong in a fabric-wide data policy.
• QoS is inherently localised: centralised policy can mark DSCP, but the queueing and scheduling that protects voice under congestion is localised policy on the egress interface. You need both marking and queueing.
• Route policy on the edge controls what local (BGP/OSPF/EIGRP) routes cross into OMP and how they are tagged - the SD-WAN redistribution discipline.
• Verify with show sdwan policy access-list-counters (proves the ACL matches) and show policy-map interface (QoS queue stats).
• Every SD-WAN policy requirement maps to exactly one type: control (topology), data (flows), or localised (per-device). Match the requirement to the right box.

Next: Direct Internet Access (DIA) in Catalyst SD-WAN. The full cluster index lives on the SD-WAN pillar.