“Learning about and avoiding impairments (delay, loss, jitter) along the path that business critical traffic takes.”  That is what I wrote in my previous blog “IWAN’s Intelligent Path Control & Using Your Backup Link.”  But how is that possible to do?

Thinking some type of probe? From where to where? Thinking the WAN edge links? But how do you know the path you send your probes over is the path that your business critical traffic is taking?

Let’s talk about what I mean by this by looking at an example.

 

 

 

 

 

 

In the above picture we have 2 sites with 1 host per site, and 1 WAN connection between the two.

• Branch2 w/ host 10.2.10.101
• Hub Site w/ host 114.114.114.101
• WAN connection w/ 21.21.102.3 on the Branch2 side and 21.21.1.2 on the Hub Site side.

Let’s say you check the health of the path between Branch2 and the Hub Site with some type of probe/IP SLA.  You will be doing it from the 2 WAN IP addresses 21.21.102.3 and 21.21.1.2.   Right?  How do you know that “health check”  of the path between Branch2 and the Hub Site will actually end up going over the same path as the critical traffic between those two hosts?

What is happening in that cloud in the middle?  All kinds of things like hashing algorithms to load share traffic for ECMP (equal cost multiple path) and port-channeling.  The majority taking, at the very least,  the source IP and destination IP into the hashing algorithm they use. Making it exceedingly obvious, already, that it is far from a given fact that a health probe between the WAN IP addresses 21.21.102.3 and 21.21.1.2 and the critical traffic between 10.2.10.101 and 114.114.114.101 are going to be traversing the same exact path over the WAN between Branch2 and the Hub Site.

I get teased sometimes for my Cisco URL/Wikipedia URLs only in my CiscoLive sessions.  🙂  So let me mix it up and point to a Juniper URL for this example.

• Juniper: Understanding the Algorithm Used to Hash LAG Bundle and Egress Next-Hop ECMP Traffic

In the above URL you can look more closely at the first table (Table 1).  You will see that the table actually shows what IPv4 and IPv6 payload fields are being used by their hashing algorithm by default.  EVERYTHING with a “✓” is a field that is on by default.

 

 

 

 

 

 

 

 

 

 

 

 

The above image is just a snippet of the entire table.  But even from the above you can see that is a 5-Tuple based hash that Juniper is doing by default.

• Source IP address
• Destination IP address
• Protocol
• Layer 4 Source Port
• Layer 4 Destination Port

 

 

 

 

 

 

 

With a Juniper default 5-tuple based hashing… now what are you thinking about the odds that

• the health probe between the WAN IP addresses 21.21.102.3 and 21.21.1.2 + Src port + Dst port and
• the critical traffic between 10.2.10.101 and 114.114.114.101 + Src port + Dst port

will traverse the same exact path over the WAN between Branch2 and the Hub Site?

You can see where this is going pretty quickly, can’t you?  And I didn’t even mention the possibility of MPLS Traffic Engineering Class-based Tunnel Selection

Why such a focus on this?  I mean… as we can see from the example there is just 1 WAN link.

As I mentioned in the previous blog, “IWAN’s Intelligent Path Control & Using Your Backup Link”,  it is very typical that a branch location has a minimum of 2 links.  As I also mentioned, people are now wanting to use that backup link. Admittedly… with intelligence at the WAN edge.  Especially for your business critical traffic.

So say Branch2 has 2 WAN connections: 1 MPLS, 1 Internet.  We decide to use IWAN and design it and configure it for our business critical traffic (EF, AF41, and AF31) to go over the MPLS link and to  use the Internet link as a fallback if there is impairment (delay, loss, jitter) on the primary path that is unacceptable for our business critical traffic.  But we want to do this with intelligence.  We want to know what the quality/health is of the actual path the business critical traffic would take over that WAN cloud.  When do we want to know this?

BEFORE we even consider moving our business critical traffic over to it!!!

 

 

 

 

 

 

 

 

So in the above picture we would have the business critical traffic going over the PfRv3 “primary channel” and we would already have a backup channel between Echo3 and Foxtrot13.  AND they would be probing and reporting to the PfRv3 masters the health of the exact path that business critical traffic would be taking.

🙂

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?  🙂   More on that in the next blog.   I have finished it yet… but currently the title is “Business Critical Apps & the DMVPN Underlay of IWAN’s Intelligent Path Control”.  So there is your hint.