388 posts categorized "Tony Fortunato" Feed

IP Subnet Wireshark Display Filter (by Tony Fortunato)

When asked for advice on how to be a proficient protocol analyst, I give 2 pieces of advice;

  1. Practice looking for patterns. In most cases, you are looking for patterns, or a break in the pattern.  Don’t worry about memorizing the RFC’s or learning about every protocol. It is easier to focus on whatever protocol you are working on at that time.
  2. Learn your display filters in whatever your protocol analyzer you use. The correct display filter will make the patterns jump out at you.

I caution analysts about going capture filter crazy. Unless you know exactly what you are capturing, I typically try to leave the capture filter as ‘open’ as possible. My concern when troubleshooting is that due to the very nature of the unknowns when troubleshooting, you may inadvertently filter out valuable packets.

I great example is you may decide to use a capture filter for a web server ip address when capturing from the client. In this scenario you would miss any packets from the router or other devices along the way if they send the client an ICMP error packet or if the client communicates with other servers.

In this example, I show you that the ip.addr display filter can be used for a subnet.  You are probably familiar with this filter when filtering on a single device. What do you do if you need to filter on more than one host? The typical approach is to combine the ip.addr filter with an or. For example ip.addr== or ip.addr== is one way to capture from two hosts.

Now let’s take this a step further. What would you do if you wanted to capture from all addresses on a server farm or client subnet?  I’ll make this a touch more realistic and add that you don’t know the all the IP addresses on the other subnet.  This is where the subnet/mask option comes in.

You can simply use that format with the ip.addr == or ip.addr eq display filter. If I wanted to display the IP addresses from the to, my filter would be ip.addr == or ip.addr eq  The mask does not need to match your local subnet mask since it is used to define the range. If you wanted to display all the packet from –, my display filter would be ip.addr ==




Continue reading other LoveMyTool posts by Tony Fortunato »

The Bootup Baseline (by Tony Fortunato)

Since 1995, I have been promoting the idea of a “Bootup Baseline”. The exercise is very straightforward, you power on a device and capture all the packets generated.

I want to take a moment to explain what we will not cover. As you look at the packets you will see several types of traffic:

  • Unicast to the bootup device. This is what we want to focus on
  • Broadcast or Multicast from other hosts. We will ignore these for the most part.
  • Flooded traffic. These are unicast packets that are addressed to other hosts that are on your switch port. This is good to note and possibly take aside to determine why it is happening and of its ‘normal’.

The traffic gathered is there for only two reasons; either the host transmitted them, or the devices on the network sent them back to the booting host.

The most important step in this process is to document how you captured the data. There are many ways to capture packets from a booting device, but the most popular are:

  • SPAN or port mirroring. Since we are not concerned with capturing errors or timings, this works well. The most convenient if you have proper access to the switch.
  • In my opinion this is the best way but it requires you to be physically close to the device and you have to break the connection to that device.
  • 10/100 Hub serves the same purpose as a TAP but no full duplex, fibre or 1 Gb support. We are only interested in the details of the traffic and not timings this works in a pinch. Ensure that the switch port connected to the hub is properly configured to support half duplex.

Continue reading "The Bootup Baseline (by Tony Fortunato)" »

LMTV LIVE | How to Improve Compliance Activities for IT (with Keith Bromley and Timothy Jones)

Upcoming LMTV Event on How to Improve Compliance Activities for IT


There is a new LMTV event happening on April 11, 2018. Keith Bromley from Keysight Technologies (formerly Ixia) and Wayne Dixon from ForeScout will be talking about how to use network visibility to improve regulatory compliance. While regulatory compliance is an important activity for medium to large businesses, easy and cost-effective solutions can be difficult to find.

Network visibility is an often overlooked, but critically important activity, that can help lower costs and make life easier for IT personnel working on compliance requirements. Solutions like network packet brokers (NPBs) allow you mask sensitive data, perform packet slicing, implement lawful intercept, and discover rogue IT. Purpose-built compliance solutions can also use data filtered by NPBs to perform activities better and also allow IT to demonstrate their regulatory compliance in an easy manner.

Continue reading "LMTV LIVE | How to Improve Compliance Activities for IT (with Keith Bromley and Timothy Jones)" »

LMTV LIVE | Meet the Ekahau Geeks (with Tony Fortunato and Tim O'Neil)


Join Tony Fortunato and Tim O'Neill Wednesday April 4 at 9:30 Eastern as they interview the geeks from Ekahau (https://www.ekahau.com).

Jerry Olla, Jussi Kiviniemi and Joel Crane will be discussing WiFi tools and common Wifi issues that they see out there. Why is Wi-Fi often so bad? What can we do about it? What does bad, and good Wi-Fi look like?

We will also see live demos of their brand-new Wi-Fi design and troubleshooting hardware and software tools.

As Tim O’Neil says, “WiFi is now an essential part of your corporate network infrastructure! Learn from experts on how to monitor, manage and secure.”

Ekahau upcoming event 

2018 Cisco Geekfest

May 8th - 10th, 2018
Chicago, IL 

Some Easy Ways To Improve Network Troubleshooting (by Keith Bromley)

Some Easy Ways To Improve Network Troubleshooting

Author:  Keith Bromley, Senior Solutions Marketing Manager, Keysight Technologies 

According to the Enterprise Management Associates report, Network Management Megatrends 2016, IT teams already spend around 36% of their daily efforts on reactive troubleshooting efforts. This is for good reason. Network and application troubleshooting can be one of the most high-profile and aggravating activities there is for IT personnel. Pressure increases exponentially on IT personnel as problem resolution times increase, since this directly correlates to network and application slowness and downtime.

This blog post, a video podcast, and an ebook provide suggestions on how you can improve your troubleshooting activities. The first thing you will want to do to reduce your troubleshooting time is to implement a visibility architecture. A visibility architecture is an end-to-end infrastructure which enables physical and virtual network, application, and security. Improved visibility is what allows you to optimize your network data capture and analysis techniques. A visibility architecture typically yields immediate benefits such as the following:  eliminating blind spots, improving data flow to security tools, and maximizing network and tool availability

Specifically, there are three layers to a visibility architecture. The first layer is data access. This is where you will want to insert taps into the network between the network data flow and your monitoring tools (or network packet broker) to improve the quality of monitoring data and time to data acquisition. Once the tap is installed into the network, it is a permanent and passive device that gives you data access. This means you don’t have to ask the Change Board for permission to touch the network again. You touch it once to install the tap and then you are done.

The second layer is the monitoring data manipulation layer. This is where you will want to deploy network packet brokers (NPBs) between those taps and the security and monitoring tools to optimize the data sent to the tools. After that, you can perform data filtering, deduplication, packet slicing, header stripping, and many other functions to optimize the data before it is sent to your tools. Just by implementing taps and NPBs, it is possible to reduce your mean time to repair (MTTR) by up to 80%. A significant portion of that time reduction comes by the reduction (and probable elimination) of Change Board approvals.

Continue reading "Some Easy Ways To Improve Network Troubleshooting (by Keith Bromley)" »