cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1573
Views
10
Helpful
6
Replies

SD-WAN BGP transport and DIA NAT using loopback address

sjhloco
Level 1
Level 1

Hi,

 

Am reaching out to see if anyone has any better information on these features as the Cisco documentation on both of them is pretty poor.

BGP for transport side underlay

The guides I have read seem to suggest that if you are using BGP to get your default route you should be using a loopback address for the tunnel interface and binding that to a physical interface. All the examples show this being done for MPLS rather than an Internet connections where you are learning a default route and advertising your PA address space. The tunnel interface does support allow service BGP but am assuming that as the default route is learnt over the tunnel interface it will send traffic over the tunnel rather than directly out to the Internet. 

 

I set this up as follows and it all works fine:

  • Physical interface is not a tunnel interface and has a BGP peering to the ISP over which it receives the default route and advertises our prefixes.
  • Loopback interface is a tunnel interface with an address from the PA address space and is bound to the physical interface 

So I was just wanting to get others opinion and make sure that I am understanding the documentation correctly and this is the correct way to configure this type of setup?

 

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/routing/ios-xe-17/routing-book-xe/m-unicast-routing.html

 

NAT DIA using Loopbacks

If DIA NAT is configured on the physical interface it will by default NAT the loopback tunnel interface along with anything else we use for DIA. I can get round this by adding a static one-to-one NAT for that 1 address as I dont like the idea of user traffic being on the same IP as our control traffic. Again looking through the Cisco documentation it is not clear at all, they suggest using a loopback address for NAT. The guide doesnt make sense, it tells you to create a pool on the physical interface and then on the loopback set "NAT Inside Source Loopback Interface"  as itself. 

 

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/nat/nat-book-xe-sdwan/configure-nat.html

 

I tried the following on a brand new loopback interface as well as on the loopback used as the tunnel interface but neither worked.

ip nat pool natpool-Loopback99-0 x.x.x.x x.x.x.x prefix-length 30
ip nat inside source list global-list pool natpool-Loopback99-0 overload
ip nat route vrf 100 0.0.0.0 0.0.0.0 global

interface Loopback99
 ip address x.x.x.x 255.255.255.255
 ip nat outside

There are no NAT translations done by this, where as if this is done on the outside physical interface NAT works fine

DC0-ASR-LAB01#show ip nat statistics 
Total active translations: 0 (0 static, 0 dynamic; 0 extended)
Outside interfaces:
  Loopback99
Inside interfaces: 
Hits: 0  Misses: 0
Expired translations: 0
Dynamic mappings:
-- Inside Source
[Id: 15] access-list global-list pool natpool-Loopback99-0 refcount 0
 pool natpool-Loopback99-0: id 9, netmask 255.255.255.252
        start x.x.x.x end x.x.x.x
        type generic, total addresses 4, allocated 0 (0%), misses 0

So like with the BGP problem, I have a configuration that works but am not sure if that is the best practise for this type of setup. Has anyone managed to get  NAT working using loopbacks, if so can you share how you accomplished this,

 

Thanks

2 Accepted Solutions

Accepted Solutions

Hi,

 

Your assumption is incorrect. BGP under tunnel interface is for underlay routing ,not overlay.  Normally, tunnel configured interface is hardcoded to be "SDWAN tunnel" and does not act as traditional L3 interface (e.g no transit routing can happen). To allow some protocols for different purposes related to underlay (e.g BGP for peering w/ ISP), you should enable that protocol by "allow" command.

 

Your setup is OK, but you may also have physical interface with tunnel configuration and BGP for underlay.

 

BGP as a routing protocol is supported both in the underlay to peer with CE routers or service providers and in the overlay on the service side to peer with routers at the local site.

Above statement is from cisco SD-WAN CVD.

 

Regarding NAT, could you clarify which config worked which didnt?

 

Regards,

HTH,
Please rate and mark as an accepted solution if you have found any of the information provided useful.

View solution in original post

I  tried out reconfiguring the transport-side so the tunnel interface was on the actual physical interface (rather than a loopback) with "allow service BGP" and everything works as expected. As this works it negotiates any need to look at NATs on loopbacks so problem solved

 

Thanks a lot for pointing me in the right direction Kanan, is just a pity that the Cisco documentation routing on the transport-side and NAT is so flaky, they could do with a rewrite now they seem to have settled down in terms of incorporating the Viptela and ASRs into this new SD-WAN solution.

 

