ENSDWI Part 7: OMP, TLOCs, Routing Protocols, Multicast, and Config Groups

15 July 2026 CiscoENSDWISDWAN

Part 6 got edges onboarded and cabled to their transports. This part configures what runs on them — the rest of domain 3.0, blueprint lines 3.3 through 3.7.

3.3 Configure OMP

OMP was described in Part 2; here’s the configurable surface:

sdwan
 omp
  graceful-restart              ! default on, timer 43200s (12h), max 604800
  send-path-limit 4             ! ECMP paths advertised by vSmart per prefix (max 16)
  ecmp-limit 4                  ! paths installed in RIB (max 16)
  overlay-as 65100              ! AS number OMP presents when redistributing into BGP
  advertise connected           ! per-protocol advertisement into OMP (per VPN too)
  advertise static
  no advertise bgp              ! BGP/OSPF/EIGRP are NOT advertised by default

Defaults the exam tests: connected and static are advertised into OMP by default; BGP, OSPF (inter-area/external), and EIGRP are not — you enable them per-VPN or globally. OSPF intra-area routes are advertised by default on vEdge lineage; the safe exam answer is “explicitly advertise the IGP”.

Path selection recap (tested from both directions): valid → higher preference → higher TLOC preference → origin (connected < static < eBGP < OSPF intra < …, lower metric wins) → highest system-IP tiebreak. send-path-limit is vSmart-side (what gets reflected), ecmp-limit is edge-side (what installs).

3.4 Configure TLOCs

The tunnel-interface block is where a TLOC comes to life:

sdwan
 interface GigabitEthernet0/0/0
  tunnel-interface
   encapsulation ipsec          ! or gre; both = two TLOCs on one interface
   color biz-internet [restrict]
   preference 100               ! TLOC preference — higher preferred fabric-wide
   weight 10                    ! ECMP ratio between equal TLOCs
   max-control-connections 2    ! 0 = data-only TLOC (classic on MPLS)
   allow-service all | sshd|netconf|dns|icmp|...

Tested knobs: color (public vs private group behaviour from Part 2), restrict (this color only tunnels to the same color), preference/weight (path preference vs load-share ratio), max-control-connections 0 (TLOC carries data but no control — the standard MPLS pattern when control rides Internet), and allow-service (implicit ACL on the tunnel interface: what non-tunnel traffic the transport interface will accept — SSH to the WAN IP fails until allow-service sshd, a favourite gotcha).

carrier, nat-refresh-interval, and hello tuning exist; recognise, don’t memorise.

3.5 Service-side routing and VRRP

The blueprint lists VRRP, OSPF, BGP, EIGRP — the protocols an edge speaks into the site per VPN. What matters for each, plus the loop-prevention marker every redistribution pair uses:

VRRP (3.5.a)

First-hop redundancy on the service side (LAN) of a dual-router site — SD-WAN’s answer to HSRP, and VRRP is the only FHRP supported on the service side. Facts: priority highest wins (default 100), preempt is default-on in this implementation, and the SD-WAN-specific feature — tloc-change-preference / tracking the overlay: if the primary router loses its tunnels (OMP/TLOC down), VRRP fails over to the router that still has a working overlay. A question about “LAN hosts still sending traffic to a router whose WAN is dead” is pointing at VRRP overlay tracking.

OSPF (3.5.b)

Standard per-VPN OSPF to the LAN. The loop-prevention detail: routes an edge redistributes from OMP into OSPF are marked — vEdge lineage sets the down bit / external route with a tag — and an edge receiving an OSPF route carrying that marker won’t re-advertise it into OMP. Design note that gets tested: OMP→OSPF redistribution makes routes external (Type 5) by default, so a backdoor link running intra-area OSPF will beat the overlay on admin-distance/type unless you filter or tune.

BGP (3.5.c)

Per-VPN eBGP/iBGP to DC cores, colo providers, cloud gateways. Loop prevention: AS-path — with overlay-as configured, OMP-sourced routes carry the overlay AS when redistributed into BGP, and site edges reject routes containing their overlay AS. propagate-aspath controls whether AS-path carries across OMP end-to-end. Standard DC pattern: pair of edges eBGP to the core, advertise bgp into OMP, and AS-path or tag filtering to stop the two edges reflecting each other’s routes back.

