MPLS with DMVPN backup

mannatech · ‎10-25-2013

Hello all,

We have a corp site (hub) and several spoke sites. We currently have two circuits at each site and have MPLS on one circuit and DMVPN as a backup on the other circuit. DMVPN uses EIGRP and MPLS uses BGP to advertise routes. The only EIGRP neighbor for all spoke sites is the hub.

If the MPLS goes down on a spoke router, that spoke router does not install a route in the routing table in order to reach another spoke router through a DMVPN tunnel. The reason for this is due to the fact that the hub router does not send EIGRP routes of spoke routers that have MPLS still up.

For example, spoke A loses MPLS and now needs to reach spoke B through DMVPN. It should get the EIGRP route from the hub, but the hub does not advertise spoke B's route since it has a BGP route (lower AD) in it's routing table for spoke B.

I can enter static routes on the spokes to force it to work, but I would rather use another solution. Is there a way to force the hub to advertise all the EIGRP routes to the other routers, w/o manually lowing the AD?

Thanks,

Tanner Thurman

Kelvin Willacey · ‎10-25-2013

My first thought is to redistribute BGP into EIGRP, so if the MPLS goes down then the external EIGRP routes should show up in the routing table via the DMVPN.

mannatech · ‎10-29-2013

If we redistribute the BGP routes into EIGRP, wouldn't EIGRP try to go over the same circuit that MPLS uses, or try to use the same gateway? The gateway for MPLS/BGP is the PE. The gateway for DMVPN/EIGRP is the other spoke's logical tunnel interface. Both MPLS and DMVPN uses different circuits on each router.

Here is an an example of the route table of the hub.

B 172.20.3.0 [20/0] via 172.20.1.1, 2w3d (MPLS)

D 192.168.8.0/24 [90/2818560] via 172.19.1.8, 4w2d, Tunnel0 (DMVPN, when MPLS is down)

Kelvin Willacey · ‎10-29-2013

No it won't. For instance, by redistributing BGP into EIGRP you are allowing Spoke A with a failed MPLS connection to know that Spoke B is now reachable through the tunnel interface back to the hub. The hub would already know how to reach Spoke B via BGP. I forgot to mention that it would have to be mutual redistribution in order for Spoke B to respond to Spoke A, unless you have some kind of default routing taking place over the MPLS circuit.

mannatech · ‎10-29-2013

That makes sense now. I see how that would work in a true hub and spoke environment. However, I believe I have conveyed our network topology incorrectly in the first post.

Our MPLS network is fully meshed. The DMVPN is a hub and spoke, but if a spoke A needs to reach spoke B, it will query the hub for the phyical address (NBMA) of spoke B to create a direct dynamic tunnel to that spoke. The tunnel will be formed but spoke A will not know how to reach the private IP addresses unless EIGRP propagates those routes from the hub to spoke A. Since spoke A MPLS is down, but spoke B MPLS is up, the hub will not send the EIGRP route to A since the BGP address to spoke B is in the routing table at the hub site.

I don't want spoke A DMVPN traffic going through the hub to reach the other spoke if I can help it. I want them to form a direct dynamic tunnel between the two and pass traffic.

Kelvin Willacey · ‎10-30-2013

I'm not too familiar with DMVPN but I believe the 'no ip next-hop-self' command will allow it to go directly to the spoke.

Vasilii Mikhailovskii · ‎10-26-2013

Hello.

I agree that idea to redistribute BGP to EIGRP would work.

At the same time, I would say that it's better not to announce specifics to spokes, but summary only (let's say 10.0.0.0/8 or even 0.0.0.0/0), in this case you won't need redistribution, as summary will always be in place.

Remember to configure your spokes as stub under EIGRP process.

PS: at the same time, if you don't need EIGRP convergence time (15 seconds and less) and will account BGP timers (30 sec minimum) acceptable, you night try to design your DMVPN with BGP - this will simplify your routing, as you will be using single protocol all over the network. Surely this could be accounted as overwhelming if your network is pretty simple and doesn't need flexibility (with multiple entry/exit points).