So to sum up for anyone else doing the same and confused by the cisco documentation:

  • You can run BGP on the transport side in pretty much the same manner as you would traditionally, just make sure you allow service BGP on the tunnel interface
  • Using the loopback as the transport interface I think is more for situations where you would traditionally want the BGP peering between loopbacks rather than the physical interface
  • DIA NAT works pretty much same as traditional ASR NAT (look at the config when deploying) meaning it will NAT your control traffic by default as nat outside is applied on the physical transport interface. Therefore if you want to not NAT your control traffic add a static NAT statement on this interface with the physical IP as the source and translated address to act as a No NAT statement
  • I still haven't a clue what the documentation means or is trying to achieve in NAT on the loopbacks.

Thanks

 

View solution in original post

6 Replies 6

As i know hairpin NAT need to 

Config ip nat enable under loopback 

Ip nat enable is equal to both ip nat indide and ip nat outside.

Hi

 The underlay for SDWAN should be as simple as possible considering that usually this will be connecting a remote site through some ISP link either using Internet or MPLS. So, for underlay, most of time, a static route can do the job as the router have only  one ISP most of time. And you can use TLOC for redundancy through the second router.  I am considering here the most usuall scenario which a cEdge connected to a ISP and the  Overlay tunnel goes to  SDWAN Controllers.   Internet breakout to local Internet. But it also works for MPLS. 

 For NAT, when using DIA, I dont think using Loopback make sense  as Loopback usually is not used for internet connection but for Overlay tunnel connection.

 

 

 

Thanks for the reply. Agree doesnt really make sense using loopback, am just trying to understand what the Cisco guides are suggesting and why.

Hi,

 

Your assumption is incorrect. BGP under tunnel interface is for underlay routing ,not overlay.  Normally, tunnel configured interface is hardcoded to be "SDWAN tunnel" and does not act as traditional L3 interface (e.g no transit routing can happen). To allow some protocols for different purposes related to underlay (e.g BGP for peering w/ ISP), you should enable that protocol by "allow" command.

 

Your setup is OK, but you may also have physical interface with tunnel configuration and BGP for underlay.

 

BGP as a routing protocol is supported both in the underlay to peer with CE routers or service providers and in the overlay on the service side to peer with routers at the local site.

Above statement is from cisco SD-WAN CVD.

 

Regarding NAT, could you clarify which config worked which didnt?

 

Regards,

HTH,
Please rate and mark as an accepted solution if you have found any of the information provided useful.

Thanks for the information, I was wondering why it had the allow-service for BGP and OSPF if it wasn't meant to be done. I did try this out in a lab many months ago and seem to remember an issue with the the route being added but having no status (it should have been F,S for fib, selected). Will try it out again and see, makes more sense not to use a loopback unless is required.

 

In terms of NAT, I couldnt get the config I pasted working, so NATing using a loopback address. Only really trying as the config guide seemed to suggest to use it, it doesnt seem the best option as the public IPs are from one ISP so need to be tied to that. 

I  tried out reconfiguring the transport-side so the tunnel interface was on the actual physical interface (rather than a loopback) with "allow service BGP" and everything works as expected. As this works it negotiates any need to look at NATs on loopbacks so problem solved

 

Thanks a lot for pointing me in the right direction Kanan, is just a pity that the Cisco documentation routing on the transport-side and NAT is so flaky, they could do with a rewrite now they seem to have settled down in terms of incorporating the Viptela and ASRs into this new SD-WAN solution.

 

So to sum up for anyone else doing the same and confused by the cisco documentation:

  • You can run BGP on the transport side in pretty much the same manner as you would traditionally, just make sure you allow service BGP on the tunnel interface
  • Using the loopback as the transport interface I think is more for situations where you would traditionally want the BGP peering between loopbacks rather than the physical interface
  • DIA NAT works pretty much same as traditional ASR NAT (look at the config when deploying) meaning it will NAT your control traffic by default as nat outside is applied on the physical transport interface. Therefore if you want to not NAT your control traffic add a static NAT statement on this interface with the physical IP as the source and translated address to act as a No NAT statement
  • I still haven't a clue what the documentation means or is trying to achieve in NAT on the loopbacks.

Thanks