05-22-2022 07:46 AM
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.
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:
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?
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.
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
Solved! Go to Solution.
05-22-2022 03:59 PM
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,
05-29-2022 04:58 AM
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:
Thanks
05-22-2022 07:57 AM
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.
05-22-2022 08:06 AM
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.
05-23-2022 03:13 AM
Thanks for the reply. Agree doesnt really make sense using loopback, am just trying to understand what the Cisco guides are suggesting and why.
05-22-2022 03:59 PM
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,
05-23-2022 03:10 AM
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.
05-29-2022 04:58 AM
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:
Thanks
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