cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
289
Views
2
Helpful
4
Replies

No BFD connection between mpls but biz_internet has bfd connectivity

nischal31
Level 1
Level 1

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:

Topology.png
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)bfdBR1.png

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.bfdBR2.png

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.

transl.png
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.

natt.png
natrans.png
For reference, I will show the same for biz-internet color.

biznat.pngbiznatt.png

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.

color.png 
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.

 

1 Accepted Solution

Accepted Solutions

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...

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/command/sdwan-cr-book/config-cmd.html#r_color_4875.xml

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.

 

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

View solution in original post

4 Replies 4

M02@rt37
VIP
VIP

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...

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

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

https://www.cisco.com/c/en/us/support/docs/routers/sd-wan/221734-configure-and-troubleshoot-sd-wan-networ.html

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.

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...

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/command/sdwan-cr-book/config-cmd.html#r_color_4875.xml

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.

 

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

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.