Networking with FISH on wire (944 bits), 116 2: b7:3F:00:20 (cc:02:b oLEEn Protocol, Src Port: bgp ol OPEN Message HOME — ABOUT FI FISHNET MORE FISH BLOG ROLL Business Critical Apps & the DMVPN Underlay of IWAN’s Intelligent Path Control Posted on September 15, 2015 by Denise "Fish" Fishburne * 0 Comments Let's assume we have a Branch with 1 Router and 2 WAN connections. We decide to se 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, P{RV3 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 | asked at the end of my previous blog entitled, Which Path in the WAN are those Business Critical Applications Taking?’ [DScP Source IP DestiP —_porT| EF 10.2.10-101 114.114.114.101 So how is it accomplished??? @ Let me ask you a question. What if the branch, Echo, 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. DSCP Source IP DestiP PORT! EF 10.2.10.101 114.114.114.101 # 10.2,10.101 Traffic Branch2 102x316 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.ineernet Pratocad Version ty Sree TOP OriOL Core TOONS Dae Te Tee TTTOL Git TTT TOO Ta apaarnas ai Rertecomibeed custcas eiaias wasuripecnncie| Seen rereading) wits ite ace RTE tng eens Seen ois (a Hips oo, See. ane Teese Oy a eee nates teres Wars atsaatean Source: 10.2.10.101 (10.2.10.101) | destination: 114.114.118.101" (114.116.116.101) [source GeorP: unknown] (Baiger sere Protocol, Src Port: 16386 (46366), Ost Port: 17366 (47386) = bata res ° We can easily see that if this packet were to be sent out to the WAN cloud as itis 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 1, source IP: 10.2.10,101 2, destination IP: 114.114.114.101 3. protocol UDP 4, 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._ 114.114.114.101 Branch2 10.2xx/16 In the above picture we DSCP Source IP Dest iP Protocol | sce Sourcei> Dest iP EF 22.21.102.3 21.21.1.2 GRE (47) SEE Seo 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.1023 + destination IP: 21.21.1.2 + protocol: GRE + DSCP: EF in Frane 11 152 bytes on wire 216 bits), 152 bytes captured (216 bits) Internet Protocol version 4, -arer o1-21023-e2i-T02- ayy bets Pie ehe te? Cal ah-t2) wee Header Length: 20 bytes Wu Differentiated Services Field: Oxb8 (osc Ox2e: [Expedited Forwarding; ficn: 0x00: Not-ECT (Not ECN-Cap: Total Length: 134 Identification: Ox3ba7 (15271) lu Flags: 0x00 Fragnent offset: 0 Time to live: 254 Protocol: Generic Routing Encapsulation (47) @ Meader checksum: Oxeeba [validation disabled] Source: 24. 21.102.3 (21.21.102.3) 21.21.12 (21.21.1.2) Protocol Type: IP (Ox0800) key: 000000002 Original Packet @ internet Protocol version 4, src: 10.2.10.101 (10.2,10,101), Ost: 114-414,114,101 (114.114.114.101) “= @ User Datagram Protocol, Src Port: 16386 (16386), Ost Port: 17386 (17386) @ pata (78 bytes)How does this help? So | wrote in the beginning of this blog that - With Intelligent Path Contro! with PIRv3 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, PARV3 wil be checking the health of the path the backup channel is taking. Actually... let me be even more specific. PIRV3 will be checking the health of the exact path that business critical traffic would take if it were fo be sent over the fallback WAN cloud. SCP Source IP Dest IP Protocol EF 11111022 11.1112 __GRE(47) DATA or Smart Probe Hus sme 114.114.114.101 Traffic en SCP Source IP Dest IP Protocol | ascr soup per EF 22.21.1023 21.21.12 GRE (47) |_# sata wiettesteso 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. PIRV3 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 itis 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 wil 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. Filed Under: DMVPN, IWAN, PéRv3 ‘«— Which Path in the WAN are those Business Intelligent Bandwidth Decisions at the WAN Edge Critical Applications Taking? = Comments are closed.