Fast Packet Manipulation on Linux Servers
ntop, with the help of Silicom, just released a new version of PF_RING for the nBox NetFlow and IPFIX probe. If you are running a nProbe to generate network traffic you can now support more flows. This means flows at wire-speeds at any size with very little CPU cycle usage with incredible flexibility. Through the help of a 10Gbit ethernet card you can now do much more with your nBox.
Benjamin Moore
Follow me on Twitter
HTTPS Details with NetFlow
Good news for those of you who use NetFlow or IPFIX to gain insight when performing network traffic monitoring. The nProbe now performs HTTPS decoding on secure connections. Below is an example of an HTTPS exported flow. Read more
Follow me on Twitter
Latency Measuring with nBox and NetFlow
While Cisco’s NetFlow technology can be extremely helpful in identifying top talkers and applications on the network, it can sometimes lack the fine details often found in a standard packet capture. For instance, let’s take a look at application responsiveness. To determine why an application is slow to respond we often look to the amount of traffic on the link, as well as the latency of the transaction itself. Was there congestion in the pipe? Was the end-system slow to respond? Was the application itself responsible for the sluggishness? These are certainly all possibilities.
Luckily for the rest of us, the NetFlow data that gets exported from the nBox is a little bit different. In addition to what NetFlow normally provides in network traffic details, nBox exports include email addresses, HTTP URLs, Latency, VoIP Jitter and more. There is one caveat; at this time, Scrutinizer NetFlow & sFlow Analyzer is the only NetFlow reporting tool that can properly display these extra data fields. So you will want to make sure to look into Plixer’s product offering to take advantage of these advanced features.
IPFIX specification passed by nProbe software
Just last week, DEMONS, a European project designed for addressing the largest obstacles of “cooperative network monitoring,” held a successful IPFIX Interoperability Event in Prague. It was at this event that the nProbe software, available here at Ravica.com, was certified as compliant with the IPFIX verification testing.
nProbe and nBox IPFIX Reporting
Looking for more resources to help you get the most out of your new nBox NetFlow probe? Watch the video below to see Scrutinizer NetFlow and sFlow Analyzer Product Manager, Mike Patterson, explain how to report on IPFIX data exported from the nProbe and nBox to get application and server latency, URL information and more!
Once you’ve completed the video, make sure to visit our friends at Plixer to learn more about configuring the Windows nProbe to send NetFlow.
Jon Mills
Follow Me on Twitter
NetFlow-Lite (NFlite) Exports Using the nProbe and a NetFlow Collector
This month’s Cisco Live show in London allowed for some great opportunities. We mentioned that we met up with Luca Deri, developer of the nProbe. Our friends at Plixer International also attended the show where Cisco demonstrated the abilities of their new Catalyst 4948E NetFlow-Lite (NFlite) exports using Plixer’s Scrutinizer NetFlow Analyzer with the nProbe. NFlite is a sampling technology using NetFlow v9.
Plixer’s Product Manager, Michael Patterson, recently blogged about its features, explaining how the NFlite samples are sent to the nProbe, sending one sample per NetFlow datagram. He also included a screen capture of their Scrutinizer NetFlow collector demonstrating the integrated view of NetFlow data from N7k and NetFlow-lite from the 4948E.
Cisco Live- London with nProbe Developer Luca Deri
I went to Cisco Live Europe 2011 recently and met up with Luca Deri, the developer of the nProbe (a.k.a. NetFlow Probe). It was great to finally meet this industry icon for NetFlow and IPFIX. I just had to have my picture taken with him. Luca is on the right in the photo below:
Latency using NetFlow from the nProbe- Part 2
As we discussed in our recent blog about the benefits of using a NetFlow probe, the nProbe is an open source network software application developed by Luca Deri which allows admins to get latency from flows on networks. Through Luca’s partnership with Plixer International, Plixer has also been offering insight on how to get latency from network flows through their collector called Scrutinizer NetFlow Analyzer.
Latency from the nProbe comes in the following formats:
· APPL_LATENCY (Application Latency)
· CLIENT_NW_DELAY (Client Network Delay)
· SERVER_NW_DELAY (Server Network Delay)
Application Latency and Client Network Delay are determined when the NetFlow probe observes the TCP flags in a transaction. Below we captured the TCP packets in a connection initiated by client (10.1.15.20) to web server (10.1.7.18).
Latency using NetFlow from the nProbe- Part 1
Determining the causes of application slowness has long been a study of both traffic volume and latency within the transaction. Administrators had to determine if there was too much traffic on the connection which caused the slowness, or if there was sluggishness caused by the response time of an involved end system. Perhaps it was even the application itself causing the slowness.
If you have an nProbe, you can get latency from network flows captured by the probe. Read more
NetFlow Domain Reporting: Part 2
In the prior NetFlow Domain Reporting blog, I outlined how to view URLs using a NetFlow Probe called nProbe. In this post I’ll explain why 174.123.133.232 doesn’t show up for theplanet.com.
Answer
The server that hosts theplanet.com is not hosted on 174.123.133.232, but 70.87.6.117, as we can see in the above command window below.