Building Network Automation Solutions
6 week online course starting in September 2017

Regional Internet Exits in Large DMVPN Deployment

One of my readers wanted to implement a large DMVPN cloud with regional Internet exit points:

We need to deploy a regional Internet exits and I’d like to centralize them.  Each location with a local Internet exit will be in a region and that location will advertise a default-route into the DMVPN domain to only those spokes in that particular region.

He wasn’t particularly happy with the idea of deploying access and core DMVPN clouds:

Looking at various design documents, they lead you to a hierarchical setup but I would like to look at your webinar if it discusses DMVPN setup in a similar manner.

The easy answer first: no, my DMVPN webinars don’t discuss such a setup. It’s a routing challenge and has nothing to do with DMVPN. It does help though if you understand how DMVPN works and how you should use routing protocols across DMVPN, and that is definitely covered in the DMVPN webinars.

Now for the interesting part.

Assuming the regional locations are DMVPN hub routers you could use (at least) two designs to get the desired traffic flow:

Multiple DMVPN access clouds (one per region) with another DMVPN cloud linking the hub routers. Hub routers would advertise default route into their region, but not between hubs. Alternatively you could exchange default routes between hubs for inter-hub redundancy.

The diagram is highly simplified. In real life you’d have at least two hub routers in ever region, and two DMVPN access networks (one over Internet, one over MPLS/VPN, or using two different ISPs) for redundancy.

The “only” drawback of this setup is suboptimal inter-region spoke-to-spoke traffic flow. Without special tricks (NHRP shortcuts across multiple DMVPN clouds) the traffic would flow through two hub routers to reach a spoke in another region.

Routing tricks – while using a single DMVPN subnet the hub routers advertise default route to in-region spokes but not to other spokes (or low-cost default route to in-region spokes and high-cost default route to other spokes). This is clearly impossible to do with OSPF, and pretty hard to do with EIGRP. BGP would be my preferred routing protocol in this case.

Are you faced with a similarly intriguing challenge? Check out ExpertExpress or buy it with Professional or Team subscription (so you won’t have to ask your boss for the expense approval twice).

Finally a note for SD-WAN aficionados: before you tell me how much easier this would be with your preferred SD-WAN solution, do remember that an SD-WAN controller is functionally equivalent to a BGP route reflector. It’s just that the route propagation functionality is hidden behind a GUI fa├žade.

5 comments:

  1. Nice post.

    I'm pretty sure I missed something and I saw the DMVPN condition. But I'm studying about a LISP solution. Would it be possible to solve it with LISP? Do you have any experience with LISP and security?

    ReplyDelete
    Replies
    1. In principle, yes. In practice, I haven't worked enough with LISP to answer.

      Delete
    2. Thanks for your fast answer. Doing more LISP is on my bucket list. Maybe I will have some time to do some labs.

      Delete
  2. Just an idea, would it work with BGP Communities? Each regional Internet Exit announce Default Route with a Region Community and all spokes only import default route for their specific region community.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.