Last week I travelled to Cisco’s RTP campus with one of our SEs to complete our Medianet Interoperability Testing (IVT). Specifically, we were there to validate test cases on Performance Monitor and IPSLA Video Operation (IPSLA VO).
We encountered a pleasant surprise during the testing
and found out that NetFlow is now supported on the Catalyst 3750 and 3560!...but more on that later…
We’ve been working closely with the Cisco Medianet team for some time now, and if you remember a while back, I did a blog on Medianet and Performance Monitor
. Since that time Cisco has released support for IPSLA VO on the Catalyst 3Ks and we’ve done the same with LiveAction 2.2. Before going forward, let’s do a brief refresher on Medianet.
Medianet is Cisco’s approach to making the network “video aware” and for generally making video easier to deploy, deliver and manage. Medianet originally started out as a reference architecture but has since evolved to include a wide range of capabilities built into the devices themselves. While it focuses very heavily on video, a lot of the Medianet capabilities apply equally to voice and other mission critical traffic. Coincidentally, a lot of these capabilities mesh very well with LiveAction’s “all-in-one” approach to managing network resources for real-time services. When you take LiveAction’s rich set of capabilities, you can see a very strong alignment with what Cisco is doing with Medianet:
Traffic flow visualization – Which paths is the critical traffic on my network taking?
What non-critical traffic is disrupting my network?
QoS provisioning and tuning – Constructing, deploying and adjusting QoS policies
QoS monitoring – What is network performance on a class-by-class basis?
Routing awareness – Are there anomalies in my forwarding paths that are impacting services?
IPSLA synthetic traffic generation – Is my network ready for new services? How do I reproduce problems or test my policies?
Our focus for the IVT was on IPSLA VO and Performance Monitor. IPSLA VO is supported on Cisco’s Catalyst 3750 and 3560 platforms using IOS 12.2(58) SE
. If you’re already familiar with “regular” IPSLA, IPSLA VO is just a video version of Cisco’s synthetic traffic generation and analysis. Now, I say “just” synthetic video, but it’s some pretty cool technology! First of all, you have the ability to choose from Telepresence, IPTV and IP video surveillance traffic types. Each of these test types mimics the bandwidth characteristics of their respective real traffic. Below is a screen shot of LiveAction monitoring an IPSLA VO Telepresence test. As you can see in the graph the synthetic traffic is bursting up to around 6.5 Mbs, which is what you would expect of an HD video conferencing session.
LiveAction allows you to graphically manage IPSLA VO by configuring the tests and displaying the results. This is extremely useful when you’re preparing for a video deployment and you need to understand the impact video traffic will have on your infrastructure and any QoS policies that are in place. Another use case is for post-incident troubleshooting where you don’t have access to the video endpoints and you need to recreate the problem. Here are a couple of screen shots of the video test setup and some results:
In the process of validating interoperability with IPSLA VO, we found out there is now NetFlow support on the Catalyst 3700s and 3500s! More specifically, these devices support Medianet Performance Monitor using Flexible NetFlow. Performance Monitor is a specialized version of NetFlow primarily used to gather performance metrics for RTP and TCP traffic. The primary use case is to monitor and troubleshoot performance of specific types of critical traffic like voice, video, and data. For example, you might monitor all of your EF (voice) and CS4 (Telepresence) traffic transiting the switch. Or, you might be looking for problems with TCP traffic going to and from a critical server.
Performance Monitor uses Flexible NetFlow with a C3PL (Cisco Common Classification Policy Language) format for identifying the traffic you want to monitor. If you know MQC you’ll be familiar with this class-map / policy-map format. Note that you will see a CPU and memory hit with Performance Monitoring, so the more flows that you are trying to monitor, the bigger the performance hit on the switch there will be. We’re still playing around in the lab and checking things out, and you should too before you try it in a production environment.
Here’s an overview of what you’ll need in the configuration:
Flexible NetFlow flow exporter to export the flows to a collector (e.g., LiveAction)
Flexible NetFlow flow monitor to store the flows with the desired match and collect fields
Performance Monitor policy-map with class-maps to identify the traffic of interest
Service policy applied to appropriate interfaces
And here’s a generic example with a wide-open match. I would use this for lab testing only:
! Define the flow exporter
flow exporter LIVEACTION
transport udp 2055
template data timeout 60
! Define the flow monitor
flow monitor type performance-monitor LA-MONITOR
! Define the class map
! This one uses a wide open ACL
class-map match-any CLASS-MATCH-ANY
match access-group name ACL-MATCH-ANY
ip access-list extended ACL-MATCH-ANY
permit ip any any
! Define the policy-map with class-map and monitor
policy-map type performance-monitor LA-POLICY-RTP
flow monitor LA-MONITOR
! Apply service-policy to interface
int gig 1/0/1
service-policy type performance-monitor input LA-POLICY-RTP
int gig 1/0/2
service-policy type performance-monitor input LA-POLICY-RTP
The record default-rtp statement in the flow monitor is using the standard set of match and collection parameters for RTP traffic. There is also something similar for TCP – record default-tcp. If you do have a lot of ACLs and class-maps that you are defining you can use LiveAction’s graphical ACL and QoS editors to create your class-maps and write it to the device. Final construction of the policy-map, service policy and flow monitor is still done via the command line, but you’ll still save some time minimize CLI fat-fingering!
Here are some screen shots showing the end result on a Catalyst 3750. You can see some of the Performance Monitoring DSCP, RTP SSRC and jitter information in the first few columns, and even some SNMP:
Also remember that Performance Monitor originally was released on the ISR platform (and already supported on LiveAction), so you can get the same type of information on those routers.
After a long trip from Honolulu to the East Coast and back, we ended up having a great week in RTP. We successfully certified LiveAction as Cisco Compatible
with Medianet Performance Monitor and IPSLA Video Operation, gained Registered Developer
status in the Cisco Developer Network (CDN), and discovered that LiveAction’s end-to-end NetFlow visualization is supported with Cisco’s most popular line of switches. All in all, a pretty good week!
If you’re interested in trying out these Medianet capabilities with your Cat 3ks or ISRs, you can download a free trial version of LiveAction here
Ken Van Orman