Route Summarization with Cisco SD-WAN(Viptela)

Overview

A lot of normal routing concepts change when they are incorporated into an SD-WAN solution. Cisco’s OMP, or Overlay Management Protocol, uses a similar method of summarization to MP-BGP. Since OMP is VRF(or VPN) aware, summarization must be done per VRF/VPN.

Taking on a similar configuration to MP-BGP we can see the normal SD-WAN (no summarization) configuration below:

! output of "show sdwan run sdwan"
omp
  !*** omitted for brevity ***!
  address-family ipv4 vrf 100
   advertise connected
   advertise ospfv3
  !
  address-family ipv6 vrf 100
   advertise ospf external
   advertise connected
  !
  address-family ipv4
   advertise bgp
   advertise connected
   advertise static
  !
  address-family ipv6
   advertise bgp
   advertise connected
   advertise static

As we can see, redistribution in OMP is a wildly different syntax than normal routing protocols. Instead of the “redistribute” syntax, OMP uses the “advertise” syntax. These commands are functionally similar.

On our test c8000v device, we have two routes (10.3.1.0/24 and 2001:300:1::/64) that we would like to summarize to /16 and /48 respectively. As of now, from the perspective of another cEdge in the fabric we see the subnets as-is:

! perspective from another cEdge !
m   10.3.1.0/24 [251/0] via 10.11.254.1

m   2001:300:1::/64 [251/0]
     via 10.11.254.1%default, Sdwan-system-intf%default

The CLI Method

The first method of configuration we will look at is the CLI, meaning the edge device doing the summarization does not have a device template applied. People who are familiar with BGP will feal right at home doing this config. The format is similar from a hierarchy perspective. You issue the “advertise aggregate” command under the address family of interest. Ensure that you are under the service side address family with the correct VRF.

sdwan
   !
   omp
    address-family ipv4 vrf 100
     advertise aggregate 10.3.0.0/16 aggregate-only
    !
    address-family ipv6 vrf 100
     advertise aggregate 2001:200:1::/48 aggregate-only

The Template Method

Most people manage their edge devices in the UI using templates. Summarization can be a little tricky to find when applying it via a template. Instinctively, you may be inclined to check the edge’s global OMP template to try to summarize. But, if you think about it a little longer, you will realize that the edge’s OMP template is global, and these devices are VRF aware. Summarizing globally is not possible, you must summarize under the VPN template.

Navigate to the “Service VPN” section of your device template and take a look at the name of the template for the service VPN of interest:

You can see that in my lab the template name is c8000v-VPN-100.

To apply summarization, we scroll to the “Advertise OMP” section of the VPN template and click “New Advertise OMP”. In the protocol dropdown select “aggregate”

Summarization is done in the exact same spot as redistribution in the VPN template. You are essentially using an “advertise” statement to statically advertise a shorter prefix.

Clicking aggregate may cause some confusion because you are never asked to enter a prefix before clicking “Add”. The UI choices here are questionable, but you get used to it. After clicking “Add” you get a new section below where you can click “New Aggregate”

Clicking “New Aggregate” allows you to enter the prefix, and also select “Aggregate Only” which functions the same as the parallel BGP feature.

Clicking “Add” adds the prefix to the aggregate list. What about IPv6? Well, that is surprisingly simple. Flipping the toggle under “Advertise OMP” to IPv6 allows us to repeat the last two steps identically for our v6 prefix.

Cisco decided to do no input validation for masks and addresses under the “aggregates” menu. Ensure you do not have a network address that intrudes into your host bits, or the template will fail to apply.

Ensure to save the Aggregate entry when you are done adding it, then proceed to save the feature template and apply it to the edge.

Verification

Verification is exactly the same as any other VRF-Aware summarization. Start by looking at routes from the perspective of other edges. The main difference you could choose in validation is to validate from vSmart rather than another edge. This may be helpful if you have central policies on vSmart that interfere with your goal. Remember, edges have no direct control plane connection to each other, and communicate control plane information exclusively through vSmart.

! "show ip route vrf 100" on another edge
m        10.3.0.0/16 [251/0] via 10.11.254.1, 00:01:41

! "show ipv6 route vrf 100"
m   2001:300:1::/48 [251/0]
     via 10.11.254.1%default, Sdwan-system-intf%default

Should you not see the routes, first try the following on a remote edge to ensure it is not being received but not resolved (you should see C,I,R):

! "show sdwan omp routes" 
!*** output clipped for brevity ***!
 PREFIX              FROM PEER        ID     LABEL    STATUS  
-------------------------------------------------------------
10.3.0.0/16         10.1.254.3       1      1003     C,I,R   

In the event you do not see the route, check that it is being advertised from the edge doing the summarization:

! "show sdwan omp routes" 
                                     PATH
PREFIX              FROM PEER        ID  
-----------------------------------------
10.3.0.0/16         255.255.255.255  196 

You should see the summary route with a “FROM PEER” of all 255s, indicating the local router. If you see the route here, but not on any other devices check your policy on vSmart to ensure it is not being filtered. If you do not see the route here, ensure you have a valid network in the aggregate to summarize.

Cisco SD-WAN Manager (vManage)	20.13.1
Cisco SD-WAN Validator (vBond)	20.13.1
Cisco SD-WAN Controller (vSmart)	20.13.1
Cisco SD-WAN Edge (IOS-XE)	17.13.01a
Cisco CML	2.7.0+build.4