EIGRP, dual DMVPN tunnels, and split horizon

[emailsbecker]

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.

[Georg Pauwen]

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.

[emailsbecker]

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.

[Cisco4Life]

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

[emailsbecker]

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.

[willwetherman]

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.

[emailsbecker]

Well, that's the thing.  Each of these routers does have a static route, and each has default-information originate under OSPF.  I should be able to get to any of our 10.x.x.x addresses.  I looked through all devices to confirm they all had default-information originate, and they do.  I did find one odd thing, but it doesn't seem related to the problem I'm seeing.  One box has this:

default-information originate route-map MAP

route-map MAP permit 10
match ip address 11
set metric-type internal

access-list 11 permit 10.1.0.0 0.0.0.255
access-list 11 permit 10.2.0.0 0.0.0.255
access-list 11 permit 10.3.0.0 0.0.0.255
access-list 11 permit 10.4.0.0 0.0.0.255

As I understand it, all this is doing is saying to OSPF, "Only advertise a default route if these 10.x.x.x addresses are in our routing table." The odd thing is ... those routes are static routes on this box. So they should always be in the routing table - unless we re-IP those blocks and remove the static routes in which case it would break routing in this market.  Like I said, not sure why they did this.

[willwetherman]

Yes that is correct. By referencing a route-map after the default-information originate command you are making the advertisement of the default route conditional, and in your case, the condition is the presence of any prefixes matching ACL 11 in the RIB. Static routes could be used for this. If the next-hop IP address for the static route was unable to be resolved, such as when the next-hop interface is down, then the default will be withdrawn. Perhaps this is what the engineer was intending?

Ok just so that I understand your configuration better, you are advertising a default route from the DMVPN spokes into the OSPF domain and then you have static routes configured on the DMVPN spokes for the 10.x.x.x networks with a next-hop IP address of the DMVPN hubs?

[emailsbecker]

No. Traffic gets from the markets to the Cisco in their market via the default route OSPF is advertising into the market. At the Cisco we have a static 0.0.0.0 pointing to the internet. No 10.x.x.x.x routes are being learned from the tunnels connecting to the hubs because of split horizon, the way they're currently designed only allows traffic from the hubs to reach the spokes.  Unknown traffic from the spokes gets sent to the internet where it dies. (Tracing my failing pings was how I discovered the problem.) 

I suppose one option would be to put in a static route for 10.0.0.0 0.0.0.0 pointing to the hub side of the DMVPN tunnels. Any 10.x.x.x address being redistributed into EIGRP by OSPF should be more specific routes. The static route should only be used if no more specific route exists.

[willwetherman]

Hi,

Ok that makes sense.

Yes, configuring static routes with a next-hop IP address of the DMVPN hub is one option. An alternate option, and probably the more preferred, is to configure the DMVPN hubs to advertise an EIGRP summary route to the DMVPN spokes for the 10.0.0.0/16 network.  This way you eliminate the need to disable split horizon on the DMVPN hubs and also reduce the redundant routing information that is advertised to the spokes.

Example

interface tunnel 1

ip summary-address eigrp [asn] 10.0.0.0 255.255.0.0

[emailsbecker]

Why would using the summary address command be better than having the hub advertise a route to 10.0.0.0 255.0.0.0?