EIGRP (3.5.d)

cEdge (IOS-XE) only — vEdge never spoke EIGRP. Redistribution from OMP into EIGRP is external (AD 170), and IOS-XE SD-WAN sets an SoO (site-of-origin)-style tag to stop multi-edge sites looping routes. Recognise “EIGRP = IOS-XE cEdge only” and “external + tagged” and you have what the exam wants.

3.6 Multicast

Describe-level. The model: no multicast inside the tunnels natively — edges replicate. Components:

  • PIM-SM on the service side (the LAN speaks normal PIM; the overlay carries multicast as replicated unicast).
  • Each site with receivers/sources elects a multicast replicator role (usually the hub or a beefy edge): sources register, and the replicator forwards copies over the overlay to sites with receivers, so a branch source doesn’t unicast-replicate to fifty sites itself.
  • OMP carries the multicast routing state (multicast AFI: sources, groups, joins) between edges/vSmart — there’s no PIM across the overlay.
  • IGMP on service-side interfaces for receiver discovery; RP is on the service network (edge can be RP on vEdge lineage; typical answer places RP/replicator at the hub).

Memory hook: PIM to the site, OMP across the fabric, replicator does the heavy lifting.

3.7 Config groups, feature profiles, and workflows

The v1.2 addition — Cisco’s replacement trajectory for device/feature templates.

The old model (still on the exam, still everywhere in production): feature templates (one per feature: VPN, interface, OMP, BFD…) compose into a device template (per model), which attaches to devices with per-device variable values filled at attach time. One device = exactly one device template; a device with a template attached is vManage-managed — CLI changes are overwritten on next push. CLI templates exist as the all-or-nothing alternative.

The new model — configuration groups: built from feature profiles (System, Transport & Management, Service, Policy, CLI, and others), each profile containing parcels (the individual feature configs). Differences the exam probes:

  • Config groups are solution-level, not device-model-level — one group serves mixed hardware; the old device template was bound to a model.
  • Built via guided workflows (Workflows → Create Configuration Group) with sensible defaults — the “workflow” word in the blueprint points here.
  • Variables/tags system for per-device values; deploy is an explicit step after association.
  • A device uses config groups or device templates, never both.
  • Coexists with templates today; new deployments are steered to config groups.

For the exam: know the vocabulary mapping (device template ↔ config group; feature template ↔ feature profile/parcel), the model-bound vs model-agnostic distinction, and that both end in NETCONF pushes from vManage.

Verification commands

show sdwan omp routes vpn 10             ! C/I/R flags, preference, origin per prefix
show sdwan omp services                  ! service routes (FW, TE...) per VPN
show ip ospf neighbor / show ip bgp vpnv4 all summary / show ip eigrp neighbors
show vrrp                                ! service-side FHRP state
show sdwan multicast replicator|topology ! replicator election, OMP multicast state
show sdwan system status                 ! config template/group attachment state

Exam traps for this domain

  • BGP/OSPF/EIGRP are not advertised into OMP by default; connected/static are.
  • preference on OMP route vs preference on TLOC are different knobs; both beat origin metric, OMP-route preference is compared first.
  • allow-service gates management traffic on tunnel interfaces — SSH-to-WAN-IP questions live here.
  • VRRP is the only supported service-side FHRP, and it can track the overlay.
  • Loop-prevention markers by protocol: OSPF = down-bit/tag, BGP = overlay AS in AS-path, EIGRP = external + SoO tag.
  • Multicast: replicator + OMP, no PIM over the fabric, PIM-SM/IGMP on the LAN.
  • One device template per device, model-bound; config groups are model-agnostic and use feature profiles/parcels. Never both on one device.

Domain 3.0 done — 40% of the exam behind you. Part 8 starts the Policies domain with the centralized control policy engine: where it runs, how sequences match, and how hub-and-spoke and regional topologies actually get built.