Let’s assume we have a Branch with 1 Router and 2 WAN connections. We decide to use Intelligent Path Control with PfRv3 and design our policy such that the business critical traffic goes over one of the WAN clouds (MPLS, for example) and will use the other WAN cloud (Internet, for example) should a certain level of impairment (delay, loss, jitter) occur on the primary path.
But that business critical traffic is well….. critical to your business. So that probably isn’t really good enough. Let’s take this a couple steps further to make sure your business critical traffic is treated as such.
With Intelligent Path Control with PfRv3 what will actually happen is that while the business critical traffic is going over the primary channel, a backup channel will be created over the other WAN cloud. On top of that, PfRv3 will be checking the health of the path the backup channel is taking. Actually… let me be even more specific. PfRv3 will be checking the health of the exact path that business critical traffic would take if it were to be sent over the fallback WAN cloud.
“How is this accomplished?
Regardless of hashing algorithms used in the WAN cloud for ECMP or port channeling?
Regardless of any MPLS TE Class Based Tunnel Selection?”
Those are the questions I asked at the end of my previous blog entitled, “Which Path in the WAN are those Business Critical Applications Taking?”
So how is it accomplished??? 🙂
Let me ask you a question.
What if the branch, Echo3, took the business critical traffic and wrapped it inside of a GRE tunnel with WAN edge IP addresses for Echo3 and Foxtrot14 as the source and destination IP?
Let’s look. First let’s start with the original packet from the end device in Branch2.
In the above picture we see that we have the business critical traffic in the branch being sent from 10.2.10.101 to 114.114.114.101.
Below is a sniffer trace snapshot of the business critical packet I’m referring to in the above diagram.
We can easily see that if this packet were to be sent out to the WAN cloud as it is now any hashing algorithm in the WAN cloud would ECMP or port-channel hash based at the very least based on source IP and destination IP
- source IP: 10.2.10.101
- destination IP: 114.114.114.101
- protocol UDP
- DSCP: EF
We can also see that if we were going through any MPLS Traffic Engineering Class Based Tunnel Selection (CBTS) this traffic would follow whatever Tunnel was selected for DSCP EF.
Again…. What if the branch, Echo3, took the business critical traffic and wrapped it inside of a GRE tunnel with WAN edge IP addresses for Echo3 (21.21.102.3) and Foxtrot14 (21.21.1.2) as the source and destination IP? 🙂 Starting to see it? Let’s look.
In the above picture we see our original business critical packet frame (in blue) from source IP 10.2.10.101 to destination IP 114.114.114.101 with DSCP setting EF. But as you can see it isn’t going out to the WAN cloud like that. Instead, the Branch is putting it inside a GRE tunnel: DSCP EF, Source IP 21.21.102.3, Destination IP 21.21.1.2, and protocol GRE.
Looking below we can see the sniffer trace snippet of what this business critical packet … GRE encapsulated…. would like like in the cloud and to hashing algorithms or MPLS traffic engineering CBTS (class based tunnel selection) in the cloud.
- source IP: 21.21.102.3
- destination IP: 21.21.1.2
- protocol: GRE
- DSCP: EF
How does this help?
So I wrote in the beginning of this blog that –
With Intelligent Path Control with PfRv3 what will actually happen is that while the business critical traffic is going over the primary channel, a backup channel will be created over the other WAN cloud. On top of that, PfRv3 will be checking the health of the path the backup channel is taking. Actually… let me be even more specific. PfRv3 will be checking the health of the exact path that business critical traffic would take if it were to be sent over the fallback WAN cloud.
See that packet going out the top WAN cloud? Is lists that the inner packet could be data (the GRE encapsulated business critical data) or a SmartProbe. Since the traffic is actually going out the primary WAN cloud at the bottom. This is a SmartProbe. This is a PfRv3 SmartProbe that is going over the backup channel and probing for the health of the backup channel path for the business critical traffic that is going out the primary. PfRv3 is probing the health of the exact path for this specific traffic class with a DSCP value of EF. How do we know that? 🙂
Is the WAN cloud going to look at the stuff in blue? Or is it going to be looking at the outer IP header to make decisions. Answer is that it is going to be looking at the outer IP header. Based on that we can see that no matter if the packet going out the top WAN cloud is a SmartProbe or the business critical traffic inside of a GRE tunnel… the WAN cloud will still make all of its hashing and MPLS TE CBTS decisions based on the outer IP header.
And VOILA! Now the reason for the DMVPN underlay is that much clearer! It is because of the GRE tunneling coupled with PfRv3’s Intelligent Path Control that we can do all the fact gathering of the health of the actual path that business critical traffic would take if it went over the fallback WAN cloud on top should impairment occur on the primary.
Why is knowledge of the health of the actual path your business critical traffic would take over the fallback WAN cloud so important? What if our business critical traffic was voice? And what if there is jitter on the primary path… but there is delay (or loss) on the fallback path over the backup channel? Our policy that we designed has delay and loss both listed as much worse than jitter. So in this situation by knowing the health of the exact path our business critical traffic would take is currently experiencing delay that is beyond thresholds for our application — we can bring intelligence to the WAN edge and stay with the jitter.
Leave a Reply