04-07-2025 07:39 AM
Hello all,
I was studying for ENSDWI exam and doing some labs. I came across this strange issue where BFD connection is not forming between MPLS and MPLS connections but forms with biz-internet colors. I will try to break down the scenario, issue and what I've found so far and where I need help with.
Scenario and topology:
1) I have 2 DC sites and 3 branch sites. I've attached the network diagram. So according to diagram TLOC is extended between BR1-1 (Internet extended from BR1-2) and BR1-2 WAN Edges (MPLS-extended from BR1-1).
2) Control connections works fine (both transports) and I can ping the transport network from the WAN Edges across all sites.
3) NAT is enabled on transport interface (Not enabled on TLOC extension interface).
4) biz-internet color which was extended from BR1-2 works fine and has control and BFD tunnels all "up". (Picture attached)
The problem
So, in BR1-2 , mpls color is not establishing bfd connectivity with all sites on mpls color. But the same mpls color is establishing bfd sessions with other transport color as seen on the picture.
What I've found and noticed
During troubleshooting, I went into one of the branch router and that tloc extended IP (10.51.1.2 and 10.61.1.1) was translated and reflected as the transport IP. What I've meant by this is 10.51.1.2( interface address of BR1-2) is tloc extended IP for biz-internet color and it was translated to biz internet IP public IP address of 209.165.201.5 (interface address of BR1-1) .
But for mpls to mpls color, the MPLS tloc address 10.51.1.2 (interface address of BR1-2) is supposed to be translated the same way as biz-internet to appear as 192.168.20.5 in bfd sessions tab but instead shows MPLS tloc address.
What's more strange is when I check the nat translation table, it shows it is translated. The ports in translation table and on the bfd sessions are higlighted in the picture below.
For reference, I will show the same for biz-internet color.
Now, the strangest part, if I changed the color of mpls to something else. For instance, I changed to green and view bfd sessions, voila it works!! on the same configuration and same IP.
Now my question is , is this normal behavior that tloc extension of mpls does not form a bfd session with other mpls transport if NAT is applied. It came to a thought in my mind that in theory sd-wan assumes that NAT is not required on mpls connection. I will really appreciate the help from experts here in the strange situation. Apologies to anyone who might find it too long to read but I am still finding any information regarding this in documentation page.
Solved! Go to Solution.
04-07-2025 09:38 PM - edited 04-07-2025 09:43 PM
Hello @nischal31
Use a custom color (custom 1). It should tricks SDWAN into treating the path as NAT-sensitive and engage NAT traversal logic to make BFD and control tunnels work...
Also, for the test ensure that restrict keyword is not added on your color command. It can silently block BFD sessions from forming if the remote site doesn’t have a TLOC with exactly the same color, which makes troubleshooting confusing—especially when everything else (NAT...) looks fine.
04-07-2025 10:05 AM - edited 04-07-2025 10:05 AM
Hello @nischal31
Thanks for that detailed use case.
From my point of view, avoid apply NAT on MPLS TLOC extensions. Let the MPLS underlay carry the private transport IPs natively across sites. Because the SD-WAN fabric assumes MPLS = private = no NAT. BFD expect to see the original, untranslated IP.
If NAT is unavoidable, don't use the reserved “mpls” color. Use a custom color instead. This allows SDWAN to treat the link as if nat is expected, avoiding the "bfd mismatches" you're seeing...
04-07-2025 11:56 AM
M02@rt37 Many thanks for taking time to read and answer to the problem I am facing in this scenario. I saw guides and docs with scenario like this , for example here
where they advise to advertise the TLOC extension subnet which in this case is 10.51.1.0/30 to the MPLS SP via routing protocol which in real world is understandable. By the thanks for clarifying MPLS=no NAT part , that was really helpful.
In my eve-NG lab, the MPLS network I am using is a private cloud and I connected to boarder router which connected Internet , LTE and MPLS transports. I guess I have to run BGP and advertise 10.51.1.0/30 subnet there to replicate the real world scenario or use another non-private color for time being like you said. I was also wondering, if there is any workaround apart from changing color or advertising the TLOC extension interface subnet to MPLS provider to override the default behavior of natting on MPLS transport to not form BFD session ?
Thanks again for reply.
04-07-2025 09:38 PM - edited 04-07-2025 09:43 PM
Hello @nischal31
Use a custom color (custom 1). It should tricks SDWAN into treating the path as NAT-sensitive and engage NAT traversal logic to make BFD and control tunnels work...
Also, for the test ensure that restrict keyword is not added on your color command. It can silently block BFD sessions from forming if the remote site doesn’t have a TLOC with exactly the same color, which makes troubleshooting confusing—especially when everything else (NAT...) looks fine.
04-07-2025 09:46 PM
Thank you very much for your detailed answer. I am accepting your answer as a solution unless apart from changing color there are way to override this behavior.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide