Need some input...

So this is work related, but also falls within the realm of CCIE knowledge. I've been pushing management to approve funding for a new project I want to undertake at work.

The current infrastructure for a service offering we have is about 12 years old. It's a site-to-site VPN to customer sites, we control the spokes.

The site looks like this.

Hub Router <--(ospf)GRE TUNNEL(ospf)--> Remote Spoke
Backup Router <--(ospf)GRE TUNNEL(ospf)-->|

This model is outdated in my opinion. We have somewhere around 400 spokes. So we are wasting about 4 potential IP addresses per site. Not to mention each site has it's own cryptomap, tunnel, own OSPF area.

I've been thinking about swapping to DMVPN (mGRE), as well as running HSRP between the primary and backup router so there will be the need for one one tunnel endpoint on the spokes. This would cut down on all the cryptomap lookups, as well as conserve IP addresses, and clean up the configs.

The downside is I cannot put each router into it's own OSPF area. 400 routers in a one stub area is a bit much. The only alternative I was thinking of would be switching to EIGRP and making each spoke a stub (I think OSPF would work good in this scenario.

Now I guess my question is, how well will DMVPN work in a 400 node setup? Would it be better for me to make 2 DMVPN tunnels, and distribute the routers across both of them? Just looking for some ideas to roll around in my head.

Find more posts tagged with

Comments

ITdude

Do the spokes need to access each other, too?

millworx

ITdude wrote: »

Do the spokes need to access each other, too?

No they do not need access to each other, in fact I prefer that they do not. That is one reason I was thinking about swapping to EIGRP, that way I can make them true stubs as opposed to sticking them all in one OSPF area. I would be limited with OSPF since there would be only 1 tunnel interface on the hub, thus only one area can be assigned.

reaper81

I'm no expert in the area but I wouldn't be worried about running 400 routers in the same area. I know service providers that run more than that in area 0 or a flat IS-IS topology. As long as your hubs are reasonably sized I think you should be OK.

Forsaken_GA

Well, I suppose whether or not 400 nodes in a single area is too many is largely dependent on your hardware, and how many networks you're dealing with. Unless you're actually running into a resource issue, or your links are unstable enough to force SPF runs enough to cause noticeable disruption, you're probably fine as is.

My hesitation with EIGRP is, and likely always will be, it's proprietary nature. It's too bad, as I think it's a pretty elegant routing protocol, but given the way market share has been shifting over the years, it's very hard to project a growth that guarantees nothing but Cisco gear in the routing infrastructure, and I don't think it's worth it to add additional points of complexity and failure via redistribution just to run a proprietary protocol.

millworx

Forsaken_GA wrote: »

My hesitation with EIGRP is, and likely always will be, it's proprietary nature. It's too bad, as I think it's a pretty elegant routing protocol, but given the way market share has been shifting over the years, it's very hard to project a growth that guarantees nothing but Cisco gear in the routing infrastructure, and I don't think it's worth it to add additional points of complexity and failure via redistribution just to run a proprietary protocol.

Thanks for the input Forsaken, fortunately for me Cisco eats it's own dog food, so no other vendors will ever be used. I think the initial reason we went with OSPF 12 years ago with this solution was this group was not originally owned by Cisco, also too there was some hesitation with having the links participating in our internal routing domain, which is also a moot point now.

As it stands now the hubs are 3800 series, current CPU utilization is at 54%

This all has given me some additional food for thought, and I appreciate the input.

Forsaken_GA

millworx wrote: »

Thanks for the input Forsaken, fortunately for me Cisco eats it's own dog food

Huh, yeah. Well, I guess that sure would remove any concerns about vendor interoperability.