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.
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.
Currently Reading:
CCIE: Network Security Principals and Practices
CCIE: Routing and Switching Exam Certification Guide
CCIE: Network Security Principals and Practices
CCIE: Routing and Switching Exam Certification Guide
Comments
-
ITdude Member Posts: 1,181 ■■■□□□□□□□Do the spokes need to access each other, too?I usually hang out on 224.0.0.10 (FF02::A) and 224.0.0.5 (FF02::5) when I'm in a non-proprietary mood.
__________________________________________
Simplicity is the ultimate sophistication.
(Leonardo da Vinci) -
millworx Member Posts: 290Do 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.Currently Reading:
CCIE: Network Security Principals and Practices
CCIE: Routing and Switching Exam Certification Guide -
reaper81 Member Posts: 631I'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.Daniel Dib
CCIE #37149 -
Forsaken_GA Member Posts: 4,024Well, 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 Member Posts: 290Forsaken_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.Currently Reading:
CCIE: Network Security Principals and Practices
CCIE: Routing and Switching Exam Certification Guide -
Forsaken_GA Member Posts: 4,024Thanks 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.