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?
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)
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.
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.
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).
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...