Route Filtering and Topology Policies

Objective

In this lesson we will configure route filtering and topology policies in a Cisco SD‑WAN fabric to control which routes are advertised across the overlay and to restrict which transport TLOCs (colors) are used between sites. This matters in production because uncontrolled route advertisement or unconstrained path selection can lead to routing leaks, inefficient traffic paths, or policy violations (for example sending sensitive traffic over the public Internet). A common real‑world scenario: a regional hub must advertise only a subset of its internal subnets to remote branches and branch‑to‑branch traffic must be forced to traverse an MPLS TLOC (private color) instead of the Internet color.

Topology (recap of Lesson 1)

ASCII topology — exact interface names and IPs shown:

Router-A (WAN Edge) Internet Router-B (WAN Edge)

---

GigabitEthernet0/0 Internet GigabitEthernet0/0 SysIP: 10.0.0.1 --------------------------------------------------- SysIP: 10.0.0.2 tunnel-interface encapsulation ipsec tunnel-interface encapsulation ipsec color: Internet color: Internet GigabitEthernet0/1 MPLS GigabitEthernet0/1 (tloc color: MPLS) (provider MPLS cloud) (tloc color: MPLS)

Notes:

• Router-A SysIP: 10.0.0.1 (from reference). Router-B SysIP: 10.0.0.2 (peer used for lab exercises).
• Interfaces shown are GigabitEthernet0/0 and GigabitEthernet0/1 — these exact names appear in the reference material.

Device table

Device	Role	SysIP	Interfaces (used)
Router-A	WAN Edge	10.0.0.1	GigabitEthernet0/0, G0/1
Router-B	WAN Edge	10.0.0.2	GigabitEthernet0/0, G0/1

Tip: In production the SysIP is the address the Controller uses to identify the WAN Edge in OMP. In our lab SysIP 10.0.0.1 (Router-A) is the authoritative value shown in the reference.

Quick Recap

• The fabric control plane uses OMP (Overlay Management Protocol) to exchange routes (subnets and TLOC reachability) between WAN Edge routers and Controllers. OMP is TCP‑based and runs over authenticated TLS/DTLS inside the control connections.
• A TLOC identifies transport locators with a color and encapsulation (for example, color: Internet, encap: IPSec). The reference shows SysIP 10.0.0.1 and colors such as Internet and MPLS.
• Route filtering is implemented via route policies that control what the router advertises/accepts into OMP. Topology policies (color restrictions and rules) control which TLOCs are permitted to carry traffic between sites.

Key Concepts (theory + practical behavior)

• OMP route advertisement vs. local routing

  • Theory: OMP advertises connected/static/learned prefixes to other WAN Edges and Controllers. In production, you must control which prefixes are advertised to avoid leaking internal-only networks.
  • Behavior: When you apply an OMP export policy that denies a prefix, that prefix will not be encoded into OMP updates and will not be installed into remote routing tables.

• Route‑policy / prefix‑set filtering

  • Theory: Route policies evaluate prefixes (via prefix-sets) and then take an action (permit/pass or deny/drop). They operate at the control plane before OMP advertisement or when importing OMP routes into the local RIB.
  • Behavior: A deny in an export route-policy prevents advertisement; a deny in an import route-policy prevents the route from being installed locally.

• TLOC / color choices and color‑restrict

  • Theory: Each transport interface advertises a TLOC with a color (e.g., Internet, MPLS). Color‑based topology policies restrict which colors can form IPSec tunnels or carry traffic between sites.
  • Behavior: If a topology policy restricts a traffic flow to MPLS color, the edge will not attempt an IPSec tunnel to a remote TLOC that is only reachable via Internet color.

• Control vs Data plane effect

  • Theory: Route filtering affects the control plane (what routes are known to whom); topology policies influence the data plane (which tunnels are used). Both together let you enforce path and reachability guarantees across an enterprise SD‑WAN fabric.

Step-by-step configuration

We will:

1. Configure the transport interfaces and mark their TLOC colors.
2. Create a prefix-set to match the subnet we want to filter (example: 10.0.0.0/24).
3. Create a route-policy that denies that prefix on OMP export.
4. Apply the export policy under router omp.
5. Configure a topology policy (color restrict) to force branches to use MPLS color for branch-to-branch site pairs.

Each step includes commands, rationale, and verification.

Step 1: Configure transport interfaces and TLOC colors

