In this post, we'll use Wireshark to identify DNS server response times. We'll start by using Wireshark to open a network capture of a simple DNS request. Using the DNS analysis tools built into Wireshark, we'll calculate the time it took for the response to come back from the server. Once we've done that, we'll walk through creating a filter to display DNS response times that take longer than expected. How Does DNS Work? First, it's important to have a high-level understanding of how DNS works. DNS is an address resolution protocol that allows systems to translate a friendly hostname to an IP address that the TCP/IP stack can use. DNS primarily uses UDP port 53 as the transport protocol and port for hostname resolutions. There are occasions when DNS will use TCP for name resolution. Typically, TCP is only used when the response size is greater than 512 bytes or if the request is actually a zone transfer. For the purposes of this post, we'll only focus on UDP. Calculate DNS Response Time Wireshark natively calculates the response time of DNS servers for us. To view DNS traffic in your capture, use this filter: dns This will display all DNS traffic (both TCP and UDP) in your capture. Once you've displayed the DNS queries, you can display the DNS server response times in a column. This GIF shows how to add the DNS response time column to Wireshark: Add DNS Response Time Column to Wireshark: Once the column for DNS response time is added, you are able to sort by that column. This will allow you to view the longest and shortest response times. Wireshark Filter to Display High DNS Response Times: Since Wireshark calculates the DNS response time, we're able to build filters based on these times. This would…

Application and network performance monitoring tools offer several metrics and counters intended to give you an indication of the health of your infrastructure and applications. With the wealth of data and options available in these tools, it can be difficult to know what's important and what can safely be ignored. In this post, we’re going to identify some of the TCP metrics that will provide a baseline for your monitoring strategy using on-the-wire network data. THE METRICS Connection Setup Time Server Connection Reset rate Application Response Time Retransmission Rate Network Round Trip Time Why were these metrics chosen? First, they are accessible. Most modern packet-based performance management tools are looking at and keeping a count of these metrics. Second, they offer a broad indication of the health of the server, network, and application infrastructure. That's not to say that this is an exhaustive list. Depending on your architecture and application, there will be several other metrics you should be watching. These items are intended to be the building blocks on which you can develop a fully matured monitoring infrastructure. Connection Setup Time Indicates: Server Health Network Health Definition: Connection setup time is the amount of time it takes for the TCP three-way handshake to complete. When this metric spikes, it can be an indication of network slowness or an increase in the processing time within the TCP stack of a server. This metric is best monitored with a deviation from normal mindset. We’re most interested in servers that have a higher connection setup time than others. We also want to be notified when a server’s connection setup time increases dramatically from normal. Server Reset Rate Indicates: Server Health Application Health Definition: Server reset rate is a per-second counter that increments as TCP resets are sent by the server. A TCP reset…

In this post, we're taking a look at a method for improving the visual appeal of the Wireshark IO Graph. The IO Graph in Wireshark is fantastic for getting the bare information out of the tool to communicate to others. In some cases though, we need to provide that data in a more visually appealing manner. We'll be using an online tool called amCharts to create our graphs using data form Wireshark. There are several other online charting tools like amCharts. I encourage you to give some of these a shot too: ChartBlocks JSCharts What is amCharts? AmCharts is an advanced charting library that will suit any data visualization need. Our charting solution include Column, Bar, Line, Area, Step, Step without risers, Smoothed line, Candlestick, OHLC, Pie/Donut, Radar/ Polar, XY/Scatter/Bubble, Bullet, Funnel/Pyramid charts as well as Gauges. Our charts is a completely standalone and independent library, which doesn’t require any 3rd party includes. You can download, try and even use our charts for free. Check chart demos to see all the charts in action. AmCharts allows us to quickly upload any type of CSV data to be displayed. In our case, we'll be using output from Wireshark. The interface of amCharts then gives us endless flexibility to modify and present our data. Wireshark IO Graph vs. amCharts Let's take a look at the below screenshots. These charts display the same information - the count of HTTP packets sent, as well as the count of TCP retransmissions. As we can see, the default display of data out of the Wireshark IO Graph is not ideal. It's limited in presentation options, and honestly is an overwhelming amount of buttons and knobs. The amCharts chart, however, is clean, concise, and easy to read. Creating a Chart In this example, we will be creating the chart above using…

As network engineers, our lives revolve around making sure data gets from point A to point B. Fortunately for us, TCP does a great job of ensuring this happens for us without much intervention. Unfortunately, we need to step in every once in a while to make sure things are going as we designed. That said, let's talk about TCP retransmissions. I'm going into this post with the assumption that we all understand what a retransmission is, and that TCP retransmissions could be a symptom of a problem - but not a cause. With this post, I want to share how to provide a visual reference of the count of retransmissions over time. The idea is that if the retransmissions are charted out, they are easier to compare to things like spikes in throughput, error count increments, or even server CPU/memory utilization. Identifying TCP Retransmissions in Wireshark The first step is to identify the retransmissions within the packet list with this filter: tcp.analysis.retransmission Once we have this filter applied, we can begin to see how many retransmissions we're seeing in the trace. It's important to note that there is no flag or unique identifier associated with a TCP retransmission. Wireshark calculates TCP retransmissions based on SEQ/ACK number, IP ID, source and destination IP address, TCP Port, and the time the frame was received. It's very easy for Wireshark to count a duplicate packet as a retransmission. Make sure you haven't captured the same frame twice. This is very common in data center capture architectures. If you open a trace file and see something that looks like the below screenshot, you'll want to review the process for removing duplicate frames here. 157

