Configure topology custom policies for fine-grained control over route advertisement and path selection in the SD-WAN overlay.
Site targeting (inbound_sites/outbound_sites, and sequences[].match_entries.sites) also accepts network hierarchy groups and regions via the paired inbound_site_groups/outbound_site_groups/match_entries.site_groups keys - each group name expands to every site nested under it, unioned with any sites listed directly. See Example-4 and the version note below.
Example-1: This example demonstrates a custom control policy that accepts routes originating from connected networks with a specific OMP tag, and sets a preference value. The policy is applied site-level inbound from SITE_100 and outbound to SITE_200.
sdwan:
feature_profiles:
topology_profiles:
- name: topology_profile_1
description: custom control topology
custom_policies:
- name: custom_control_policy_1
default_action: reject
level: sites
inbound_sites:
- SITE_100
outbound_sites:
- SITE_200
sequences:
- sequence_id: 1
sequence_name: accept_connected
base_action: accept
type: route
protocol: ipv4
match_entries:
origin: connected
omp_tag: 100
action_entries:
preference: 200
omp_tag: 150
Example-2: This example demonstrates a custom control policy targeting regions instead of sites, with service chaining and TLOC actions.
sdwan:
feature_profiles:
topology_profiles:
- name: topology_profile_2
description: regional custom control
custom_policies:
- name: regional_policy
default_action: accept
level: wan_regions
role: border
inbound_regions:
- region_west
outbound_regions:
- region_east
sequences:
- sequence_id: 1
sequence_name: service_chain_rule
base_action: accept
type: route
protocol: ipv4
match_entries:
tloc:
ip: 1.1.1.1
color: mpls
encapsulation: ipsec
color_list: my_color_list
sites:
- SITE_100
action_entries:
service:
type: FW
vpn: 100
tloc_action: strict
Note: For the above example, my_color_list must be defined under sdwan.feature_profiles.policy_object_profile.color_lists.
Example-3: This example demonstrates a custom control policy with community matching, LAN VPN export, and service chain configuration.
sdwan:
feature_profiles:
topology_profiles:
- name: topology_profile_3
description: advanced custom control
custom_policies:
- name: advanced_policy
default_action: reject
level: sites
sequences:
- sequence_id: 1
sequence_name: community_match
base_action: accept
type: route
protocol: ipv4
match_entries:
community_list: my_community_list
lan_vpn_names:
- Corporate
- Guest
action_entries:
export_to_lan_vpn_names:
- Corporate
community: 100:200
community_additive: true
service_chain:
name: SC1
vpn: 100
tloc_ip: 10.0.0.1
tloc_color: mpls
tloc_encapsulation: ipsec
Note:
For the above example,
my_community_list must be defined under sdwan.feature_profiles.policy_object_profile.standard_community_lists.
Corporate and Guest must be defined as LAN VPN names under a service profile (sdwan.feature_profiles.service_profiles[].lan_vpns[].name) that is associated with a configuration group.
If a VPN referenced in lan_vpn_names or export_to_lan_vpn_names needs renumbering, create a new LAN VPN feature with the desired VPN ID rather than modifying the existing one in-place.
Example-4: This example demonstrates targeting by network hierarchy group instead of listing individual sites. EMEA and AMER are groups declared under sdwan.network_hierarchy; each expands to every site nested under it.
sdwan:
manager_version: "20.18.4"
network_hierarchy:
groups:
- name: EMEA
sites:
- name: SITE_100
site_id: 100
- name: SITE_200
site_id: 200
- name: AMER
sites:
- name: SITE_300
site_id: 300
feature_profiles:
topology_profiles:
- name: topology_profile_4
description: group-targeted custom control
custom_policies:
- name: custom_control_by_group
default_action: reject
level: sites
inbound_site_groups:
- EMEA
outbound_site_groups:
- AMER
sequences:
- sequence_id: 1
sequence_name: accept_all
base_action: accept
type: route
protocol: ipv4
match_entries:
site_groups:
- EMEA
action_entries:
preference: 200
Note: site targeting and Manager version
A group name (inbound_site_groups, outbound_site_groups, sequences[].match_entries.site_groups) must be declared as a group or region under sdwan.network_hierarchy, and a plain site name must be declared as a site there too - either directly, or nested under any group/region. An undeclared name fails validation, and (if it slips past validation, e.g. a var.model caller) fails the Terraform plan by name.
When sdwan.network_hierarchy is declared, every resolved site is sent as a network hierarchy UUID on Manager 20.18.1 and later - this is also what makes a sequences[].match_entries targeting a site actually render in the 20.18 Manager GUI; a site name is accepted by the API there but shows blank. An unset manager_version is treated as 20.18.1+.
Set manager_version below 20.18 (e.g. "20.15") to send plain site names on the wire instead, for Managers that predate hierarchy UUIDs. manager_version is required whenever sdwan.network_hierarchy is declared - validation rejects the combination of a declared hierarchy and an unset version.
