softflowd : Free NetFlow Probe
We tested a free netflow probe recently called softflowd. The setup and configuration was pretty straight forward. To install softflowd:
- sudo apt-get install libpcap-dev
- sudo apt-get install softflowd
Security Monitoring System
Our new security monitoring system is underway and I should have some pics and some specs on what we have installed. We have multiple security cameras attached to the security probe as well as some temperature sensors and humidity sensors.
DSCP or ToS in Flexible NetFlow Configurations
Filed under: environmental monitoring, General, IPFIX, nBox, NetFlow, NetFlow probes
Do you want to export ToS or DSCP in your Flexible NetFlow export? This is an interesting question and I’ll do my best to answer it. The NetFlow RFC 3954 makes reference to ToS as the 5th field and makes NO reference to DSCP. The IPFIX standard information elements outlined in RFC 5102 lists both ToS (5) and ipDiffServCodePoint (195). Why duplicate efforts, aren’t they the same thing? NO!
Why have Both?
ToS is an 8 bit field that includes DSCP which is a 6 bit field. This being said, I could not find a Flexible NetFlow document that would make reference to both however, I know Cisco sometimes supports both in the same export.
Be aware that Cisco NetFlow v5 and traditional NetFlow v9 only export ToS. I’m sure you are aware that FnF is an extension of NetFlow v9 and supports both ToS and / or DSCP depending on the implementation.
* Cisco NBAR (requires FnF) for example, it will export both ToS = ipClassOfService (5) and DSCP ipDiffServCodePoint (195). See below.
- Cisco nBar Exports ToS & DSCP
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.
VoIP NetFlow Monitoring Software
Are you looking for VoIP monitoring software using NetFlow? Many people wouldn’t consider a Cisco NetFlow analyzer for troubleshooting voice or video traffic; however, this is changing. Cisco, SonicWALL and nProbe are all providing details that allow for VoIP NetFlow Monitoring.
VoIP Details include:
- SSRC
- Codec
- Jitter
- Packet Loss
- Caller ID
- Details on both RTP and SIP
Below are a few screen shots of these new reports, which are based on the nProbe’s IPFIX exports. IPFIX is the proposed standard for NetFlow.
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.
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