Fast Pinger

Let’s talk about one of my favorite tools: Fping.exe

Fping mostly works like the well known ping command that’s available in every windows/unix/linux OS, but gives you some more options that make it a tool to use when testing failover technologies in your network.

Let’s look at the additional options from the fping.exe command that aren’t available from the ping.exe command :

-S : size sweep. Ping with size1, size1 + 1, ..., size 2 datalength

One might wonder when this option is useful. Have you ever tried to determine the MTU of a particular network? Testing it with best guesses using the “-f don’t fragment flag” option combined with the “-l ” option in the ping command? Here’s how to determine the MTU using fping.exe in a single command:

Fping 10.0.0.1 -S1400/1500 –t1 –f


The output speaks for itself! Another option (I already used in the previous example) is:

-t : time between 2 pings in ms up to 1000000

The “-t” options let’s you specify the time between 2 pings. This is particular useful for speeding up the whole process in combination with the “-c Continues Ping” option. To demonstrate this I’ll use a third cool option, which is:

-D : print datestamp and timestamp with each reply

Also available with only the time information:

-T : print timestamp with each reply

Using the ”–D” of “-T” options I can show you what the speed difference is when using the “-t” option.

First off, let’s ping a host 5 times without the “-t” option:

Fping 10.0.0.1 –n5 –D


As you can see, default behavior is sending 1 ping every second (look at the timestamps). Now, that’s not really fast, is it? Now let’s ping a host 200 times with the “-t” option:

Fping 10.0.0.1 -n200 –t1 –D


In the output you can find that it’s possible to send approximately 150 (reply 7 – reply 156 are all within 1 seconds (21:25:48)) ICMP packets per second using the “-t” option. So when checking failover mechanisms, this ping tool will most definitely show more detail of the outage than the regular ping tool.

A relative new option is:

-j : print jitter with each reply (only when pinging one host)

This option also shows the jitter on the network:


Being able to test for excessive jitter can help a lot when troubleshooting voice-over-ip networks.

The last option I would like to bring to your attention is de “-L ” option:

-L : logging to a text file

With this option you’re able to also log the output to a textfile. The ‘also’ means that with the normal ping command, as with every command utility, you’re able to redirect the output to file instead of the display, but not to show the output on screen and also log it to file.

You can download this utility at kwakkelflap.com. Check it out!

Sniffing dot1Q tags with wireshark

Ok, so here's the issue. When testing some QoS settings on a customers network I wanted to verify layer-2 QoS (CoS) using Wireshark. I've done so many times, but recently I got a new laptop (HP Elitebook 8530P) and I noticed that no matter what I configured in the monitor session, no dot1q tag would appear in Wireshark.

Today I created a small testlab which you can see below.


I configured the following SPAN session:

monitor session 1 source interface Fa0/23
monitor session 1 destination interface Fa0/24 encapsulation dot1q

I sniffed some ICMP packets originating from FW1 towards FW2, which gave me the following Wireshark output:


Clearly no dot1Q tags present in the captured data.....

After some searches on the web I found out that newer drivers strip off tags like dot1Q by default and therefore are not available to upper layers in the OSI-model.

In my case it concerns an Intel 82567LM Gigabit Adapter which, luckily for me, has the possibility to turn off this 'strip off' feature by setting the following registry key: MonitorModeEnabled, value 1, type DWORD, at the following location:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\00xx


The '0007' part of the registry location may differ from laptop to laptop. You can check by looking at the DriverDesc string in each folder.

After a quick reboot I did the same test as earlier with the output below:


YES! It's working again like it should. The yellow circle shows the CoS value and the blue circle shows the VLAN-id. Time for some QoS testing next week....

Welcome!

Welcome to this new blog! Obviously there's not much to read.....yet! Stay tuned and I'll try to write articles on a regular basis regarding networking and network security.