SD-WAN What is the relation between control-connections and OMP sessions?

[muthumohan]

Hello All,

I could not really understand how these two things, control-connection, and OMP sessions, are different? I know that the OMP sessions are established between the two "system-ips" and control connections are established from each TLCO on vEDGe to vSmart. Does this mean OMP sessions are established inside the control connections? 

When more than one control connection is established, then which control connection will the OMP session use?

Why is there a need to have more than one OMP session between vEdge and vSmart? What does this achieve?

If two control connections are there, will the OMP routes be advertised over both the control connections?

If two OMP sessions are there, will the OMP routes be advertised over both the OMP sessions?

You see where my confusion is coming from...

Any help would be appreciated.

Thanks,

Mohan

[elesani]

Control Connections (CC) are DTLS sessions established between different nodes (controllers and edge routers) of SD-WAN fabric.

OMP is the routing protocol used across Cisco SD-WAN Fabric. 

for a given Edge router, here is how the authentication/authorisation process kick-off:

• it will establish CC towards vBond controller seeking authentication towards the fabric
• vBond will redirect the Edge device to vManage and vSmart controllers after a successful authentication
• vBond will drop the CC to Edge router after successful CC establish in between vManage and vSmart controllers

There are two more items to mention yet:

• a given vEdge will establish a CC to a single vManage through only one Transport interface only - doesn't matter how many transport interfaces you have. 
• Edge router will establish a CC to maximum 2x vSmart controllers per Transport interface

It's best practice to have minimum 2x vSmart controllers within your fabric for High Availability (HA). In a scaled scenario, you might have more than 2x vSmart controllers, a given Edge router will establish a CC to only 2x of those vSmart controllers still. However, it will establish CC to each vSmart controller over every active Transport Interface. For example, if you have 2x vSmart controllers and 3x Transport Interfaces, you should expect to have:

• 2x CC per vSmart per Transport interface = 6x CC towards vSmart Controllers
• 1x CC towards vManage 

Now, OMP peering will be established between vSmart Controllers and Edge router. Consider OMP peering just like BGP peering and consider vSmart Controller as BGP Router Reflector.

OMP sessions will be established between Edge and vSmart controller only and won't be established from Edge to Edge (again like a BGP RR scenario) 

Multiple OMP sessions are for achieving HA. 

Hope it helped.

Regards,

Ehsan

[muthumohan]

Hello Eshan.

Thank you for taking the time to reply to my questions. Appreciate it. I am aware of most of the things you mentioned. But my questions is:

Say, you have 2 (or more) control connections between vEdge and vSmart (1 via MPLS and 1 via the Internet), but we still have only 1 OMP session between vE and vS. Is this correct?

If it is correct, which CC will the OMP session use? It picks one or it uses both? I know OMP is established between the system-ips of vE and vS, so just one CC should be enough. Then why more than one CC is needed? This is what is confusing me.

Thank you,

Mohan

[elesani]

Hi Mohan,

Yes, from a given Edge router only one peering per vS will be formed, but there are two facts here:

- by default, the control connection from Edge router towards vS is going to be an indicator if that interface can act as Transport Interface - unless you change this default behaviour, so that's one of the reasons behind the fact that you need one CC per-interface towards vS.

- Multiple established connection will bring HA into vS and Edge router OMP peering. As a result, the OMP peering will remain intact in case of link failure.

Hope that clarified it for you.

Regards,
Ehsan

[muthumohan]

Hi Eshan,

I appreciate your quick reply. Thanks.

Please refer to this link below:

https://community.cisco.com/t5/sd-wan/viptella-sdwan-question-about-private-mpls-transport-interface/m-p/4069362

Here, the MPLS connected transport on both vEdges does not have connectivity to the controllers. Does this mean that both vEdges will not advertise the MPLS TLOCs to vSmart? If so, how then IPSec will be formed over MPLS links? I also saw somewhere that you can use "max-control-connections = 0" so that Control connections are not attempted from those transport interfaces, but still will be advertised via other transports (say Internet) to vSmarts, so that IPSec can be formed over MPLS, even though the MPLS transport does not have connectivity to the controllers. This is actually my original question.

Once again, I thank you and appreciate your replies. 

Regards,

Mohan

[elesani]

Hi Mohan,

So, TLOC of the transport interface will be advertised towards vS only if a CC has been established over that interface in between vE & vS. this behaviour can be overwritten by turning off control connections on that transport interface through Feature Template: (max-control-connections=0) - on MPLS interface in your case, as a result, vE will advertise TLOC for your MPLS interface to vS and IPSec tunnels can form using that interface.