In this lesson, we will explore the concept of labels in Cisco SD-WAN. Labels are an essential part of the solution and are used for segmentation, route leaking, and service chaining. Most Cisco SD-WAN courses do not focus enough on the function of labels, and subsequently, many network engineers don't really understand where they fit into the solution.

VPNs and Labels

VPNs divide the Cisco SD-WAN network into different isolated layer 3 segments. Segmentation is an essential networking function these days as organizations want to keep different business verticals separate for security and compliance reasons. Additionally, security teams want to keep guests separate from employees separate from contractors. Application teams want to separate the front-end from the back-end from the database layer, and so on.

What is a VPN?

In the context of Cisco SD-WAN, a VPN is just a separate routing table on a node. All routes belonging to the same VPN are kept in the same routing table. All other routes, part of another VPN, are kept in another routing table, and so on. This technique provides the Layer 3 isolation between the VPN segments on a single node.

Okay, an interesting question then arises - if a router has multiple routing tables, how does it know in which routing table to make an IP lookup for each incoming traffic flow? 

On the service side of a WAN edge router, this is fairly simple - each service-side interface is associated with a VPN-ID in a one-to-one fashion. For example, interface ge0/2 is in VPN20, and ge0/3 is in VPN30. This tells the router - "When you receive traffic on interface ge0/2, make an IP lookup in VPN20's routing table. When you receive routing information from a routing peer on interface ge0/2, insert it in the VPN20's routing table." The layer 3 separation is pretty straightforward here.

What about the transport side, though? TLOCs aren't associated with VPNs. When a WAN edge router receives data traffic on an overlay IPsec tunnel, how does it know in which routing table to make an IP lookup? Well, this is where the LABEL comes into the picture.

What is a label in Cisco SD-WAN?

When a network administrator configures a new VPN ID on a WAN edge router, the router automatically associates the VPN ID with a LABEL. If we take figure 2 for example, when we configure VPN 50 on vEdge-1, the router automatically maps the VPN-ID 50 to the next available LABEL number  - for example - 1016. Then it advertises this VPN-to-LABEL mapping to vSmart via OMP. The Cisco vSmart controller maintains all VPN-ID to ROUTER-ID to LABEL mappings of all WAN edge routers.

We can check the VPN-to-LABEL mapping on a vEdge router using the show omp services service vpn command, as shown in the output below. You can see that vEdge-1 has associated VPN 10 with LABEL 1014, VPN 30 with label 1015 and VPN 50 with LABEL 1016.

vEdge-1# show omp services service vpn  

ADDRESS                                               PATH                      
FAMILY   VPN    SERVICE  ORIGINATOR  FROM PEER        ID     LABEL    STATUS    
--------------------------------------------------------------------------------
ipv4     10     VPN      1.1.1.1     0.0.0.0          66     1014     C,Red,R   
                                     0.0.0.0          68     1014     C,Red,R   
         30     VPN      1.1.1.1     0.0.0.0          66     1015     C,Red,R   
                                     0.0.0.0          68     1015     C,Red,R   
         50     VPN      1.1.1.1     0.0.0.0          66     1016     C,Red,R   
                                     0.0.0.0          68     1016     C,Red,R   

On the vSmart controller, we check the VPN-to-ROUTER-to-LABEL mapping of all WAN edge routers in the topology. Currently, for this example, only two vEdge routers are powered on (1.1.1.1 and 4.4.4.4), so you can see their label association on vSmart using the show omp services service vpn command as shown below.

vSmart# show omp services service vpn                                                     
                                                                      
ADDRESS                                           PATH                  
FAMILY   VPN    SERVICE  ORIGINATOR  FROM PEER    ID     LABEL    STATUS
------------------------------------------------------------------------
ipv4     10     VPN      1.1.1.1     1.1.1.1      66     1014     C,I,R 
                                     1.1.1.1      68     1014     C,I,R 
         10     VPN      4.4.4.4     4.4.4.4      66     1013     C,I,R 
                                     4.4.4.4      68     1013     C,I,R 
         30     VPN      1.1.1.1     1.1.1.1      66     1015     C,I,R 
                                     1.1.1.1      68     1015     C,I,R 
         30     VPN      4.4.4.4     4.4.4.4      66     1014     C,I,R 
                                     4.4.4.4      68     1014     C,I,R 
         50     VPN      1.1.1.1     1.1.1.1      66     1016     C,I,R 
                                     1.1.1.1      68     1016     C,I,R 
         50     VPN      4.4.4.4     4.4.4.4      66     1015     C,I,R 
                                     4.4.4.4      68     1015     C,I,R 

Notice an important aspect of labels - a label is a locally significant value on an individual WAN edge router. For example, notice that vEdge-1 associates LABEL 1014 with VPN-10, and vEdge-4 associates LABEL 1014 with VPN-30. There is no global LABEL assignment for the entire network by the centralized control plane. Further down in the lesson, we will talk about why a label isn't a globally significant value.

Labels in the Control-plane

Once a new VPN is created on a vEdge, the router automatically associates the VPN-ID with a locally significant LABEL. Then when a service-side interface connects to the site-local network, all routes learned via this interface are placed in the respective VPN routing table, and subsequently, advertised to vSmart with the LABEL id that represents this VPN on the router. If we take figure 3 for example, vEdge-1 associates VPN-10 with LABEL-1014. Then all site-local routes that are learned via interfaces in VPN10 are advertised with LABEL 1014 to vSmart via OMP.

