I have an iSCSI performance problem. So I'm just going thru my checklist. One thing mentioned on page 336 is using IP ID to identify looping packets. So i did a tshark dump of the ip.id and created a Perl script to check for duplicates. Once I identified these I looked at the packets to see if Don't Fragment is set. I found a case where I have duplicate IDs and the DF is set. See displayed frames 10 and 11 of the following trace. I have a DF bit flag set and from the same host I'm seeing the same IP ID. Note the time display is set to display seconds since beginning of capture. As a matter of fact all of the packets displayed here have the same IP ID. But many of them don't have the DF flag set. Please advise if I'm missing something. But this doesn't look right. http://cloudshark.org/captures/bfd12b3b02d9 asked 04 Jun '12, 07:32  gipper |
2 Answers:
You will see "looping" packets, if they are forwarded between systems (e.g. router) several times, due to a routing loop. In that case you'll see the same packet (same IP ID, same src/dst IP, same ports, same SEQ/ACK, same payload) with different src/dst MAC addresses (those of the routers forwarding the packets). So, just looking for the same IP ID does not help to detect "looping" packets, as long as you ignore the other parameters of the packets. According to that definition of looping packets, there are only two matching pairs in your (stripped) capture file: Frame #1/#2 and #4/#5. Those are probaly just a (very fast) re-transmissions, or a problem during capturing the packets. Regards answered 04 Jun '12, 08:12  Kurt Knochner ♦ edited 04 Jun '12, 11:58 |
On the contrary - in my eyes and on a quick glance your trace does look quite normal (with big holes in it because of the filtering). I have no idea why you think that looking for packets with the same IP ID on a general scope would help you tracking a loop problem (unless it happens on a really large scale, but then it'd be obvious). The IP ID is usually (which means, there are some OSes that do it differently, e.g. OpenBSD) incremented by 1 for each new IP packet, and it has a 16 bit range - meaning, that after getting to the number 65535 it will start again at 0 and count up again. So if you wait long enough (and believe me, when waiting on a busy iSCSI transfer with tons of data being transfered it doesn't take long) you'll see the same IP ID over and over again. By the way, what "page 336" do you refer to? It's not much use to tell us a page number and not which book it is ;-) answered 04 Jun '12, 07:54  Jasper ♦♦ |
Sorry page 336 of Wireshark Network Analysis. Laura Chappel. So this IP ID which is a hex 4 digit number which can be up to 65,535 values to uniquely identify an IP packet could be the same number from the same host within 1.5 seconds would loop thru 64k values? That doesn't make sense.
see comment below (the one with the screenshot).
Thanks Kurt that makes perfect sense. Thanks for the help. I'm still trying to come up to speed on this.
it makes perfect sense. Here is an IO graph based on traffic in an iSCSI network.
This is just 2,6 Mbit/s and you see a wrap around of the ip.id after ~ 15 seconds. So, multiply that throughput by 10 (26 Mbit/s) and you will have a wrap around after 1,5 seconds. The IP.ID in the capture was increased in steps of 6!! in this sample (OS dependant).
Let's also calculate it:
800 is the arithmetic average of the packet size (please consider data + ACK + other).
That's the amount of data needed for a wrap around. Divide that by the number of seconds and you get the required throughput. 419 Mbit / 1,5 s = 279 Mbit/s. Not so uncommon in a iSCSI network. If you change the arithmetic average, the number will change! Some OS increase the value by 2,4 or 6. You will get an even faster wrap around.
Regards
Kurt