Google Maps for Your Car, PFR for Your Critical Data!
Recently I was driving on the 90 going to Boston, traveling to Logan International Airport. I was using Google Maps to navigate myself to the airport, since I was unfamiliar with the local area. The traffic was pretty awful, and I was cutting it close to arriving with enough time to drop off my rental car as well as check in for my flight. I noticed on Google Maps that it had offered me an alternative route that was supposed to be quicker. I could have really used the extra time to make sure I could make my flight, so I took Google up on the offer. While driving down the alternative route I thought that many of the local people would also use the same roads, since it was supposed to be faster. What I noticed was that it was pretty open compared to 90. This got me to thinking about PfR, or Performance Routing, and how powerful it can be, similar to Google Maps.
You may design your Wide Area Network (WAN) to send your critical data over your MPLS service provider and have an Internet link as a failover. While most of the time it may be best to send that data over the MPLS service provider, what if there is some type of congestion or issue with the MPLS link? (Similar to the 90 and how many of the local people just take that same route because that route is traditionally the fastest). Using PfR you can now set policies that will, in a similar manner as Google Maps algorithms, verify how that path is doing, and then intelligently move that critical data to the best performing link. To complete the picture, you need a tool like LiveNX to show you the visual map of the routes.
Very similar to having to catch my flight, your Voice and Video information is very delay sensitive. Looking at a snippet of a PfR policy below, you can get an idea of how the technology works:
pfr-map MYMAP 10
match PfR learn list LEARN_VOICE_VIDEO
set delay threshold 150
set loss threshold 50000
set jitter threshold 30
set link-group VZN fallback L3
Above, you can see if the delay loss or jitter exceeds a certain value, then the Voice and Video traffic will use the L3 fallback instead of the traditional VZN path. Now, what’s happening under the covers? Cisco is using your real traffic to verify the performance of the link. Using performance monitors and probes, your traffic will always be taking the best route possible.
Now, if you have considered PfR in the past, such as PfRv2, there have been major improvements in the latest version. The deployment and management of the technology has improved greatly. Using LiveNX, you can deploy this technology in seven easy steps. If you have 15 minutes, I would highly recommend from our Senior TME, David Izumo, where he gives a demonstration of the technology. Here is also a great wiki that discusses PfRv3 in great detail: http://docwiki.cisco.com/wiki/PfR3:Solutions:IWAN.
September 23, 2016
Author: Alex Cameron