Yes, this is a valid design approach. TLOC Extension allows one SD-WAN device (e.g., C8300 Edge) to extend its transport reachability to another device (e.g., vEdge) when one of them has no direct transport access. This is useful when only one device has a transport link, and you want the second device to use it for connectivity.
We don’t currently have any lessons that deal with TLOC extension in an SD-WAN environment, however, you can go to the Member Ideas page below and make your suggestion. You may find that others have had similar suggestions, and you can add your voice to theirs:
In the meantime, the Cisco SD-WAN design guide is an excellent source for understanding how this feature works.
I had the same issue as Manoj - all bfd sessions between not the same colors (i.e. biz-pub, pub-biz) were down with 2 x static summary routes of 10.0.0.0/8. When changed to default routes 0.0.0.0/0 all good.
I would appreciate your comment on this as I can’t seem to find an anwser on the original question.
Thanks for revisiting the post issued by Manoj, you’re right, it wasn’t addressed. Since you reproduced Manoj’s results, this behavior can be considered confirmed.
Let’s see if we can break down and explain the reasoning for this behavior. You and Manoj observed partial WAN connectivity, and BFD sessions were down between different TLOC color combinations. The introduction of a default route seems to fix the issue. However, when using a static summary route, the issue persists and BFD remains down.
Without having performed the lab directly, I can share with you my thoughts about why this takes place. Let’s look at BFD in more detail. BFD relies on establishing a tunnel between the local TLOC and the remote TLOC IP. The BFD session cannot come up if there is no valid route.
Since BFD comes up with the default route set but not with just the summary routes, I would further investigate reachability when just the summary routes are used. Each color pair must have bi-directional reachability to the public IP (TLOC) of the other side. And this routing should be symmetric. Also, check to see if the IPsec SA is successful when just the summary routes are used. Since BFD uses that VPN, it could be that the VPN itself is not fully operational. Check these parameters and let us know how you get along in your troubleshooting.
I have investigated this furhter already and the only thing which could make sense is the asymmetric routing. As I have checked in SDWAN documentation, this indeed could cause BFD sessions to be down.
I think this explanation is good enough and I can’t seem to see any other reason anyways.