By this time, I’m sure you’ve all heard about the whole SD-WAN, or Software Defined Wide Area Network, craze hitting the industry. Heck, if you are reading this now, it probably means you are in the process of researching, piloting, or operating one yourself. This is great news! However, if you are looking for a high-level, marketing overview of the four pillars of an SD-WAN, then you are probably in the wrong place! In this article, I’m going to pass on some information from my personal experiences with one SD-WAN solution, Cisco IWAN.
The conversation here will mostly focus on Cisco’s PfRv3, otherwise known as the Intelligent Path Control component of Cisco IWAN (for you four pillar people still hanging around). As it turns out, PfRv3 is the driving force behind the design requirements for the DMVPN overlay network (pillar = Transport Independence…damnit, I said I wasn’t going to do this…). Being that this is the case, it is very important that those components are setup with PfRv3 in mind. Before we get there, let’s set the table with a really quick primer on why we want to use a technology like PfRv3 (and you do want to use it, you just may not know it yet!).
Why PfRv3?
We, as Network Engineers, love redundancy. We get off on it, it’s kind of our thing. We’d probably opt for a second Spouse too, if we could get the budget approved (..and if that sort of thing weren’t socially frowned upon). Anyway, we have been ordering redundant circuits from a diverse set of service providers for decades now – this is nothing new. We usually set them up with one as primary and one as backup (via our routing protocols). This provided predictable performance and automatic failover. Ah, life was good. Wait, was it? Try explaining to management about how you are paying an (often exorbitant) monthly fee to your backup service provider just in-case your preferred service provider fails. Oh, and you’re doing this at each of your 50 offices. Yikes! We need the redundancy, but at the same time, we need it to be more than an insurance policy. So, why PfRv3? It lets us intelligently place traffic onto our redundant link[s]. With PfRv3, we can define a policy, that overrides the routing table’s next hop information, to place the traffic of our choosing on a redundant link. So far so good, but you’re asking “do my users application experiences change when traffic is on the redundant link?”. The redundant link is often less expensive than the primary, and may be Internet-based, so this is a valid question to consider. PfRv3, in addition to allowing us to place certain traffic on a redundant link, allows us to measure and enforce performance policies on a per application basis. Simply put, if the application performance is degraded on the backup link, PfRv3 will move it to the primary link, if that meets the application performance requirements. This works both ways, so the lines between primary and backup as we’ve traditionally known them begin to blur a bit, to the point that we begin defining primary and backup on a per application basis with PfRv3. It can move traffic from your primary link to your backup link if the performance is measured to be better on the backup! It is this ability of being able to measure, analyze, and enforce the performance of your application’s traffic, that gives many companies a data driven strategy to ditch their overly expensive private MPLS circuits in lieu of commodity broadband Internet connections! This was all a long-winded way of saying that initially we want to use a technology like PfRv3 to increase the performance and return on investment in our existing WAN networks. In the long run, a technology like PfRv3 gives us the ability to drastically change the way we look at, and how much we pay for our Service Provider WAN circuits.
Why do I need DMVPN with PfRv3?
Now that the table has been set, here’s the nerdy bit. So why is PfRv3 dependent upon DMVPN? For a couple of main reasons; alternate next hop resolution from the routing protocol and GRE encapsulation (ok nerds, technically it is only the GRE encapsulation as it directly relates to DMVPN but I am lumping the routing protocol in with DMVPN too. Step 1: Take a breath. Step 2: Remain calm.).
Routing Protocol
PfRv3 needs to become aware of the alternate next hops, in order for smart probes (performance monitoring) to be sent out on the alternate path[s]. You may be thinking, “ok smart guy, how about we look at the RIB for this information? I’ll run whatever routing protocol I want”. In traditional WAN routing, you typically configure your routing protocols to make one of your WAN connections primary and one backup. Because PfRv3 relies on traditional WAN routing as a fallback under certain circumstances, this concept of primary/backup for your traditional routing protocol remains the same. So, as far as “I’ll run whatever routing protocol I want” goes…no, no you won’t. In order for PfRv3 to get this alternate next hop information, it has to be compatible with the routing protocol itself, as that is where that key piece of information (alternate next-hop IP) is stored. You will use EIGRP or BGP as your routing protocol, like a good little Cisco Network Engineer! PfRv3 does not have the ability (at this point) to glean this information from OSPF, or any other dynamic routing protocol.
GRE Encapsulation
Ok the routing protocol dependencies makes sense, I buy it. But what about the GRE encapsulation? This bit harkens back to the whole “Transport Independence” pillar (Dangit! I said I wasn’t going to talk about the pillars!). Remember that PfRv3 uses performance monitoring to ensure the quality of the application experience? In order to do that, PfRv3 needs to know that the Service Provider will forward the PfRv3 Smart Probes (the application specific, performance monitoring traffic generated by PfRv3 itself) the exact same way that it will forward the users traffic. We don’t want to give the Service Provider any granularity/entropy to treat our users’ application traffic any differently from our PfRv3 smart probes. The solution? GRE! When we use GRE encapsulation both for our smart probes and our user traffic, the Service Provider will always see the same source IP, source port, destination IP, and destination port! Oh yea, we’ll copy that DSCP/TOS value up to the GRE header too, don’t worry!
Well This Seems Complicated
You ready for the best part? Blue Pill/Red Pill time. You can take the Blue Pill and choose to forget everything I’ve written above by following a Cisco prescribed approach to deploying IWAN (PfRv3, DMVPN, QoS, etc..) using the “Easy Button” that is the Cisco IWAN App for their APIC-EM SDN Controller. For those that prefer the Red Pill like myself, these things are good to know, because the Devil in the details is always there, lurking. Even if you can’t see him (or her!). Either way, I think you’ll find the outcome well worth it! I hope that you’ll find this information on Cisco IWAN helpful, as we all journey into the world of SD-WANs together.
Written By: Dominic Zeni, LookingPoint Consulting Services SME - CCIE #26686
If you are interested in having LookingPoint install SD-WAN into your network, feel free to contact us here!
