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.
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 (22.214.171.124) 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 (126.96.36.199) Origin IGP, metric 1000, localpref 100, valid, external, best Extended Community: SoO:0:1 rx pathid: 0, tx pathid: 0x0
This lesson has shown one of the most typical use-cases for localized control policies. However, the other common scenarios include:
- 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:
- Set BGP as-path / local_pref / community / origin / metric
- Set OSPF metric / metric-type / OSPF-tag
- 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:
- Set OMP tag
- Filter out particular route entries such as:
- Site-local routes (BGP, OSPF, etc) from being redistributed into OMP;
- OMP routes from being redistributed into the site-local routing protocol such as BGP or OSPF.