Cisco Performance Routing isn’t your grandfather’s routing. Cisco Performance routing (PfR for short) considers a particular path’s traffic characteristics when determining the best path for the conversation. Imagine being able to use actual delay, packet loss, MOS, jitter and more to give your router a better idea of the traffic conditions. With that data it can make a smart decision on how to route the conversation traffic. Add to that the ability to report on this with something simple like Netflow and you have solution that sounds to good to be true. Well, it isn’t!
Last summer our Product Manager and Samuel Yee explained why the introduction of Cisco Performance Routing (PfR) and our Performance Routing Netflow Reports were important. To recap, the goal of any network administrator is to get the most out of their network’s available bandwidth and/or the best possible performance for your applications across the network. The benefit of using PfR is that it provides intelligent routing that can correct traffic issues by adjusting the route that traffic takes when performance degrades beyond defined thresholds. PfR can do this in two different ways:
1. Passive monitoring – Learns your traffic and then creates a class on it’s characteristics. Each traffic class has a policy that it is measured by to determine it’s quality. Passive monitoring measures performance of traffic that is traversing the router.
2. Active monitoring – You can configure PfR to actively send different types of traffic across a link and make routing decisions based on the performance results. It uses synthetic traffic in order to insure performance at all times. This is especially helpful if certain types of traffic are sporadic.
Policies can be issued per class or applied globally which allows you to make things as general or specific as you need them to be. The cool thing is, PfR policies use various metrics to determine the quality of the path. If the class does not meet the conditions of the policy it will generate an Out Of Policy flag and then action is taken (rerouting or another action). For more information make sure that you check out the Cisco Wiki which has a great PfR Overview
This is all great but, how do you report on this? Good question and I had one of my French evaluators ask the same the one! The good news is that every record that is generated by PfR can be recorded by Netflow and sent to a Netflow reporting tool like Scrutinizer. In this case the evaluator wanted to know if Scrutinizer could report on “flapping” and the answer was “yes”!
“Flapping” is intermittent reachability of an IP. PfR will test the connection both actively and passively to get it’s state. If PfR determines that a link is down it will generate an OOP or Our of Order Policy record. In Scrutinizer, if you see a constant OOP: Timer Expired over a given time then there is a possibility that the interface is flapping.
Here is how you can see this
Step 2: Click on PfR Out of Policy
Step 3: Here you look for OOP:Delay
Step 4: Add a PfR Traffic Class filter and enter in the Border Routers IP and the Traffic Class ID.
To find the Traffic Class ID just hover over the word OOP:Delay
Now you are able to see all of the delay violations for that traffic class.
If you are seeing multiple entries along with the up and down lines in the graph there is a good chance the interface is flapping. You then easily change the report type by clicking on the IP address of the border router and get the “what”, “where” and “who” of the traffic that as associated with this OOP. On top of that you can use our Cisco Advanced Reporting module to get Performance Monitoring data. If you have any questions or want to see PfR reporting become part of your network traffic analysis solution make sure to give us a call at 207 324 8805.