The classic traceroute tool has become an essential tool for network engineers. Traceroute is able to discover layer-3 nodes (routers) along the path towards a destination. This information provides operators with visibility about the path towards a destination.
However, there are limitations to traceroute such as issues with traceroute following the right path (as it’s IP source address might be different), no layer-2 (switches and bridges) discovery and really only a single piece of information is returned (IP address of the router).
With mediatrace, which shares the IP header of the flow you would like to trace, you can have much better path congruency—and confidence in the discovery. The mediatrace will also not only discover the routers (as with traceroute), but also switches that are only doing layer 2 forwarding.
Mediatrace does not need to be enabled on every hop. If it is not enabled on node, the mediatrace packet will simply be forwarded through that part of the network. This is exactly what would happen in the case of your traditional MPLS-VPN network.
Figure 1. Mediatrace tracing a flow while the operator chillaxes
Now for the best part! Mediatrace can dynamically engage the performance monitor feature we talked about a few weeks ago. This allows a dynamic surgical monitoring policy to be applied for the flow we are tracing that results in hop by hop performance measurements such as loss and jitter. As is the case with all mediatrace runs, the information is brought back into a single report where it can be quickly analyzed.
Figure 2. Mediatrace integration with performance monitor
Despite the name, mediatrace is not only for voice/video flows. It is able to trace any IP flow, and is even able to engage performance monitor to gather hop by hop TCP stats.
Mediatrace is a new tool that cisco released in IOS 15.1(3)T for the ISR platforms as part of the medianet program. Over the course of 2011, this feature will proliferate across cisco’s enterprise line of routers and switches.
“The philosophy of the school room in one generation will be the philosophy of government in the next.” -- Abraham Lincoln
Given its technical complexities, it’s understandable that some people have been skeptical about business video adoption over the past few years. But video is now much more than just a technology. Like printing and voice were not so long ago, it’s an irresistible force that is fundamentally changing the way all generations create and experience culture, business, and much of our everyday existence. For example:
Video and computer game time for kids 8-18 has doubled in the past 10 years, and only 4-6% of their time is spent on print media (source: Arstechnica).
In a recent enterprise survey, 57% of respondents are planning or have already implemented some desktop video conferencing, and 44% are planning or have already implemented some IP video for training, demos, and other purposes (source: Forrester Research).
By the end of 2010, almost half of all mobile data traffic was already video, and it’s expected to grow 26 fold from 2010 to 2015 (source: Cisco Visual Networking Index).
Forward-thinking organizations embracing these trends have already come up with some wonderfully innovative new business models built on delivering video everywhere. For instance, the Khan Academy delivers free education via YouTube to millions of people worldwide, and Marriott Marquis hotels are delivering unique new guest experiences for discriminating travelers via Cisco technology.
Here’s a dramatization of delivering video anywhere to enhance education:
Most people already have IPv6 capability whether they know it or not. All Microsoft operating systems such as Windows Vista and all MacOS releases since 10.2 have IPv6 installed enabled by default. Mobile devices running Android 2.1, Apple iOS 4.0, and Symbian 7.0 are configured likewise as is nearly every *nix variant you can name. Even the venerable and ubiquitous Windows XP has a latent IPv6 stack which can be activated with a single command.
Typically, IPv6 enabled systems will prefer IPv6 connections over IPv4, so a misconfigured or malfunctioning IPv6 network will cause connectivity problems. Many popular troubleshooting regimens simply prescribe disabling IPv6 as the “solution,” which really does nothing more than to hide the underlying problem with the IPv6 network. When you have a network problem that is “solved” by disabling IPv6, you have masked the symptom of a bigger problem that warrants further investigation.
You can make your named network services available via IPv6 with a few simple steps. First, your DNS server or DNS service provider should first hand out AAAA DNS records (pronounced quad-A record) which map hostnames to IPv6 addresses. Second, you should provide PTR records to allow IPv6 Reverse DNS (rDNS) lookups. Finally, you should take steps to make the DNS server itself reachable via IPv6.
Setup your DNS Server to start serving AAAA records
To allow resolution of hostnames to IPv6 addresses, your DNS Server must respond to requests for AAAA records. Adding AAAA records to your forward zones will enable clients with IPv6 connectivity to learn the IPv6 addresses of your resources. Be aware there is a small risk that if a requesting client is among the minority with broken IPv6 connectivity, it can appear to the client that your website is down. Some companies use DNS whitelisting to mitigate such issues, but there are concerns around that approach.
The only way to be sure of delivering highest quality of experience is by actually measuring QoE of real traffic. In IOS 15.1.3T, we introduced a new embedded monitoring capability to collect packet loss, jitter, delay and response time information for performance evaluation of data, voice and video services. The feature is called IOS Performance Monitor. (See yesterday’s blog on User Traffic Analysis by Medianet performance Monitor.)
In December of last year, Cisco IT was running a medianet pilot program for the new IOS performance monitor feature as their ongoing effort to provide high quality and improved services to end users. The pilot was designed to support 50 remote sites equipped with the ISR-891 routers. Two of the pilot sites were small Cisco offices and the remaining was home offices. I was lucky enough to be selected for the pilot.