In this post, we'll use Wireshark to identify HTTP server response times. We'll start by using Wireshark to open a network capture of a simple web request. Using the HTTP analysis tools built into Wireshark, we'll calculate the time it took for the response to come back from the server. Once we've done that, we'll walk through creating a filter to display HTTP response times that take longer than expected. Finding HTTP Response Time The HTTP response time is calculated and displayed in the HTML dissector. In this example I made a request to http://i.imgur.com/OAEsnJh.jpg. Let's take a look at what this looks like in Wireshark: In this first screenshot, we establish the TCP connection with a three way handshake, then the browser requests the image with an HTTP GET request. The data is transferred from the web server to the client, then sends an HTTP response of 200 OK. This indicates the requested action was successfully completed on the web server (see the pink highlight below). 45

The purpose of a network visibility architecture is to provide a method of access for security, analysis, and performance tools to access the data traversing your network infrastructure. These appliances are incedibly valuable to your organization, however they are only as effective as the data they are seeing. This post is intended to provide a framework to design a visibility architecture that can support the tools you currently have as well as scale to support the tools of the future. There are five key considerations that a visibility architecture should address. Along with these considerations, your design should adhere to a well defined, repeatable approach that can be translated across all environments with minimal architecture changes. Adhering to these principles allows for a supportable architecture that is easy to maintain and cost effective to deploy. The five key considerations: Provide shared access Wire-speed, reliable transport Scalability Cost Simplicity The Three Tiers - Acquisition, Aggregation and Intelligence A good way to visualize the design of your visibility architecture is a hierarchical, three tiered approach. Those tiers are acquisition, aggregation, and intelligence. Each layer defines a separate role within the visibility infrastructure and contributes individually to the five key considerations above. Let's dive into each role to get a better understanding of it's place in our architecture. 74

This post is part 1 in a series of posts on trace file anonymization/sanitization. In this series, I will be focusing on three individual tools that each accomplish capture file anonymization. The general use of capture anonymization is to allow capture file owners to obfuscate potentially sensitive data within the files to prepare them for consumption in a non-secured environment. Most likely scenario would be preparing a trace to send to a vendor or consultant. There are differing levels of sanitization within a trace file ranging from removal of .pcap metadata (comments within .pcapng files) all the way to the removal of all payload data after layer 4 and total randomization of any other potentially identifiable information within the frame. The three tools I'll be focusing on in this series are: TraceWrangler tcprewrite from AppNeta SCRUb-tcpdump TraceWrangler TraceWrangler is a GUI based trace obfuscation tool built exclusively for Windows. It supports .pcapng file formats as well as .pacp and .cap. At the time of writing, the last development release was in Sept. 2013. In this exercise, I will work through a basic process of ingesting a trace file, anonymizing the IPv4, IPv6, and MAC addresses within the capture, then exporting it to a sanitized version of the file. In this case, we are required to keep the payload data of an HTTP request. These steps will not remove any potentially sensitive data within the payload, however TraceWrangler has the capability to do that. I would encourage you to check out the documentation to understand that process. Let's start with our initial capture file. In the screenshot below, you can see that my original IP addresses, as well as MAC addresses are visible. My host: IP - 192.168.0.10 MAC - 24:77:03:0c:ca:9c Remote host: IP - 192.167.20.246 MAC - 40:8b:07:ab:38:80 Now let's fire up…

Let's take a quick moment to work through the steps of cleaning out a trace file that contains duplicate packets. This screenshot is of a capture with a duplicate of every frame in the trace. A couple things can cause this - switch VLAN SPANs are a common cause. Another possibility is tapping in multiple locations within a stream. What's Happening Here In the example above, you can see that Wireshark is interpreting each duplicate packet as either [TCP Out-of-Order], [TCP Dup Ack], or [TCP Retransmission]. This is standard behavior and really is just a very literal interpretation of what's happening in the trace. Let's walk through the trace to explain this more: (Frame No. 1) First SYN comes from the source to destination. (Frame No. 2) This frame is a duplicate. Wireshark expects the next frame from this host to have an increased sequence number from 0. Since the switch sent the same frame immediately, the second frame still has a Seq number of 0, Wireshark labels it as Out-of-Order. (Frame No. 3) This is the SYN/ACK from the destination. (Frame No. 4) This frame is a duplicate of frame 3. Again, Wireshark expects the frame after frame three coming from this destination to have an incremented sequence number. Since it doesn't, it is labeled as out of order. This process continues on throughout the trace with the frames being labeled as either [TCP Dup ACK] or [TCP Retransmission]. How Can I Fix It?! There are a couple options for editing your trace file after it's been collected. Wireshark Display Filter The first option is to create a Wireshark display filter that will filter out frames that match the Out-of-order, Dup ACK, and Retransmission criteria. This option will filter out all traffic that has these flags set. Use this…

Welcome to WordPress.com! This is your very first post. Click the Edit link to modify or delete it, or start a new post. If you like, use this post to tell readers why you started this blog and what you plan to do with it. Happy blogging!