The blog I was going to post today was a blog about how PfRv3 (IWAN’s Intelligent Path Control) utilizes the GRE tunnel of the DMVPN underlay in order to make intelligent decisions about where to send business critical traffic based on knowledge of the health of the path that business critical traffic would take. …… But then I started realizing that while I have dug into a lot of DMVPN stuff recently on Networking With Fish…. I have not even really touched Intelligent Path Control. So……. let’s take a giant step backward.
Intelligent Path Control
Intelligent Path Control at the WAN – what can it do for you and why do you want it? In this blog I’m not going to try to be the definitive all encompassing guide of what all Intelligent Path Control is…. just enough to get us a little on the same page before we start playing in the lab together with it in future blogs.
The picture above is of a typical 1 router branch location with 2 WAN connections. One WAN connection is the primary and the other one sits there, unused, as just a backup … doing nothing unless the primary link or path completely go away. That was good enough yesterday. But not today. Not anymore.
Brownouts and Business Critical Traffic
What if the primary link doesn’t actually fail? What if it, instead, experiences brownouts? Impairments along the path like delay, loss or jitter? Impairments you would like to know about so that you can send your business critical traffic out the backup WAN link until the impairments on your preferred primary go away.
How might we learn about impairments along the actual path your business critical traffic is taking? What can we use as a health check for this path? Maybe you are thinking we could use some simple IP SLA that checks the end to end generic health between your two WAN router endpoints? I’d have to point out that this idea makes a pretty large assumption. You are assuming that this simple IP SLA between your two WAN router endpoints will be sent via the same exact path as your critical traffic. This may very well not be the case. One such example might be that your MPLS provider is sending your high priority business critical traffic (EF, AF41) over one path and your best effort (AF11, 0) over another. Other examples are load sharing hashing algorithms that are used in ECMP and port channeling environments.
Business critical traffic is…. well…. critical. So we really need to know the health of the underlying path that it takes and make intelligent decisions at the WAN edge. This is a key thing that IWAN’s Intelligent Path Control will be doing that for you. How does it do it? More on this in a future blog.
Increased WAN Bandwidth Needs
I talked with a customer recently that had 10 branch locations. They were explaining to me that their WAN bandwidth usage had almost tripled in just over 2 years. Obviously you can imagine that they were really looking for a way to start using that backup link.
How did that happen? How did their branch WAN utilization almost triple in just 2 years? I didn’t ask them. But I can just see someone thinking “Ooooo…. I have an idea. Let’s save money by just putting everything on the cloud – Microsoft Office 365…. Google Docs“. Then just stopping there with the idea and implementing it and not looking at whether or not the WAN links to the branches are ready to support this without potentially impacting business critical traffic. Okay.. that is me clearly on my soapbox. Small pet peeve of mine – not thinking decisions through. Okay.. off the soapbox! Admittedly, we do all know that moving stuff to the cloud is not the ONLY reason for the increase of WAN bandwidth needs at the branch.
Bottom Line? – WAN bandwidth needs at branch locations is increasing…. increasing… and increasing. We have quickly entered into a situation at our branches that WAN bandwidth needs are pushing us to no longer have that link as just a backup. But to use it.
So Why Not Just Go Active/Active with Equal-cost multi-path (ECMP) Routing?
So if we want to start using that backup link actively… why are people turning to IWAN? I mean… why not just go active/active by turning on equal-cost multi-path routing? Send traffic over both links?
- Business Critical Traffic and Avoiding Brownouts – ECMP doesn’t help with intelligent path control at the WAN edge in reference to learning about and avoiding impairments (delay, loss, jitter) along the path that business critical traffic might be taking.
- Traffic Control – ECMP doesn’t help with allowing you to control what traffic goes where. It is very possible, if not likely, that if your primary is MPLS and your backup is Internet… you are probably going to want to have your business critical traffic (EF, AF41, AF31) going over the MPLS link where you are paying for some level of quality of service from your MPLS service provider. ECMP won’t provide this for you.
- Load Balancing – ECMP doesn’t help you if your two links are different bandwidths and you want to take advantage of that.
IWAN stands for Intelligent WAN — bringing intelligence to the WAN edge. Intelligence like Intelligent Path Control which can help you with not only utilizing that backup link… but doing so with a level of intelligence that “begins with the end in mind“.
- Business Critical Traffic and Avoiding Brownouts – Intelligent path control at the WAN edge. Learning about and avoiding impairments (delay, loss, jitter) along the path that business critical traffic takes.
- Traffic Control – Want EF, AF41 and AF31 going over your MPLS link while everything else goes over your Internet? Sure. No problem. YOU create the policies for what traffic goes where as your preferred path.
- Load Balancing – Want your default class to get load balanced over both links AND have that load balancing take into account that the bandwidth of the two links are different? No problem. Enable load-balance in one place and you are good to go.
So, again, why Intelligent Path Control at the WAN edge?
Intelligent Path Control at the WAN edge allows you to utilize that backup link to bring more WAN bandwidth to your branches but with intelligence.
Want more IWAN now? 🙂
CiscoLive
BRKCRS-2000 – Intelligent WAN (IWAN) Architecture (2015 San Diego) – 2 Hours
Great Article and great explanation of PfR! And it came at a perfect time for me since I am leading a “Lunch and Lab” for our customers over IWAN tomorrow.
How did your “Lunch and Lab” go?
Great post!
I think a big issue is that load balancing only works for an on multiple TCs. What I find that most people don’t understand is that you can’t just ‘load balance your internet traffic’.
Most of the return traffic to a site vlan (VLAN X) will all have DSCP0 and will get load balanced to a single link. That will all be one TC and stay pegged to that link..