Just wanted to start off by apologizing from the ugly diagram. Didn't really feel like busting other the other laptop for Visio. It may be ugly but I hope it does the trick in terms of information.
Attached to this post I have a diagram that I hope can assist with my question.
Currently I have a DMVPN and MPLS design setup that has an OSPF connection between the DMVPN HUB router and my L3 Core switch. When the remote sites MPLS connection goes down the site advertises its local routes over the DMVPN and those routes are then advertised via the main site and out the MPLS with a lower BGP local preference and AS_PATH prepending.
This is a design I inherited and I can see a fundamental flaw in it. The problem is, on the remote branch side, if the connection between the L3 switch and the SP CE goes down the SP CE will learn the local routes from the remote branch via eBGP (AD 20). When the uplink between the L3 switch and the SP CE comes back online the SP CE will prefer to go back to the Main location and over the DMVPN. Thus all traffic destined to the remote site will route over the DMVPN.
Now, this has been addressed in the main site...when the routes from the local site are advertised via the Main site I mentioned I use local preference and path prepend...I prepend the originating AS_PATH onto it aswell as the AS of the main site. So when the route goes full circle and reaches the remote sites SP CE the route is discarded because the SP CE see's its own AS in the AS_PATH.
My question is....this isn't a really scalable design. For every site with a backup (DMVPN) connection I need to have a specific route-tag and route-map sequence to add in the local sites AS number into the AS_PATH.
Would it be a better design to change the DMVPN HUB router from a OSPF connection to the L3 core and setup an iBGP connection to my two (2) CPE routers at my main site? This would automatically put in the orignating AS and I would no longer have to manually set this. Looking for feedback on that....
The other question would be how everything else would work. Currently the CPE routers redistribute BGP into OSPF...so the Core switches have reachability to the other sites via the MPLS. I'm guessing I would just ensure that the DMVPN routes advertised to the CPE routers also redistribute into OSPF and into the Core Switches. Just ensure that those routes have a worse metric (OSPF = cost / BGP = Local Preference). Looking for feedback on that...
Any other design related feedback would be really appreciated.
>> Would it be a better design to change the DMVPN HUB router from a OSPF connection to the L3 core and setup an iBGP connection to my two (2) CPE routers at my main site? This would automatically put in the orignating AS and I would no longer have to manually set this. Looking for feedback on that....
I suggest to use also next-hop self from DMVPN-HUB to CPE routers in order to pass next-hop check on CPE otherwise you need to ensure that the CPE routers know all possible BGP next-hops.
The root cause is the fact the SP CE, that I guess is not under your control, does not prefer OSPF routes over BGP routes for IP subnets that are local to the remote site so then the link between the L3 switch and SP CE.
Actually it should prefer locally injected routes ( from OSPF to BGP) over routes learned over the eBGP session.
But it is not under your control you could only contact the SP tech people.
I'm guessing I would just ensure that the DMVPN routes advertised to the CPE routers also redistribute into OSPF and into the Core Switches. Just ensure that those routes have a worse metric (OSPF = cost / BGP = Local Preference).
you can take advantage of OSPF route type hierarchy:
O E1 routes are preferred over O E2 routes so CPE routers can inject routes using O E1 type and DMVPN route can use OS E2 type ( default).
Also you can have less specific routes over DMVPN ( if addressing plan allows for this) in comparison to routes learned/exchanged over the L3 MPLS VPN
if you can use less specific routes over DMVPN you have also a fix for the problem you are facing on the remote branches