What we are doing: Configure the physical interfaces used for transports and declare them as TLOCs with encapsulation IPsec and a color. This tells the SD‑WAN software which transport (color) each interface represents and ensures the device advertises the correct TLOC to the controllers.

configure terminal
interface GigabitEthernet0/0
 description WAN-Internet-Transport
 ip address 10.0.0.1 255.255.255.0
 no shutdown
 tunnel-interface
  encapsulation ipsec
  color Internet
 exit
exit

interface GigabitEthernet0/1
 description WAN-MPLS-Transport
 ip address 192.168.100.2 255.255.255.0
 no shutdown
 tunnel-interface
  encapsulation ipsec
  color MPLS
 exit
exit
end

What just happened:

• The GigabitEthernet0/0 interface is assigned IP 10.0.0.1 and declared as a TLOC with encapsulation set to IPSec and color "Internet". This causes the device to advertise a TLOC with color Internet in OMP updates.
• GigabitEthernet0/1 is marked as color MPLS and will advertise that TLOC as well. Advertised TLOCs are the building blocks for topology decisions and tunnel setup.

Real-world note: In production, each transport to a different provider or link type (Internet, MPLS, LTE) should have a unique color to allow policy control over path selection.

Verify:

show omp tlocs

Expected output (complete):

TLOC           Site-ID     System-IP     Color     Encapsulation   Protocol  Preference
10.0.0.1:0     site-A      10.0.0.1      Internet  IPSec           dtls/tls  0
192.168.100.2:0 site-A     10.0.0.1      MPLS      IPSec           dtls/tls  0

Step 2: Create a prefix-set to match the subnet we will filter

What we are doing: Define a prefix-set that matches the prefix 10.0.0.0/24 we want to prevent from being advertised across OMP. Prefix-sets are reusable and allow precise prefix matching.

configure terminal
prefix-set DENY-10
 seq 10 permit 10.0.0.0/24 le 32
exit
end

What just happened:

• The prefix-set named DENY-10 now matches any route whose destination falls within 10.0.0.0/24. This object will be referenced by the route-policy so we can deny that specific subnet from being advertised.

Real-world note: Use prefix-sets for maintainability — if the block of prefixes grows you only update the prefix-set rather than multiple policies.

Verify:

show prefix-set DENY-10

Expected output (complete):

Prefix-set DENY-10
 seq 10 permit 10.0.0.0/24 le 32

Step 3: Create a route-policy to deny the prefix on OMP export

What we are doing: Build a route-policy that consults the prefix-set and drops matching prefixes. This route-policy will be applied when exporting control plane prefixes into OMP.

configure terminal
route-policy FILTER-OUT-10
 if destination in DENY-10 then
  drop
 endif
 pass
end-policy
exit
end

What just happened:

• The route-policy FILTER-OUT-10 evaluates incoming candidate routes for export to OMP. If a route’s destination matches DENY-10 (10.0.0.0/24), the policy drops it (prevents advertisement). Otherwise, the policy passes the route so it can be advertised.

Real-world note: Export policies are a safe way to remove sensitive internal prefixes from the global overlay. Always test with a single prefix-set before broad application.

Verify:

show route-policy FILTER-OUT-10

Expected output (complete):

Route-policy FILTER-OUT-10
 if destination in DENY-10 then
  drop
 endif
 pass
End of policy

Step 4: Apply the route-policy to OMP export

What we are doing: Attach the route-policy to the OMP process so the device will honor the policy when advertising routes to controllers and peers.

configure terminal
router omp
 distribute-list route-policy FILTER-OUT-10 out
exit
end

What just happened:

• The OMP process will now consult FILTER-OUT-10 for outbound advertisements. Any prefix dropped by the policy will not be included in OMP update messages to Controllers or other WAN Edge routers, effectively hiding the prefix from the fabric.

Real-world note: Export filtering should be used carefully at hubs; a mistaken deny can make a subnet unreachable across the fabric.

Verify:

show omp routes

Expected output (complete) — note that 10.0.0.0/24 should be absent in OMP advertised routes:

Network          Next-hop         Protocol   Source
10.0.1.0/24      10.0.0.1         connected  local
10.1.0.0/16      192.168.50.1     bgp        learned
<No entry for 10.0.0.0/24 - filtered from export>

Also verify OMP advertisements outbound (controller-facing):

show omp neighbors

Expected output (complete):

