• sudo apt-get install libpcap-dev
• sudo apt-get install softflowd

After softflowd is installed you can run it on an interface. In the example below eth0 is attached to a mirrored port (uplink) on a core switch and the NetFlow is being sent to 10.1.10.1 on UDP 2055. This will allow you to see all of the flows on the switch.

• sudo softflowd –v 9 –n10.1.10.1:2055 –i eth0 –m 100000 –t general=60s

Use a free NetFlow monitoring tool such as Scrutinizer.  Scrutinizer NetFlow Analyzer will treat this as a new exporter, but will only report using a single interface, 0. All of the flows are tagged with a source interface of 0 and a destination interface of 0.

Nationally, the USA is not seeing a big increase in crime, however this is best measured locally according to the Bureau of Justice.  Is crime on the increase in your area?

What is interesting about this solution is that it doesn’t involve multiple monitor spread out over a wall with 1-2 people watching for problems (or sleeping).

Our solution is a dashboard that allows you to have cameras from different vendors in the same web interface.  You can place a gadget using any 3rd party URL into the mashup. I should be able to put some NetFlow probes  in here as well.

I can’t wait to start testing the playback features:

I should be able to post some details over the coming months.  I’ll even have some night vision cameras with inferred technology to tinker with.  I can’t wait!

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 Performance Monitoring for Medianets (requires FnF) for example, it only allows for the export of DSCP ipDiffServCodePoint (195).
* The nBox exports ToS (5) even when exporting IPFIX however, it may export DSCP (195). I need to check.

Why did this Happen?

Cisco is a big company. My guess is that communication doesn’t always occur on every field that an engineer wants to export. Lets hope it is easy for them to address. In the mean time, what can you do?

Look for a Flexible NetFlow Reporting  solution that supports reporting on either but, you need to be using our beta release. See below.

Join NetFlow Developments on Linkedin to stay on top of issues like this.

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.

Michael Patterson of Plixer International and Luca Deri of nTop.org have devised an excellent whitepaper describing, in detail, the methods behind determining network latency using NetFlow from your nBox.

So, whether your slowness issues are caused by Application Latency, Client Delay or Server Delay, the combination of Scrutinizer and nBox can be a valuable suite for network administrators that need the extra visibility into application and network performance. In addition, these details can also be quite helpful when monitoring cloud services. Just ask any marketing or sales rep how frustrating it can be when their connection to Salesforce.com is crawling right along. Why waste hours troubleshooting a network issue that isn’t an issue with the network? Conversely, why should an application be blamed when it’s clearly database transactions are being poorly routed?

Let us know if you’ve had success with using nBox data to pinpoint slowdowns. We’d love to hear your stories!

~ Jon Mills
Follow Me On Twitter

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.

If you are looking for an nProbe demo, give us a call. We can provide many of the above details on your Cisco medianet, as well using their new Performance Monitoring NetFlow exports.

~ Mike Allen

nProbe creator, Luca Deri, says in a recent blog post, “nProbe 6.3.x has been successfully tested against all the available implementations including Vermont, SiLK, nfdump/IPFIX (Cesnet). nProbe has passed all the IPFIX interoperability tests as both probe (over SCTP, UDP, and TCP) and collector (UDP), dissecting both IPv4 and IPv6 traffic, and also converting NetFlow-Lite flows into IPFIX flows.”

Above is a picture of Luca at the event. That’s him just right from the middle, between Benoit Claise from Cisco (a joint creator of NetFlow / IPFIX) and Jiri Novotni of Invea-Tech.

This news speaks volumes about the level of commitment that Luca and the rest of the nProbe team have made to complying with the various network performance monitoring standards in the industry.

Jon Mills
Follow Me On Twitter

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.

Plixer was able to work directly with Cisco and with Luca Deri to ensure Scrutinizer’s compatibility with the new NetFlow exports.  Ravica offers nProbe as a versatile and powerful software solution to help you retrieve these NetFlow exports.  When installed on a PC, nProbe turns it into a Network-aware monitoring appliance.

Ravica offers nProbe as part of the nBox hardware solution to help you monitor your network.  nBox is an economical solution which is easily implemented.

If you would like more information about monitoring your network traffic with an nBox, give us a call.

~Angela
207-324-8173
Follow us on Twitter!
Find us on Facebook!

Luca and I talked about the nBox and its ability to export nearly 500,000 flows per second.  If you accompany the nBox with Scrutinizer NetFlow Analyzer to report on the IPFIX exports, you end up with an incredibly powerful reporting combination which includes reports on application latency as well as HTTP URLs.

The nBox NetFlow probe is usually configured to reside off of a spanned or mirrored port of a switch.  It receives the packets, creates flows, and exports them to the NetFlow or IPFIX collector.  It is exciting to be involved with this product, and Ravica is the largest nBox distributor of this NetFlow appliance in the USA and Canada.

For more information, please contact us.

Mike

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).

Here is a simplified look at the above 3 packet transaction:

