Protocol Analysis, Data Recorder, CALEA, Lawful Intercept, Application Performance, User Experience, Industrial Ethernet, Data Loss Prevention, Deep Packet Inspection, NetFlow, SOX, HIPAA and PCI Compliance, Switching and Routing, Forensics, VoIP, IPTV ... etc.
We have come up with some great add on's and upgrades to our Win-UFO program. We have restructured the layout of the report to make it more printer friendly. We are listening to your suggestions and hope that this tool helps many. Please consider making a donation by clicking the donate button on our web site or by clicking it in the program. http://www.win-ufo.org
One of the toughest things to do when analyzing packets is documentation.
I rely on my Tracefile Workbook to make notes when I need to reference a specific packet or event.
Wireshark added a pretty cool feature to help with this process. It is called the Annotation feature. There are 2 different types of annotation; File and Packet.
The File annotation allows you to make some notes regarding the trace file itself. A good example of items to note would be things like recording the test environment, use of span ports, what is being tested or finally a description of the issue.
The Packet annotation allows you to make notes within specific packets. For example you might want to make a note on the packet that caused the application error, or mark the packet that represents when the client clicked submit.
One of the more complicated steps when troubleshooting a network or application performance problem is capturing and reading traffic off the wire. We’re in a switching world today, which makes forwarding network traffic to an analyzer difficult. Traffic is usually isolated between two ports on a switch, leaving the network analyzer blind if it is plugged into a regular switch port.
Until now, there have been three basic ways to capture traffic in a switched environment, and each has it’s pros and cons:
1. Span/Mirror port on switch 2. Tap inline between server and switch or on key link 3. Hub on client end of connection
These three methods have been used industry-wide to collect traffic on a switched system.
IPv6 could be awesome but it is getting scary, Why?
I do not dislike IPv6, but it seems a scary transition, at this time…It has some great attributes but it has gotten out of control – where IPv4 was easy to implement and was a few steps higher than the previous version, IP Before (IPv4 )as I call it …..
IPv6 is like stepping out of an airplane at 50000’ with no parachute - It is a VERY long drop!
Currently the landing is the killer! Where will it lead us?\
Starting I do not like the fact that from the network and processor views running dual stacks eats up processor, bus and network time and traffic not to mention adding complexity to all of our current applications and communications.
I was on the IPNG and IPv6 committee back in the 90’s and I was and am an advocate for IPv6 deployment, I do not feel we have a choice! That being said we have created a BIG MESS thus hindering any easy or even reasonable deployment for IPv6. I am sorry to say but all one has to do is look at the standards and there are a bunch of them to fully understand the impossible complexity to a successful and safe deployment. BUT - I still feel we have created a giant that is NOT movable and if we do not rethink it we may never see it deployed!
I love capturing packets with my laptop – all the tools are set up the way that I need them. However, I know that it’s no longer a tool that I can use in a next-gen network. New data centers are being designed with non-blocking L2 ECMP architectures like Leaf-Spine and Clos ( Leaf-Spine video from Brad Hedlund and an IEEE ANTS Presentation PDF by Malathi Veeraraghavan U. of VA.), where it’s difficult to answer the #1 question for sniffing: where do I plug in to capture the packets I need?
What makes this more difficult is the speed of these links. It’s increasingly common to find 10G to servers and 40G in the fabric between the switches. There’s no way my laptop can keep up with those speeds. What we need is a way to have visibility baked into the network. This post will explore a few emerging methods.
I’ve been preaching the benefits of standardized and consistent testing for as long as I can remember.
If you are part of a team with multiple tools available, the first challenge you face is which tool to use in certain scenarios. Then the harder part – what tests and feature do I use? Better question; do you remember how you used it and the various settings you configured for that last report?
You might be a seasoned veteran and you know the various options of your favorite troubleshooting tool but what does the new guy do to get up to speed?
The same scenario can easily apply if you are a one man shop and haven't used a tool for a while and forget how you tested or configured that tool.
This is precisely why I favor tools where I can save my test criteria. In the past I have even showed you how I use batch files to ensure the tests are performed consistantly.
You haven’t missed something if you noticed that I haven’t mentioned saving your results. That’s an obvious feature and I havent seen a tool out there that cant save its test results. Lets face facts, if the test settings are incorrect, the results are irrelevant and not worth saving.
In this video I use Fluke Networks AirMagnet WiFi Analyzer to perform a site survey or validate an installation.