This new PF_RING 4.7.0 includes 10 Gbit DNA driver (Direct NIC Access) support at both RX and TX. This means low-end Linux servers can now manipulate packets at 10 Gbit wire speeds with the help of a 10Gbit ethernet card. With this speed you can process traffic as well as capture it at ease.

Luca Deri has tested this on a VM with only one core dedicated. Silicom displayed it’s support by providing Luca with the PE10G2SPi-SR Dual Port Fiber 10Gbit adapter card. You might be surprised at the results on ntop.org. Stay tuned for any further releases from ntop.

• Fields-   Example Data
• Client-   192.168.1.92
• Server-   www.ravica.com
• Protocol-   HTTPS
• Method-   GET
• URL-   /img/screenshots/nbox-m.jpg
• HTTPReturnCode-   200
• Location-   http://www.ravica.com/about/index.php
• Referer-   Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us)
• UserAgent-   AppleWebKit/533.21.1 (KHTML, like Gecko)
• ContentType-   Version/5.0.5 Safari/533.21.1 image/png
• Bytes-   76281
• BeginTime-   1307007397.970
• EndTime-   1307007398.624
• Flow Hash-   1142612386
• Cookie-   51510
• Terminator-   C
• ApplLatency-   0.159

A few things to keep in mind when using this for network traffic monitoring: This will only decode your traffic, so you need to have your own private key. Also, it is only available on Unix right now.

If you have questions on the above, please give us a call and we’ll have you get setup with your NetFlow collector.  This deep traffic insight will take your network traffic analysis to another level, but remember your netflow or IPFIX analyzer must be setup to report on this data.

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!

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.

Additional Details:

• e8.85.7bae.static.theplanet.com is a server on theplanet.com domain – but doesn’t host theplanet.com website.
• e8.85.7bae.static.theplanet.com does not resolve to anything – there is no forward DNS entry for this name.
• 174.123.133.232 resolves to e8.85.7bae.static.theplanet.com – there is a reverse DNS entry, also known as PTR record, for this IP address.

Trashminer.com Details:

• Trashminer.com is a website hosted on 174.123.133.232 who’s reverse DNS entry is: e8.85.7bae.static.theplanet.com.
• Trashminer.com will need a forward DNS entry of 174.123.133.232 so that users will be able to find the server that hosts the website.

DNS Overview
A forward DNS lookup (uses an A record) is using an Internet domain name to obtain the hosting server’s IP address. An A record gives you the IP address of a domain. That way, users that try to go to www.example.com will get to the right IP address.

A reverse DNS lookup (uses a PTR record) is using an Internet IP address to find a domain name. In short, a user has an IP address and wants to know what the host/domain is.

Scrutinizer NetFlow Analyzer is performing reverse DNS lookups; therefore, a single domain name, typically the server hostname, will be returned.

There can be many A records for the same server. One reason for this would be web hosting. This will allow many different domains to reply with the server IP for which their site is hosted on; however, there can only be 1 PTR record for that server.

You might be wondering if you could do the same thing with sFlow reporting. Yes, but not if the switch didn’t sample the packet. In my experience, most of the time it doesn’t capture the one I wanted.

So, I hope this 2 part series helped you understand more about the nProbe, URLs via NetFlow and something about DNS entries.

Jon Mills
Follow Me on Twitter