This lab example will show how Cisco SD-WAN Service Chaining works. We will ensure that the VPN1 traffic between spokes (vEdges 3 - 6) goes through a centralized firewall located in the data center, as shown in figure 1. The overlay topology is already hub-and-spoke after the previous lab lessons.

To meet the objective of this lesson, we will define a new firewall service on vEdge-2 and advertise it to vSmart via OMP. Then we will modify the outbound control policy applied to the spokes so that the traffic between the spoke routers is automatically redirected through the FW service.

What is Service Chaining?

In the context of Cisco SD-WAN, service chaining means injecting a network service such as a firewall into the path of specific data traffic in an automated manner.

These days, it is very common for an organization to inject a network service into specific traffic paths across the WAN. For example, a typical use case is to redirect remote traffic through a security device such as a firewall, IPS/IDS, or a web proxy located in a centralized data center or a regional hub.

Another typical example would be to redirect traffic through a load balancer, caching engine, or a WAN optimizer. Regardless of the type of service, the SD-WAN solution natively supports the advertisements and deployment of network services using the Cisco OMP protocol. 

The key differentiator of Cisco SD-WAN's service insertion process is that it is very flexible and fully automated. For example, injecting a firewall in the path of specific traffic is typically associated with tons of manual box-to-box configuration in a traditional WAN environment. In contrast, Cisco's process is as simple as matching interesting traffic with a control policy, setting the firewall service as a next-hop, and then applying the policy to all necessary sites with a single NETCONF transaction.

Service Chaining Workflow

Before we jump into the configuration section, let’s break down the process of inserting a network service into steps and illustrate them in figure 2:

1. vEdge-2 advertises an attached firewall service to vSmart via OMP. The service is associated with label 1009.
2. vSmart knows that an FW service is available at vEdge-2 with next-hop tlocs T21, T22, and label 1009. The Cisco vSmart controller uses the FW service in an outbound control policy as a next-hop for the spokes’ vroutes.
3. The vSmart controller then replaces the original next-hop of the spokes’ vroutes with tlocs T21,T22, and label 1009. Notice that the service routes themselves are not advertised out by vSmart.
4. The spokes' vEdges then insert label 1009 into all packets destined to other spokes and send them to vEdge-2.
5. This step is key to the whole service chaining process - when a WAN edge router receives a packet, the packet’s label determines the lookup context. If the label points to a VPN service, the router performs an IP lookup on the destination IP found in the header. If the label points to a network service, the router does not do IP lookup but instead directly switches the traffic to the service IP address.

Configuring Service Chaining

The first step in inserting a new network service in the SD-WAN domain is always to define the service itself. In our lab example, we will configure a new firewall attached to vEdge-2. The configuration is as simple as defining the type of service (FW) and its IP address (10.1.50.50). However, keep in mind that the network service must be layer 2 adjacent to the WAN edge device. 

vEdge-2# conf t
Entering configuration mode terminal
vEdge-2(config)# vpn 1
vEdge-2(config-vpn-1)# service FW address 10.1.50.50 
vEdge-2(config-service-FW)# commit and-quit
Commit complete.

Once the service is configured, the router starts keeping track of its liveliness using ICMP pings. Then the vEdge associates a LABEL with the network service and advertises it to the vSmart controller using an OMP service route. Note that in our example, it has generated the label 1009. 

vEdge-2# show omp services vpn 1
C   -> chosen
Red -> redistributed
R   -> resolved

ADDRESS                                               PATH                      
FAMILY   VPN    SERVICE  ORIGINATOR  FROM PEER        ID     LABEL    STATUS    
--------------------------------------------------------------------------------
ipv4     1      VPN      1.1.1.2     0.0.0.0          66     1004     C,Red,R   
                                     0.0.0.0          68     1004     C,Red,R   
         1      FW       1.1.1.2     0.0.0.0          66     1009     C,Red,R   
                                     0.0.0.0          68     1009     C,Red,R  

Once the vSmart controller receives the service route, it uses the next-hop tlocs and the associated label to manipulate the OMP routing in such a way that specific traffic gets redirected through the network service. However, it is essential to remember that the vSmart controller never advertises service routes.