Neighbor: controller-1 (10.0.0.100)
 State: UP
 Last-redirect: none
 Advertised networks:
 10.0.1.0/24
 10.1.0.0/16
 <10.0.0.0/24 not advertised due to FILTER-OUT-10>

Step 5: Configure a topology policy (color-restrict) to force MPLS for branch-to-branch traffic

What we are doing: Create and apply a topology-style rule that restricts traffic between certain sites to use only TLOCs with color MPLS. This ensures sensitive branch‑to‑branch traffic traverses the private MPLS transport rather than the public Internet.

configure terminal
topology-policy BRANCH-TO-BRANCH-MPLS
 rule 10
  source site site-A
  destination site site-B
  allow color MPLS
  deny color Internet
 exit
exit
end

What just happened:

• The topology-policy BRANCH-TO-BRANCH-MPLS contains a rule that, for traffic from site-A to site-B, permits only MPLS color TLOCs and denies Internet color TLOCs. When the routing decision chooses a TLOC to forward data-plane traffic, it will skip any non‑MPLS TLOC for this flow.

Real-world note: Topology policies are particularly valuable when compliance or performance SLAs require that inter-branch traffic never traverse public Internet transports.

Verify:

show topology-policy BRANCH-TO-BRANCH-MPLS

Expected output (complete):

Topology-policy BRANCH-TO-BRANCH-MPLS
 Rule 10:
  Source: site-A
  Destination: site-B
  Allowed colors: MPLS
  Denied colors: Internet
End of policy

Also confirm data-plane selection behavior (simulate or view active path selection):

show omp tlocs

Expected output (complete) — demonstrates available TLOCs and the selected color for the flow:

TLOC           Site-ID     System-IP     Color     Encapsulation   Selected
10.0.0.1:0     site-A      10.0.0.1      Internet  IPSec           not-selected (policy denied)
192.168.100.2:0 site-A     10.0.0.1      MPLS      IPSec           selected

Verification Checklist

• Check 1: The prefix 10.0.0.0/24 is not advertised in OMP updates — verify with show omp routes and show omp neighbors. Expected: no entries for 10.0.0.0/24 in advertised networks.
• Check 2: The prefix-set DENY-10 shows the correct prefix — verify with show prefix-set DENY-10. Expected: sequence entry for 10.0.0.0/24.
• Check 3: Topology policy enforces MPLS for branch-to-branch traffic — verify with show topology-policy BRANCH-TO-BRANCH-MPLS and show omp tlocs. Expected: policy shows allowed color MPLS and MPLS TLOC selected for the flow.

Common Mistakes

Symptom	Cause	Fix
The prefix still appears on remote routers	Route-policy applied incorrectly (e.g., applied inbound instead of outbound), or not attached to OMP	Ensure policy is attached with distribute-list route-policy <policy> out under router omp
TLOC still used with Internet color despite policy	Topology policy not matching site IDs or rule order wrong	Verify site identifiers in the rule and ensure rule order allows the desired action; use show topology-policy to confirm
No routes at all advertised after applying policy	Route-policy is too broad and denies all prefixes (e.g., missing a pass at the end)	Edit policy to include a final pass statement for non‑matched prefixes
Traffic paths unchanged after topology policy	Device has no MPLS TLOC known for the destination or preference settings override selection	Confirm MPLS TLOC is present via show omp tlocs and check TLOC reachability; ensure policy allows the correct TLOC color

Key Takeaways

• Use route-policy (with prefix-sets) to precisely control which prefixes are advertised via OMP. This protects sensitive networks and prevents route leaks across regions.
• Topology policies (color restrict) control which transport (TLOC color) is eligible for a traffic flow — vital for enforcing SLAs and compliance (e.g., force MPLS for PCI traffic).
• Always verify both control-plane state (OMP routes, advertised lists) and data-plane outcomes (selected TLOCs, traffic forwarding) — filtering affects the control plane; policies affect data-plane tunnel selection.
• In production, document prefix-sets, route-policies, and topology rules carefully; small changes can have wide-reaching effects on reachability and should be tested in stages.

Warning: Route and topology policies can make networks unreachable if misconfigured. Always apply conservative policies first, validate widely with show commands, and use incremental rollouts in production.

---

End of Lesson 6/7 — Next lesson will cover application-aware routing and SLA‑based policies (how to steer traffic per application and performance metrics).