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

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

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

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!

The problem with reporting on NetFlow latency details is that most IPFIX Analyzers (NetFlow Analyzer) ignore this new information from the nProbe.  Scrutinizer NetFlow Analyzer from Plixer is making use of this new export.

Using the Flow Analytics add on, I was able to configure a threshold to monitor any DNS traffic (UDP Port 53) with an application latency greater than 9 seconds. Check it out:

Flow Analytics is constantly monitoring for this threshold.  When  a violation occurs, the message is placed in the Alarms tab.

Ultimately, the combination of using nProbe to generate the NetFlow data and using Scrutinizer to collect and report on that data produces a simple yet detailed ability to monitor network latency.

Contact Ravica if you would like to evaluate the new nProbe.

Mike
207-324-8173
Follow us on Twitter!
Find us on Facebook!

The above is useful, but I wanted to narrow in on the hand held devices.  Specifically, I wanted to find out how much traffic is placed on the network when a person streams a NetFlix movie to their hand held. 

So I decided to setup another nProbe.

In my configuration, the uplink from the Enterasys switch is spanned (i.e. mirrored) to an nProbe.  The nProbe exports IPFIX (i.e. the proposed standard for NetFlow) and can include the MAC address among other things in its flow exports.  Using the new Advanced filter option in Scrutinizer NetFlow Analyzer.   I filtered for the first 3 octets of the MAC address of the iPhone 3GS and iPhone 4 phones (60:33:4b & 64:b9:e8):

Immediately after adding the filters, I saw the traffic I wanted to narrow in on:

Wow, 700K per second or 161 Megabits (over 20 Megabytes) in 3 minutes just from streaming a single NetFlix movie!

I decided to add the High Tech Computer (HTC) vendor IDs so that I could see the Android traffic as well:

I knew this was going to be one of my favorite reports to show people so I saved the report and then added it to the dashboard in MyView:

You can also export MAC addresses using Cisco’s Flexible NetFlow technology.  However, if you don’t have a Cisco router where you need one, contact us for an nProbe.

207-324-8173
www.Ravica.com 
Follow us on Twitter!
Find us on Facebook!

Luca Deri founded ntop in 1998 because he wanted to solve his employer’s network monitoring problems but had no tool to provide simple and efficient answers.  Through ntop, he offers nProbe and nBox to serve as visual insight into network utilization. 

Cisco’s NetFlow and sFlow are collected by nProbe, providing flow monitoring views and holistic understanding of traffic trends. nBox is a hardware device preloaded with nProbe, used as a probe and collector at the same time.  nBox is the option for those who don’t have an available PC for nProbe or who prefer the small nBox device with low cost, web interface, and remote maintenance.

Without question, knowing your traffic flows leads to improved time to resolution and can help with any necessary configuration restructuring.  Having this information is no longer a luxury for Network Managers; it is a need.

nProbe and nBox offer extremely cost-effective solutions for businesses who desire better visibility into their networks.

Ravica offers the availability of economical nProbes and nBoxes which are both easily implemented.  nProbe generates NetFlow v5 and v9 for fast Ethernet or gigabit Ethernet networks.  nBox is a simple embedded hardware solution containing nProbe.  Systrax.com has a great blog to help configure nProbe to send NetFlow.

For more information on how nProbe and nBox can help you monitor your IT world, call or visit Ravica today.

~Angela
207-324-8173
www.Ravica.com
Follow us on Twitter!
Find us on Facebook!