SD-WAN segmentation through Label/VPN-ID

[bassomarco1998]

Hello everyone,

I have a question about how segmentation works in SD-WAN. I'm particularly having trouble understanding how OMP routes (vR) are distributed to the various vEdges (vE).

From the documentation, I've gathered that the association of Label-VPN ID is local to the vE. However, when a vE announces a vR (which includes the label), how does the remote vE know to which VPN to associate that route? To explain this further, I'll provide the following example:

Two vE announce their respective vR. In particular, vE-1 announces the network 10.1.10.0/24 (along with its label 1014 because it belongs to VPN 10). Now, when vE-4 receives the network 10.0.10.0/24, how does it know that it should associate it with VPN 10?

Thank you for your help.

[M02@rt37]

Hello @bassomarco1998,

The key to how the remote vEdge (vE-4) knows to which VPN to associate the route is the label carried in the route advertisement. Each vEdge has its local routing and label mapping table that associates labels with VPNs, and when a route is received, it checks this local table to determine the correct VPN association.

[bassomarco1998]

Hello,

thank you for the response. However, your reasoning doesn't make sense to me.

Let's consider the example of the image. vE-3 sends a vR for the network 10.0.10.0/24. Inside this packet, there will be the "label" attribute = 1014. If it were as you say, when vE-4 receives the vR, it would insert this network into the VPN associated with label 1014, which is VPN 30. This is obviously incorrect.

Could you explain your reasoning more clearly?

Thank you.

[Kanan Huseynli]

HI,

VPN-ID is part of vRoutes:

Also from config guide:

OMP routes advertise the following attributes:

**omitted**

• VRF—VRF or network segment to which the OMP route belongs.

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/routing/ios-xe-17/routing-book-xe/m-unicast-routing.html

Label is used by remote device to differentiate VPN service (can be prefix or service insertion), remote device sends user traffic with respective label and receiving router understands how to forward traffic in service side based on label in received packet (to do normal routing or to do service chaining e.g forward to firewall).

By the way, these services are also advertised in OMP as service route:

[bassomarco1998]

Hello Kanan, thank you for your response.

However, the explanation is still not clear to me. Within the vRoute, the "VPN-ID" attribute is also announced. But, how does the remote vE know the label to associate with this VPN-ID? If the information about the Label/VPN-ID association is stored only locally and sent to vSmart, how does the remote vE learn the Label to associate with a specific VPN-ID?

As M02@rt37 said (and as described in your first image) within the vR, in addition to the VPN-ID, there is also the associated Label. So when a vE receives a vR, it also receives this association. Is that correct? However, if I look for the received labels on the vE ("show omp services service VPN") or if I look for the received vRs ("show omp routes"), there doesn't seem to be any trace of the VPN-ID from the remote vE. It almost seems like it's not being received at all. Could you tell me how to view this information in the vE?

Thank you.

[Kanan Huseynli · Accepted solution]

Hi,

router sends vRoute update information to vSmart and vSmart distributes to other routers. So, not only local but also remote device knows VPN-ID/Label.

In VPN1 OMP RIB routes are with respective attributes. Example,

SDW01#sh sdwan omp routes vpn 1 10.0.0.0/8 detail
Generating output, this might take time, please wait ...

--------------------------------------------------------------------------
omp route entries for tenant-id 0 vpn 1 route 10.0.0.0/8
--------------------------------------------------------------------------
RECEIVED FROM:
peer 1.1.1.2
path-id 27099
label 1004
status R
loss-reason preference
lost-to-peer 1.1.2.2
lost-to-path-id 26997
Attributes:
originator 1.1.30.1
type installed
tloc 1.1.30.1, mpls, ipsec
ultimate-tloc not set
domain-id not set
overlay-id 1
site-id 30
preference 50
affinity-group None
region-id None
region-path not set
route-reoriginator not set
tag 400
origin-proto eBGP
origin-metric 50

I don't think that there is difficulty here. Router_A sends its routes in OMP update with VPN-ID/Label to vSmart. vSmart re-advertises information to Router_B, and now Router_B also knows about the route. It understand that route belongs to VPN-ID (which is in update) and it should use label for data traffic (which is in update).