MPLS TLOC not attempting to connect to vSmart controllers

[PatrickCavell85782]

What would cause a vEdge to NOT attempt control connections to vSmarts for an MPLS TLOC? I have max-control-connections set to default (unlimited). The LTE TLOC is making such connections but I don't even see the vEdge attempting to do so for the MPLS TLOC. Verified this via a tcpdump on the MPLS interface. We know the MPLS interface is up because it's established an OSPF adjacency with it's upstream neighbor. We've also confirmed the FW is not blocking any traffic. The MPLS interface has a static private (RFC1918 address).

I've done the same for another vEdge and its MPLS TLOC has made control connections to the vSmarts. The difference from the vEdge above is that the MPLS interface in this one uses DHCP.

Any ideas?

[inderdeeps]

Can you share the configuration for both the vEdges to compare. Did you add DHCP in feature template to work on vManage ? 

Regards

Inderdeep Singh

www.thenetworkdna.com

****RATE MY RESPONSE IF YOU LIKE MY REPLY***

[PatrickCavell85782]

Not sure if I can share. Will need to check. 

Curios, what do you mean by “Did you add DHCP in feature template to work on vManage?”.

[inderdeeps]

How you define DHCP for one vEdge ?

[PatrickCavell85782]

Not sure if this helps, but see below:

vEdge 100M that has vSmart control connections on both TLOCs:

- interface cellular0, color=LTE, uses DHCP

- interface ge0/4, color=MPLS, uses DHCP (RFC 1918 address), sits behind a FW

vEdge 100M that has vSmart control connection only on LTE TLOC:

- interface cellular0, color=LTE, uses DHCP

- interface ge0/4, color=MPLS, uses Static addressing (RFC 1918 address) & has OSPF neighborship to upstream router, sits behind a FW <-- this color doesn't seem to attempt to make control connections to vSmart (max-control-connections set to default); NOTE: this interface is up and can ping devices on the internet.

[PatrickCavell85782]

Additional interesting info regarding the vEdge whose MPLS interface will not set up a control connection to vSmarts:

Noticed we have asymmetric routing going on for VPN0 when we do a ping to 8.8.8.8 with the source interface being the MPLS link. ICMP echo request goes out the LTE link and ICMP echo response comes in via the MPLS link. When I do the same ping but use the LTE as the source interface both the requests and responses go over the LTE.

[PatrickCavell85782]

On further review I'm seeing load balancing outbound in VPN0 even when I specify the ping source to be the MPLS interface. Have 2 static default routes, one to LTE next hop and one to MPLS next hop. All response come back in the MPLS interface.

[Dgoswami22]

This seems like an interesting issue that you faced. When you mention having two static routes one to LTE and other on MPLS actually this will create issues as ECMP doesn't work in underlay.  So basically you will have only one tunnel actively working at a time. 

To create a proper set up you should actually have to remove tunnel source out of physical interface and create a loopback to use a as tunnel source. What it will basically allow you to do is have one static route that will be used as underlay and should allow tunnels over both colors. 

I am linking the below document that must be of help here

https://www.cisco.com/c/en/us/td/docs/solutions/CVD/SDWAN/cisco-sdwan-design-guide.html#LoopbackInterfaceTunnels