cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1499
Views
0
Helpful
10
Replies

EIGRP, dual DMVPN tunnels, and split horizon

emailsbecker
Beginner
Beginner

Here's the situation:

Multiple markets with non-Cisco devices that run OSPF.
Each market has one Cisco, with two internet connections from differnet providers.
Each site has two DMVPN connections (one for each internet connection).

Each remote site has a local VLAN with an SVI of 10.0.x.x in OSPF, and two DMVPN connections in EIGRP.
One DMVPN connection is in 10.1.1.x, the other in 10.2.2.x.

OSPF is redistributed into EIGRP, EIGRP is NOT redistributed back into OSPF.
All sites have one "network 10.0.0.0" statement under EIGRP.

Each remote site only sees the two main sites as EIGRP neighbors.
Both Main Site 1 and Main Site 2 are learning all routes via their Tu0 interfaces.
Due to split horizon neither main site advertises any routes to any other site.

There are some cross-market connections in the OSPF networks with static routes facing the Cisco routers.
These back channel connections are permitting some connectivity from remote office to remote office but it's not a full solution.
Due to EIGRP preferring internal routes I'm not too worried about the OSPF static routes if I turn off split horizon - but what about the dual DMVPNs?

If the main sites only had 1 DMVPN connection I would turn off split horizon only at the main sites. They'd be able to redistribute routes to the remote sites, the remote sites would be able to talk to each other but not advertise to each other. But because Main Site 1 and Main Site 2 both have TWO DMVPN connections would they loop?

If a remote site lost both internet connections both main sites would look at each other and say, "Hey, you had a route, right? Here, pass this traffic."

Could I turn off split horizon on only one of each main site's tunnels? Tu0 of Main Site 1 and Tu1 of Main Site 2? I'm not sure how to think this through.

10 Replies 10

Georg Pauwen
VIP Master VIP Master
VIP Master

Hello,

can you post a schematic drawing of your physical setup ? Are both main sites connected ? 

Also, if possible, post the configs of the main sites, as well as those of two spokes, so we can lab this.

Hi Georg,

I found some more information on DMVPN.  Based on what I'm reading here, I would say we're in Phase 1. The remote sites don't have the "tunnel mode gre multipoint" command, and none of the sites have "no ip split-horizon eigrp [asn]".

In discussing this with my boss I don't really think there's any need for spoke-to-spoke connectivity, so we can probably leave it like this, but it's good to know for future reference what we'd need to do in case we ever do need spoke-to-spoke connectivity.

So in regard to how I would do it if I needed ... it appears I could configure DMVPN Phase 3. However we have two DMVPN tunnels at each site, and I still don't know about how that would work with the no split horizon command required for Phase 2. The page I linked to above doesn't specify if we use the commands for Phase 3 in addition to the ones for Phase two, or instead of them. If the latter there might not be any problem with routing loops. I suppose I could lab it up and test.

I'm also curious about whether or not the two tunnels at each site being on different /24s would affect the potential for routing loops. I think them being on different /24s might eliminate switching loops but not routing loops. If Main Site 1 thinks Main Site 2 has a route to a remote site I don't think it matters if that route is via MS2's Tu0 or Tu1, and vice versa. So I think it could still form a loop, unless there's something I'm missing.

And yes, the main sites are also connected.  It's a dual-star topology, each star is on its own /24.

Hello-

I would configure the HUB & SPOKES as DMVPN Phase 3.  If you do not want the Spokes talking to each other, then you can apply a distribute-list inbound to filter out the remote spokes.

You would also only disable split-horizon on the tunnel interfaces.

With regards to routing loops.  It will not loop if properly configured and using EIGRP.  You can choose to set the tunnels up in an active/passive or active/active.  A you know EIGRP will do unequal cost routing; but if the connections are same speed even better as EIGRP will load balance your traffic.

I am curious as to why not redistributing back into OSPF..  fear of loop?

Thanks

Frank

Thanks for the response.  This was designed before I got here so I'm guessing, but they probably saw no need to redistribute EIGRP into OSPF because each market only had 1 path out (technically each Cisco has two internet connections but they still have to come through that one Cisco).  A default route is all that's needed, provided you know to connect to that market's Cisco to get to the device(s) you need access to, or have access to the one location where everything comes back to.

Since then markets have grown, and now some could be interconnected.  At that point we no longer need as many ways to get into the production network, but we'd need market-to-market routing.  I'm researching what needs to be done to make that work.

Hi,

Have you considered configuring EIGRP to advertise a default route from your hubs to your spokes instead of the advertising the spoke subnets by disabling split horizon?

As explained in the blog that you posted, DMVPN phase 1 builds hub and spoke tunnels whereby all traffic from the spokes is forced to transit the hub. As a result of this, it is inefficient to advertise the full routing tables to the spokes as each route will have the same next-hop IP address of the hub. By configuring EIGRP to advertise a default route to the spokes using command ‘ip summary-address eigrp [asn] 0.0.0.0 0.0.0.0’ under the hubs tunnel interfaces,  you eliminate the need to disable split horizon on the hubs and also reduce the redundant routing information advertised to the spokes.

Obviously this puts more load on the hubs but it will provide spoke-to-spoke connectivity without the need to

change to a DMVPN phase 2 or 3 design.

I hope that this helps.