DMVPN EIGRP redistribution into OSPF

[RYAN BARNES]

Just throwing some possible design configurations around. Anyone have any input as to the best way to attack this?

http://www.cisco.com/warp/public/105/dmvpn.html#dualhubdual

Assume however that Hub-1 and Hub-2 are not co-located, and are seperated from the internal network by FW's. This would require either a GRE tunnel or BGP to support dynamic route updates to the internal network for failover purposes.

Add to that, OSPF running on the internal network. From what I can figure, the benefits of running EIGRP for path selection will be removed if redistribution is required into OSPF. Am I correct in assuming this? I would have to manually seed the OSPF metric which would kill off any dynamic preferance potential I had tinkering with my delay and offset metrics in the EIGRP DMVPN cloud. I think BGP would also give me the same issues w/ redistribution.

I think my only other option might be to give up the load balancing ability and run OSPF native using one hub as the primary and the other as a backup.

Any thoughts?

[ruwhite]

If you run a GRE tunnel between the routers, you'll be bypassing the firewalls (the traffic will follow the same path as the routing updates), so I'm not certain that's the best solution (depends on your requirements, though). You could run iBGP, but you're correct about losing the original metrics. Of course, iBGP itself can load share over multiple equal cost links. It can also load share over multiple unequal cost links using the bandwidth dmz feature, if that would fit into your network design:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guide09186a008012db46.html

"The BGP Link Bandwidth feature allows a BGP speaker to send traffic over two iBGP or eBGP learned paths where the traffic that is sent is proportional to the bandwidth of the links that are used to exit the autonomous system."

You could also try using an eBGP link, and setting the med to the IGP cost, but you can't pull the MED back into the IGP cost on the other end--especially with EIGRP, since BGP won't carry the component metrics EIGRP uses. Redistributing into OSPF will also blow your EIGRP metrics, yes, and OSPF won't unequal cost load share anyway.

Since you can't do a multihop EIGRP neighbor (yet, we've been talking about this for some time), it seems to me the two best bets are going to either skip the load sharing or work through some hack with BGP to make it work.

:-)

Russ.W

[RYAN BARNES]

Thanks Russ. Helpful as always.

I think I'll toss my dream of loadsharing, since it doesn't seem to me (and you apparently) that there is any good way to make this happen.

Good call on the GRE. For some reason that didn't occur to me that the traffic would also follow the same path.;-p

Essentially my options appear to be the following.

Run EIGRP in the DMVPN cloud. Redistribute to iBGP o n the Hub router, run iBGP across the FW to an internal router. Redistribute from iBGP to IGP (EIGRP/OSPF). This would require some massaging of the redistributed metrics to ensure I have no asymetric routing w/ failover.

Second options is to run eBGP across the FW. Redistribute EIGRP DMVPN routes into eBGP, eBGP across the FW, then redistribute from eBGP into OSPF/EIGRP. I could then adjust the MED value to have my DMVPN "prefer" a particular Hub router when communicating to my internal network.

If I've gotten that even remotely close, I'll dig up some more docs on BGP and get reading. Know of a good crash course advanced BGP book?

Thanks again.

[ruwhite]

Either option sounds fine, but remember to turn on iBGP ti IGP redistribution if you use iBGP. It's not on by default.

As for a crash course in BGP--the little Addison Wesley Networking Basics book is the best intro I know of. For design work, be patient, Addison-Wesley and Cisco Press are both coming out with books around July, I think. I'd tell you to get the Addison-Wesley book (Practical BGP, the title should be), but I'm prejudiced, since I'm one of the authors. :-)

:-)

Russ.W

[RYAN BARNES]

One last stupiud question. If I am bringing an iBGP route into my network at two seperate points, I will be running iBGP between those internal routers to determine best path to that external network. Fine for those routers running iBGP. But I am not running BGP on any other internal routers.

My last quibble with this is the best attack to redistribute. Is the best plan to redistribute from iBGP into IGP. From only one router? I want to redistribute from two (one at each location for redundancy), but then I run into problems with the IGP redist. route trouncing my other BGP route. With eBGP this doesn't appear to be a problem due to the admin distance being lower than the IGP distance. I suppose I would need to maintain an ACL to filter these routes inbound on my redist. routers to ensure they don't pick up each others redistributed IGP route.

[ruwhite · Accepted solution]

"If I am bringing an iBGP route into my network at two seperate points, I will be running iBGP between those internal routers to determine best path to that external network. Fine for those routers running iBGP. But I am not running BGP on any other internal routers. "

Yes, this is correct, and exactly what syncrhonization was designed to force you to solve. :-) If you are redsitributing into your IGP, this won't matter, will it, since all the routers will have the routes in question? For the routes they don't have, they should just have a default, I would think.

As for the best way to redistribute.... I would use tags in the IGP to block the routes from coming back into BGP once they've been redistributed into the IGP. It's a lot easier than filtering based on prefix and such. Both EIGRP and OSPF can do tags.

http://www.cisco.com/en/US/tech/tk365/tk207/technologies_tech_note09186a008009487e.shtml

http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guide09186a008012db77.html

Are two good sources of information on tags. Filtering on the inbound side based on the tags will solve your iBGP/IGP admin distance problem, as well, though it will leave your border (redistributing) router without a route if it loses its iBGP route (which really shouldn't be a problem, since the other routers in the network will point to the remaining redistribution router with a route). If you have local networks attached to one of the redistributing routers, you'll need to filter based on the tags in the redistribution, and then set your admin distances so the iBGP route wins (though, as I recall, there's some wierdness here in the order of operation that may not make that so easy as just changing the admin distance, but I don't remember all the circumstances off the top of my head).

I hope all of that makes sense.

:-)

Russ.W

[RYAN BARNES]

Yep. Figured I might have to do filtering...Thanks for all the assistance.

Cheers,

Ryan