A colleague of mine has sent me this strange PCAP file. He has taken a PCAP file on a core switch and capture the ping packets from my PC to a remote device. The first ICMP echo msg gets an echo reply. But then a third echo request is sent (without any reply found in the trace). Take a look at the negative timing of this packet... This schema does repeat indefinitely. Any idea about the potential cause of this strange behaviour ? |
I suspect packet three is a duplicate of packet 1. Notice the TTL: packet 1 is decremented (127 instead of 128). What is the span or mirror port setup? I would suspect two source ports into a single destination. I can replicate something very close, except for the specific timing. With a poorly(*) configured port mirror or span setup on my switch/router, I can end up with the same as you have: The ttl change is telling in that you crossed a router so it is not likely a layer2 loop or anything like that; the specific configuration for this is to configure a router with mirror port capability and then:
There are probably other ways to get this. The timing is dependent on a lot of things. I have seen Cisco span ports mirror packets out of order (obvious to see when it happens with TCP). This diagnostic feature is usually lower priority than other device functions, so you never really know how that will affect the timing. What happens when we mirror two 1GB ports into a single 1GB destination? Not good things... Also the negative timestamp is common for me when I capture on two separate interfaces at the same time. Instead of setting the mirror destination to the same port as in point 3 above, use separate destinations but capture on the same PC, with two NICs. Make one of the them a USB NIC and heavily load the system. Timing could be a mess. *My assertion that this is poor is true for me - I have no need to configure my span ports in this manner for my daily work. However, it may be perfectly valid for whatever it is you are trying to do. For understanding ICMP echo flows across a router this is probably not the best choice. What can explain a TTL=127 for a duplicate packets ?
(14 Oct '16, 23:15)
thierryn
Your answer has been converted to a comment as that's how this site works. Please read the FAQ for more information.
(15 Oct '16, 00:19)
Jaap ♦
I would assume, somehow a router is influencing it's TTL. Awkward indeed.
(18 Oct '16, 02:38)
SynAck
As @Bob Jones has already explained - the same "logical packet" is captured twice, before and after passing through a router.
(18 Oct '16, 03:00)
sindy
|