I have been working for Cisco for over 15 years, much of that time as a Consulting Engineer for Routing and Switching. 

I understand strengths and weakness of routing, the value of a good hierarchical design.... But what's worse than having an end-user having problems with one of his business application and being unable to provide an answer? Yes we have traceroute, ping and other fancy networking tools but nowadays we have to deal with applications and user experience. We have to move forward and take into account the performance of an application rather than just forwarding packets based on static cost metrics. It's not just about connectivity anymore.

Therefore I've moved to the Application Visibility and Control (AVC) group in Engineering. It's like jumping from standard L3 to advanced L4-L7 kind of routing.

I know what you may be thinking when you read these lines ... yet another new acronym. We have the good old routing protocols,why should I care about this new AVC?

It's a fact that we know how to deal with routing designs, we know how to deploy routing protocols, and the next natural question is "what about my applications?" And more specifically, "how can I ensure that my applications get what they need in terms of network resources?" After all, it's all about applications and user experience. You can have the best design ever, however if your users complain about their application being too slow and you can't find the root cause, you are in bad shape as a network admin.

Application Visibility and Control (or AVC) includes the "A" for Application recognition, this is essentially NBAR2, the new deep packet inspection engine. I will keep that one for another post.

Let's look at the "V" of Visibility.I have the following questions for you:

• Do you know if you are getting your SLA?
• Do you know the applications running in your network?
• Do you know how to isolate application performance problems?
• Do you know how much non-business traffic is consuming your resources?

If you answer all the questions above, you are good to go and probably already have network instrumentation in place.

The next step is to look at the "C" of AVC, which is Control.

• Are you able to deal with poor and inconsistent application performance?
• Are you able to deal with your network outages?
• Are you able to optimize your bandwidth utilization, especially over expensive WAN links?
• Are you able to deal with network brownouts, or soft errors?

These are the typical problems we have now.

In this post I will concentrate on the Control part of Application Visibility and Control. You basically have two options there. Optimizing the bandwidth on a specific link and that's all about QoS, and you can try to find an appropriate path based on application requirements. This is Cisco Performance Routing, or PfR.

Performance Routing allows network administrators to minimize bandwidth costs, enable intelligent load distribution, improve application performance, and improve application availability.

Whereas other routing mechanisms can provide both load sharing and failure mitigation, Cisco IOS PfR makes real-time routing adjustments based on application criteria such as response time, packet loss, jitter, path availability, interface load, and circuit cost minimization.

There has been an increasing number of requests lately for two PfR deployments scenarios:

Internet Edge-Using PfR to load balance the traffic among multiple Internet provider uplinks. Internet path optimization was the original use case for Performance Routing. PfR is certainly not the only solution to cope with this problem, but this should be the easiest. You can (and probably do) tune BGP with a mix of route-maps and local-preference as well as some AS-PATH prepend for the ingress traffic. This supposes you have some instrumentation in place to determine the top talkers prefixes and tune accordingly.

PfR will give you the load balancing you are looking for, using the same kind of BGP tuning, but automatically without the pain of manual configuration. You can troubleshoot BGP the same way, but the configuration remains simple and clean. And you can add some policies like tracking the brownouts, removing links from the selection if they experience a bad delay or a high number of packet losses. Sounds attractive?

Enterprise WAN-PfR enhances WAN routing by applying application and link performance considerations to IP routing. PfR takes real-time measurements and implements application-specific routing to keep performance within an application-defined policy. This allows an enterprise to optimize the bandwidth, reduce their cost and also track the brownouts and blackouts. Implementing Performance Routing over the WAN will improve the overall user experience and increase the application and network uptime.

One of the common concerns with PfR is on troubleshooting. Traditional IP routing determines shortest and alternate paths based upon static metrics which makes the path calculations deterministic, while PfR will continuously track the performance and move the traffic to the appropriate path based on dynamic metrics such as delay, loss and link utilization levels. This is a paradigm shift for network operations.   Before routing protocols, we had static IP routing and there were similar concerns about dynamic IP routing protocols (RIP and EGP).  It is only a matter of time when adaptive application routing will become the normal mode of operation.

If you are interested in knowing more about Performance Routing,  you can check out our wiki or register for the AVC TechAdvantage Webinar, April 3rd at 8 am PST. 

Ready for a change? Ready for Performance Routing?

Tell me what you think.