Interesting Traces - Ping Failure

Blue Bar separator


The following ping output from a Stratus VOS system would imply that the 192.168.12.9 host was not responding to the ping packets.

VOS>ping 192.168.12.9                                                                          
Pinging host 192.168.12.9 : 192.168.12.9
ping: No reply. Time Out !!
ping: No reply. Time Out !!
ping: No reply. Time Out !!
ping: No reply. Time Out !!
Host 192.168.12.9 replied to 0 of the 4 pings
ready  20:48:13
VOS>

The following trace implies that it is. There could be many reasons for the VOS system to not see the replies.

  1. The trace could have been taken on a network other than the source's 192.168.1.0 local subnet and the replies lost after that - Nope
  2. The source's NIC was experiencing errors and the packets discarded - not according to the Ethernet chip statistics
  3. The reply's are corrupt and failing a IP or ICMP checksum test - wireshark did not report any checksum errors and the statistics on the VOS system do not indicate any checksum errors
  4. The ping replies are not for the ping requests - thats it.
While each ping reply follows a ping request the Identifier field in the replies does not match the field in the requests. As a result VOS cannot match the replys to the requests and the pings time out.

No.     Time           Source                Destination           Protocol Info
      1 0.000000000    192.168.1.137         192.168.12.9          ICMP     Echo (ping) request
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0 ()
    Checksum: 0x4bb3 [correct]
    Identifier: 0x0000
    Sequence number: 11437 (0x2cad)
    Data (64 bytes)

      2 0.050319672    192.168.12.9          192.168.1.137         ICMP     Echo (ping) reply
Internet Control Message Protocol
    Type: 0 (Echo (ping) reply)
    Code: 0 ()
    Checksum: 0x8d64 [correct]
    Identifier: 0xc64e
    Sequence number: 11437 (0x2cad)
    Data (64 bytes)

      3 15.000925064   192.168.1.137         192.168.12.9          ICMP     Echo (ping) request
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0 ()
    Checksum: 0x4bb3 [correct]
    Identifier: 0x0000
    Sequence number: 11437 (0x2cad)
    Data (64 bytes)

      4 15.050540924   192.168.12.9          192.168.1.137         ICMP     Echo (ping) reply
Internet Control Message Protocol
    Type: 0 (Echo (ping) reply)
    Code: 0 ()
    Checksum: 0x8d64 [correct]
    Identifier: 0xc64e
    Sequence number: 11437 (0x2cad)
    Data (64 bytes)

      5 30.001644134   192.168.1.137         192.168.12.9          ICMP     Echo (ping) request
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0 ()
    Checksum: 0x4bb3 [correct]
    Identifier: 0x0000
    Sequence number: 11437 (0x2cad)
    Data (64 bytes)

      6 30.051267624   192.168.12.9          192.168.1.137         ICMP     Echo (ping) reply
Internet Control Message Protocol
    Type: 0 (Echo (ping) reply)
    Code: 0 ()
    Checksum: 0x8d64 [correct]
    Identifier: 0xc64e
    Sequence number: 11437 (0x2cad)
    Data (64 bytes)

      7 45.002258301   192.168.1.137         192.168.12.9          ICMP     Echo (ping) request
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0 ()
    Checksum: 0x4bb3 [correct]
    Identifier: 0x0000
    Sequence number: 11437 (0x2cad)
    Data (64 bytes)

      8 45.051847458   192.168.12.9          192.168.1.137         ICMP     Echo (ping) reply
Internet Control Message Protocol
    Type: 0 (Echo (ping) reply)
    Code: 0 ()
    Checksum: 0x8d64 [correct]
    Identifier: 0xc64e
    Sequence number: 11437 (0x2cad)
    Data (64 bytes)

Now the question is why do the replies not match the requests. Tracing each leg of the network it was determined that an F5 BIG-IP running the Local Traffic Manager application release 9.1.3 Build 39.0 was changing the ICMP packet before it forwarded it on to the 192.168.12.0 subnet. The 192.168,12,9 host saw the ping with the changed Identifier field and correctly responded to the ping that it received. It appears that the F5 device only makes the change only when the Identifier field is zero, non-zero fields are not changed.

Since the F5 device correctly updates the checksum in the ICMP and IP packet headers I have to assume that it is changing the Identifier field on purpose although I do not understand why. According to the Internet Control Message Protocol RFC (792) the Identifier field may be 0. If the device felt that the ICMP packet was invalid I could understand it discarding the packet but I do not understand why it would change it.

Blue Bar separator
This page was last modified on 08-08-19
mailbox Send comments and suggestions
to ndav1@cox.net