One of the most common use-cases for localized control policies is manipulating the local routing advertisements so that site-local routers prefer one vEdge over another in a dual-homed environment. This can be useful in scenarios where an advanced network service such as a next-gen firewall or application recognition engine requires traffic to flow symmetrically over the same router in both directions.

We will use the local network at the data center site shown in the following diagram for this lab example. You can see that dual-homed WAN edge routers are peering with two core switches using eBGP as a routing protocol of choice. With default BGP configuration, the onsite core switches load-balance the data traffic coming from local networks destined to the WAN across both vEdge routers. To create a symmetric traffic pattern and always prefer only one of the vEdge routers as an egress point to the WAN, we are going to manipulate the BGP routing advertisements from vEdge-1 in such a way so that the BGP routes being advertised from vEdge-1 are more preferred than the ones from vEdge-2. While we could use different BGP attributes to achieve this objective, we will adjust the BGP ORIGIN as illustrated in the diagram. 

Manipulating site-local routing with a route policy
Figure 1. Manipulating site-local routing with a route policy

In BGP, the origin code of IGP is preferred over EGP, which itself is preferred over INCOMPLETE. Therefore, if we match all routes advertised from vEdge-1 to the core switches and change the BGP Origin code of these routes to IGP, the core switches would select the vEdge-1’s routes as best due to better BGP Origin code.  

The Initial State

Before we begin with the SD-WAN configuration, let’s check the routing table of each of the core switches. 

CORE-SW1#sh ip route bgp
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
B        10.3.5.0/24 [20/1000] via 172.16.1.2, 00:02:07
                     [20/1000] via 172.16.1.1, 00:02:07
B        10.4.5.0/24 [20/1000] via 172.16.1.2, 00:02:07
                     [20/1000] via 172.16.1.1, 00:02:07
B        10.5.5.0/24 [20/1000] via 172.16.1.2, 00:02:07
                     [20/1000] via 172.16.1.1, 00:02:07
B        10.6.5.0/24 [20/1000] via 172.16.1.2, 00:02:07
                     [20/1000] via 172.16.1.1, 00:02:07

We can see that both switches have equal-cost routes to all remote branches via both WAN edge routers - vEdge-1 (172.16.1.1) and vEdge-2 (172.16.1.2).

Configuring a route policy

Now, let’s configure a route policy that sets the BGP origin to IGP on all routes sent from vEdge-1 to the core switches. Notice that we configure the localized policy directly on vEdge-1 (not on vSmart). In this lesson, we are going to use only the CLI. However, if you want to try this example in an existing sd-wan environment where the vEdges are in vManaged mode, you con use device/feature templates as well.

vEdge-1# conf t
Entering configuration mode terminal
vEdge-1(config)# policy
vEdge-1(config-policy)# route-policy SET-ORIGIN-IGP
vEdge-1(config-route-policy-SET-ORIGIN-IGP)# sequence 11
vEdge-1(config-sequence-11)# action accept
vEdge-1(config-action)#set origin igp
vEdge-1(config-set)# default-action accept
vEdge-1(config-route-policy-SET-ORIGIN-IGP)# commit and-quit

The policy has a similar structure to all other SD-WAN policy types. It has a name, followed by match-action sequences and a default action in the end. 

policy
 route-policy SET-ORIGIN-IGP
  sequence 11
   action accept
    set
     origin igp
  !
  default-action accept
!

Route policies are applied within the traditional routing protocol’s configuration, typically per-neighbourship. In our case, we will apply the route policy to the BGP neighbourship of vEdge-1 with both core switches. To do this, we enter the “vpn 5 > router > bgp 65000” configuration hierarchy, and under each neighbor’s configuration, we apply the route policy in either in or out direction. In our particular example, we want to manipulate the BGP advertisement from vEdge-1 to the core switches, and therefore, we apply the route policies in the outbound direction.

vpn 5
 router
  bgp 65000
   propagate-aspath
   address-family ipv4-unicast
    redistribute omp
   !
   neighbor 172.16.1.1
    no shutdown
    remote-as 65001
    address-family ipv4-unicast
     route-policy SET-ORIGIN-IGP out
    !
   neighbor 172.16.1.2
    no shutdown
    remote-as 65001
    address-family ipv4-unicast
     route-policy SET-ORIGIN-IGP out
 !

Once the policies are applied, we can see that only vEdge-1’s BGP routes have been inserted in the routing table of the core switches, and now they prefer only vEdge-1 as an egress point toward the WAN.

CORE-SW1#sh ip route bgp
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
B        10.3.5.0/24 [20/1000] via 172.16.1.1, 00:00:55
B        10.4.5.0/24 [20/1000] via 172.16.1.1, 00:00:55
B        10.5.5.0/24 [20/1000] via 172.16.1.1, 00:00:55
B        10.6.5.0/24 [20/1000] via 172.16.1.1, 00:00:55

If we check the BGP attributes of the route selection on any of the core switches, we will see that they choose the routers via vEdge-1 (172.16.1.1) as best because of the BGP ORIGIN attribute.

CORE-SW1#sh ip bgp 10.3.5.0/24
BGP routing table entry for 10.3.5.0/24, version 3
Paths: (2 available, best #2, table default)
Multipath: eBGP
  Advertised to update-groups:
     2         
  Refresh Epoch 1
  65000
    172.16.1.2 from 172.16.1.2 (1.1.1.2)
      Origin incomplete, metric 1000, localpref 100, valid, external
      Extended Community: SoO:0:1
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  65000
    172.16.1.1 from 172.16.1.1 (1.1.1.1)
      Origin IGP, metric 1000, localpref 100, valid, external, best
      Extended Community: SoO:0:1
      rx pathid: 0, tx pathid: 0x0

Key takeaways

This lesson has shown one of the most typical use-cases for localized control policies. However, the other common scenarios include:

  1. Manipulating the attributes of OMP routes when they are redistributed by a specific vEdge router into the site-local routing domain via any traditional routing protocol such as BGP or OSPF. For example: 
    1. Set BGP as-path / local_pref / community / origin / metric 
    2. Set OSPF metric / metric-type / OSPF-tag
  2. Manipulating the attributes of site-local routes when they are received by a specific vEdge router, redistributed into OMP, and sent to the vSmart controllers. For example:
    1. Set OMP tag
  3. Filter out particular route entries such as:
    1. Site-local routes (BGP, OSPF, etc) from being redistributed into OMP;
    2. OMP routes from being redistributed into the site-local routing protocol such as BGP or OSPF.