Note on Policy Components in Cisco SD-WAN

There are 2 types of policies in Cisco SD-WAN.

1. Centralized

2. Localized

Centralized Policies are applied at the WAN side (Northbound) and Localized Policies are applied at the LAN side (Southbound) of the WAN Edges.

Centralized Polices

These policies are pushed to vSmart from vManage and vSmart will push them to WAN edges.

In order to configure these type of policies, the vSmart should be configured via the vManage templates. Which means if it is configured only via the CLI while it was onboarded, you will have to reconfigure it using templates.

You will not see these policies in the running config of WAN edges but there are commands to view the pushed policies.

There are 2 types of Centralized Polices too.

1. Topology Policies (Control Policies)

2. Traffic Polices (Data Policies)

Topology Policies 

These are there to control the OMP protocol which is basically the routing updates which effects the routing tables. So if you want to do route filtering, change next hop of routes etc. you have to use Topology Policies under Centralized Policies.

Traffic Policies 

These are the policies which effects the data plane only. 

This can be used to alter data plane based on L3/L4 characteristics like source IP / destination IP type of things without effecting to Control Plane. Traffic Data Policies are used to configure local internet breakouts (Direct Internet Access / DIA).

When this is configured based on applications, it is called AAR (Application Aware Routing). In AAR; the WAN edge will look for the application and will override the routing table for that specific traffic according to the Policy configured. Note that it will not change the routing table but will change the way data is forwarded. It can be configured for SLAs with link quality etc. as well.

Configuring Centralized Policies?

You can configure them via Cisco vManage > Configuration > Polices > Centralized Policies

You can configure many Centralized Policies in vManage and There can be only one active Centralized Policy at a time. When you deploy one policy, other policies are deactivated..

There are 4 steps to configure a Centralized Policy.

1. Create Groups of Interest (Objects needed to configure a policy)

2. Configure Topology and VPN Membership (Topology Policy / Control Policy component)

3. Configure Traffic Rules ( Traffic Policy / Data Policy component)

4. Apply Policies to Sites and VPNs

You can bypass some steps if there is none to configure under that step. As an example, an AAR may not need to configure a Topology Policy hence the step 2 will be ignored.

Examples:-

Configuring AAR (Application Aware Routing) Policy in Cisco SD-WAN

Manipulating Traffic Flow using TLOCs in Cisco SD-WAN (Topology Policies)

Configuring Route Filtering using Topology / Control Policies in Cisco SD-WAN

Creating a Controlled / Flexible Hub & Spoke Topology using TLOCs

Configuring Direct Internet Access / Local Breakout in Cisco SD-WAN Edges

Localized Policies

These policies will be also configured in vManage but directly send to the WAN edges and they can be found in the running config in vEdges / sdwan running config in cEdges.

Used to configure QoS in local WAN edge, Configure ACLs or Route Policies for a local WAN edge etc.

Configuring Localized Policies?

There are 5 steps to configure a localized policy.

1. Create Groups of Interest (Objects needed to configure a policy)

2. Configure Forwarding Classes/QoS

3. Configure Access Control Lists

4. Configure Route Policy

5. Policy Overview

Examples:-

Configuring QoS in Cisco SD-WAN Edges by Localized Policies

======================================================================

About Groups of Interests / Lists

The components which are needed while configuring a policy are called Groups of Interests / Lists.

They can be configured before configuring policy as well as on the go.

Just by looking at the above lists you can get an idea of the things which can be configured under each policy type.

Figuring out the Exit Interface of an OMP Route in cEdges by Routing Tables

Let's start from looking into the configured VRF numbers through CLI by command show vrf

(click on the images to view in full size)

As we can see the; VRF 1 is configured in this router. Other 2 VRFs are default configured VRFs. So this VRF 1 is the only Service VPN we can see here which the OMP routes are learned.

Let's check the routing table of VPN 1 by following command,

show ip route vrf 1

In OMP (Overlay Management Protocol), there is this concept called TLOC (Transport Locator) to identify the hop and transport which the traffic should be forwarded to.

TLOC contains of 3 components;

1. TLOC IP (System IP of the Hop)

2. Color (the transport eg:- biz-internet, MPLS, etc)

3. Encapsulation Method

Let's analyze a specific route, 192.168.11.0/24, the next-hop is 10.1.1.111 which is actually the TLOC IP (System IP of the WAN edge router) which is not need to be routed from other WAN edges, just like a OSPF router id. So let's find the public IPs of the TLOC transports by the following command..

show sdwan omp tlocs | b 10.1.1.111

So to reach the TLOC IP of 10.1.1.111, there are 2 public IPs 172.16.1.1 and 10.10.11.1

Now let's check how those IPs can be reached through the default VRF which is actually the underlay VPN (VPN 0) of SD-WAN domain.

show ip route

So as you can see from the above output, the traffic will be load balanced between GE 1 and GE 2 interfaces.  

All above was done to resolve next hop IP and exit interface by examining routing tables. Following command will give you the same information at once and hope now you know how it is derived and that is nothing but the forwarding table.

show sdwan ip fib

Red box shows the next hop addresses of the route in the Service VPN (Overlay VPN).

To find the physical exit interface; 

show ip cef

Note that since AAR (App Aware Routing) in SD-WAN is defining the traffic forwarding in case it is configured. You can simulate to visualize the actual traffic flow in vManage GUI interface.

Figuring out the Exit Interface of an OMP Route in vEdges by Routing Tables

Let's start from show ip routes command in CLI.

(Click on the image to see in actual size)

You can see there are 2 VPNs (0 and 1) and several routes learned via static, connected, OSPF and OMP. All other routes except OMP are straight forward just like in normal Cisco IOS; either there is a next hop or else directly connected. 

In OMP (Overlay Management Protocol), there is this concept called TLOC (Transport Locator) to identify the hop and transport which the traffic should be forwarded to.

TLOC contains of 3 components;

1. TLOC IP (System IP of the Hop)

2. Color (the transport eg:- biz-internet, MPLS, etc)
3. Encapsulation Method

OMP routes are learned via a Service VPN only which in this case the VPN 1. Let's analyze a specific route, 192.168.22.0/24

So there are 2 TLOCs which the traffic should be forwarded to, which has the same TLOC IP but different transports. Which means this subnet is learned from these 2 transports from same WAN edge.

Now let's see how to reach this TLOC IP. 

The thing is that the TLOC IP is not need to be routed from other WAN edges, it's the System IP of the WAN edge just like a OSPF router id. So let's find the public IPs of the TLOC transports by the following command..

show omp tlocs | b 10.1.1.112

Now it's the time to look for the next hops in VPN 0 routes for the above 2 public IPs.

So the traffic is load balanced through the 2 interfaces.

All the above was done to resolve next hop IP and exit interface by examining routing tables. Following command will give you the same information at once and hope now you know how it is derived and that is nothing but the forwarding table.

show ip fib

Red box shows the next hop addresses of the route in the Service VPN (Overlay VPN) and Purple lines show the real next hop addresses in VPN 0 (underlay VPN) if any and the exit physical interfaces.

Note that since AAR (App Aware Routing) in SD-WAN is defining the traffic forwarding in case it is configured. You can simulate to visualize the actual traffic flow in vManage GUI interface.

If AAR is not configured, it will show the same result as we found from above CLI analysis.

Go to vManage > Monitor > Devices > Select the Device

Troubleshooting (left side)  > Simulate Flows under Traffic and enter the values.