TIME STAMP                                                PORTS                       TCP FLAGS

[pkt  1] 16:12:29.013422                     52525 -> 80                         SYN
[pkt  2] 16:12:29.013923                     52525 <- 80                        SYN/ACK
[pkt  3] 16:12:29.013945                     52525 -> 80                        ACK

Notice the time stamps in the flows above.  We used them to calculate latency below:

Client Network Delay = (16:12:29.013923 – 16:12:29.013422) / 2 = 0.501 msec / 2 = 0.25 msec
Server Network Delay = (16:12: 29.013945 – 16:12:29.013923) / 2 = 0.022 msec / 2 = 0.01msec

Above, we divided the time delta by two because we wanted to compute the network latency that we assume is half the round trip time.

Loaded with the above information, the nProbe exports the above millisecond values (.25 msec and .01 msec) as seconds and microseconds.  The seconds column is often rounded off to zero.  Below the values are displayed as collected by FlowView in Scrutinizer in a CSV export:

Notice above that the ACK and PSH flags are not seen because we only saved the packets relevant to our current topic.  The other packets that included the ACK and PSH flags were filtered out of the saved capture.

NetFlow logically ‘ands’ these flags together when exporting a flow.  The 209 packets involved with the first flow are seen below.

The reason the three flows above weren’t all part of one flow is because we are also exporting the URL (which will be the topic of another blog).  The short answer is that when you specify in the template that you want to see the URL, nProbe has to split HTTP/1.1 connections into various http requests.

Application latency is computed as the time needed by an application to react to a client request.  For TCP connections, application latency is computed on the first packet after three-way-handshake.

As with network latency, application latency is location dependent.  In theory, application latency is supposed to measure the time depicted in pink in the chart, but in practice it also measures the time depicted in green.  For this reason, latency measurements depend on where the probe is placed.  For accuracy reasons, it should be located as close as possible to the server in order to minimize the green time.  For certain protocols (e.g. ftp file transfer or video-over-ip), application latency cannot be computed because they are one way without client->server and server->client communications.

The nProbe has a Command Line Interface (CLI) for setting it up.  To configure our nProbe to export the data needed for this purpose, we configured it as follows:

nprobe -n 66.186.184.202:2055 -n 66.186.184.204:2055 -i eth1-t 60 -d 15 -u 3 -Q 4 -L 24.39.1.172/32 -r -V 9 -T”%IPV4_SRC_ADDR  %IPV4_DST_ADDR %IPV4_NEXT_HOP %INPUT_SNMP %OUTPUT_SNMP %IN_PKTS  %IN_BYTES %FIRST_SWITCHED %LAST_SWITCHED %L4_DST_PORT %L4_SRC_PORT  %TCP_FLAGS %PROTOCOL %HTTP_URL%SRC_TOS %SRC_MASK %DST_MASK %CLIENT_NW_DELAY_SEC  %CLIENT_NW_DELAY_USEC %SERVER_NW_DELAY_SEC %SERVER_NW_DELAY_USEC”

For further details on the open source NetFlow probe, visit Luca Deri’s NTOP’s website.  For nProbe pricing, visit our Online Store.

~Angela
207-324-8173
Follow us on Twitter!
Find us on Facebook!

If you have an nProbe, you can get latency from network flows captured by the probe.  The nProbe is an open source NetFlow probe developed by Luca Deri of NTOP.  It resides on a server and turns the traffic it sees into flows.

What is an nProbe?

Most companies that have implemented the nProbe use it for traditional NetFlow v5 information which can be collected and displayed by any NetFlow Analyzer.  However, the nProbe can export dozens of traffic details overlooked by most consumers due to the lack of ability to view the information.  This has changed thanks to Luca’s new formed partnership with Plixer International, the developers of Scrutinizer NetFlow and sFlow Analyzer.

Advanced features exported by the nProbe include email addresses, HTTP URLs, Latency and a whole lot more.  One of our favorites to monitor is latency.  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)

Below is what the data could look like in Scrutinizer:

Troubleshooting with Latency

Network delay is crucial for some online services such as SSH and transaction services. Monitoring latency cannot be performed using standard flow templates because latency cannot be estimated using information like bytes/packets and flow duration.

Application latency estimates the time needed by a server to react to a client request which is basically the time that a server needs to answer to client requests.

Both application latency and network delay should be constantly monitored in order to detect slow-downs that degrade the overall service performance.

Summary

The NetFlow probe allows collectors to provide customers with visibility of network performance by providing metrics for estimating the delay introduced by both the network and the server applications.  Location of the nProbe can be important.  Accurate application latency is best gained by locating the nProbe on the actual server of the application or on a probe near the server.

For more details details about the NetFlow probe functionality, you can read Part 2 of this blog.

Feel free to check out NTOP’s website for more information about the nProbe.  For nProbe pricing, visit our Online Store.

~Angela
207-324-8173
Follow us on Twitter!
Find us on Facebook!