The CLI output below shows how vEdge-1 advertises the VPN10's prefix 10.1.10.0/24 to the vSmart controller. Notice that it includes the LABEL-1014 that is associated with the respective VPN-ID 10. 

vEdge-1# show omp routes advertised detail 
---------------------------------------------------
omp route entries for vpn 10 route 10.1.10.0/24
---------------------------------------------------
            ADVERTISED TO:                   
peer    1.1.1.30
    Attributes:
     originator       1.1.1.1
     label            1014
     path-id          66
     tloc             1.1.1.1, mpls, ipsec
     ultimate-tloc    not set
     domain-id        not set
     site-id          1
     overlay-id        1
     preference       not set
     tag              not set
     origin-proto     connected
     origin-metric    0
     as-path          not set
     community        not set
     unknown-attr-len not set
    Attributes:
     originator       1.1.1.1
     label            1014
     path-id          68
     tloc             1.1.1.1, biz-internet, ipsec
     ultimate-tloc    not set
     domain-id        not set
     site-id          1
     overlay-id        1
     preference       not set
     tag              not set
     origin-proto     connected
     origin-metric    0
     as-path          not set
     community        not set
     unknown-attr-len not set

The label in the vRoute tells the vEdge routers that receive this route - "If you want to send me traffic to VPN 10 prefix 10.1.10.0/24, insert label 1014 in the data packets so that I can demultiplex them to the correct VPN routing table." 

Every OMP route (vRoute) in Cisco SD-WAN has a LABEL-ID that points to a next-hop router's VPN table. 

Labels in the Data-plane

We have seen that each OMP route (vRoute) in the control plane has a LABEL ID that points to the VPN routing table. When data traffic matches an OMP route, the router sends it to the next-hop tloc and inserts the label found in the route itself into the packets. 

Figure 4 shows an example of this process. Packets coming in from the service-side of vEdge-4 match an OMP route that points to vEdge-1's TLOC T2 and label 1014. vEdge-4 sends the data traffic to the next-hop tloc and inserts label 1014.

When vEdge-1 receives the data packets on TLOC T2, it first looks at the label value. The label 1014 tells the router to make an IP lookup into VPN 10's routing table. Then it matches the traffic to the directly connected subnet 10.1.10.0/24 and switches the packets in the respective interface.  

Notice an important concept - vEdge-4 doesn't know the vEdge-1's VPN-to-LABEL mappings (vpn-label mappings are locally significant to a single node), it finds the correct label in the OMP route that matches the data packets.

Why aren't labels globally significant?

Engineers often ask why are LABELs locally significant values and why each individual vEdge router keeps independent VPN-to-LABEL mapping? Why doesn't Cisco SD-WAN just use a globally significant LABAL ID for each VPN? Wouldn't it be easier to have label 1014 associated with VPN 10 on all vEdges? Then when we see label 1014 we will immediately know that this is VPN10 traffic, right? Looks pretty logical and straightforward at first, but it isn't.

Having locally significant LABEL-to-VPN mappings on each individual router makes the segmentation process stateless from vEdges' perspective. Figure 5 shows an example - when we configure a new VPN 60 on vEdge-1, the router associates VPN-60 with LABEL-1060 and advertise it to vSmart via OMP. Since every WAN edge router keeps only its own local VPN-to-LABEL mapping, all other vEdges don't need to be updated with this new VPN60-to-LABEL1014 mapping on vEdge-1. 

Having locally significant LABEL-to-VPN mappings allows the SD-WAN fabric to scale horizontally - adding more WAN edge routers and more VPNs doesn't affect the existing vEdges.

Labels used for Service Chaining

Labels play another very important role in Cisco SD-WAN. They are used to inject a network service into the path that specific users/applications take through the network. In this lesson, we will not go into great detail about the whole process of service chaining but will see how LABELs play a major role in gluing everything together. If you want to learn more about service chaining, you could check this lesson.

Service Chaining in Control Plane

The process of service chaining in the control plane can be broken down into three steps:

1. vEdge-1 advertises its attached firewall service to vSmart via OMP. The service is associated with locally significant label 1017.
2. vSmart knows that an FW service is available at vEdge-1 with next-hop tlocs T1, T2, and label 1017. The Cisco vSmart controller uses the FW service in an outbound control policy as a next-hop for routers matched by site-list X.
3. When advertising the OMP routes, the vSmart controller replaces the original next-hop of VPN10's vroutes with tlocs T1, T2, and label 1017.

Now let's see what happens in the data plane when the routers matched by site-list X send data traffic to the destination in VPN10.

Service Chaining in Data Plane

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.

In the example shown in figure 7 above, the vSmart controller will change the next-hop tlocs and the LABEL of all omp routes sent to routers matched by site-list X. Subsequently, when the routers send traffic in VPN10 they insert label 1017. When the traffic reaches vEdge-1 in the data plane, vEdge-1 looks at the incoming label first. The label matches its attached FW service, and the router switches the traffic directly to the FW service's next-hop address without making an IP lookup in VPN10's routing table.

Labels used for VPN Traffic Leaking

Labels play another significant role in the process of data traffic leaking between VPNs. Organizations often need to leak traffic between different VPN segments. A common use case is when an organization wants to provide a shared service to clients connected to different VPNs while at the same time making sure that the clients cannot access each other.