where-do-you-want-to-move-complexity.html

---
date: 2017-06-05T09:27:00.000+02:00
tags:
- design
- WAN
title: Where Do You Want to Move the Complexity?
url: /2017/06/where-do-you-want-to-move-complexity/
---

<p>Michael Klose left an interesting remark on my <ahref="/2017/05/regional-internet-exits-in-large-dmvpn/"><em>Regional Internet Exits in Large DMVPN Deployment</em></a><em></em>blog post saying…</p>
<blockquoteclass="cite">Would BGP communities work? Each regional Internet Exit announce Default Route with a Region Community and all spokes only import default route for their specific region community.</blockquote>
<p>That approach would definitely work. However, you have to decide where to move the complexity.<!--more--></p>
<pclass="more">Before reading the rest of this blog post, I’d recommend you read <ahref="/2017/05/regional-internet-exits-in-large-dmvpn/">the original one</a>.</p>
<p>In my proposed design, the hub routers need to know which spoke routers reside in the same region, and use different route maps for in-region spokes. In Michael’s design the hub routers don’t differentiate between the spokes but you need different configurations on spoke routers.</p>
<p>There’s no right-or-wrong here. Michael’s design keeps the hub router configuration simple, but requires slight modifications to spoke routers. You might want to avoid that if you’re deploying a large network and want to unify the spoke configurations as much as possible.</p>
<p>My design assumes that you can split spoke routers into in-region and out-of-region groups on the hub routers. You could do that by using explicit BGP neighbors, or ACLs with dynamic BGP neighbors to classify spokes. You could make ACLs simple with a good addressing plan, which might then limit your growth (if you get too many spokes in one region).</p>
<p>Michael’s design makes it simple to move spokes between regions. Don’t even try to do that in my design without readdressing the spoke (you don’t want to deal with lengthy ACLs).</p>
<p>Which alternative should you use? How about the third way: building router configurations from a simple data model? Once you go down that path, you could stop caring about details I’m discussing in this blog post because it’s very simple to switch from one deployment model to another by changing the configuration templates. For more details, watch the <ahref="http://www.ipspace.net/Ansible_for_Networking_Engineers">Ansible for Networking Engineers webinar</a> (in particular the DMVPN Case Study sections and Using NAPALM with Ansible section).</p>
<p>Oh, and of course you could <ahref="/2015/06/software-defined-wanwell-orchestrated/">hide the complexity behind an SD-WAN façade</a>, or buy a controller or orchestration system that does that for your more traditional network from your favorite $startup or $vendor. Just keep in mind that you can’t avoid the complexity, you can only hide it (<em>abstract </em>tends to be the buzzword du jour).</p>