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 ? asked 14 Oct '16, 07:57  thierryn |
One Answer:
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. answered 14 Oct '16, 10:06  Bob Jones edited 15 Oct '16, 03:28 |
What can explain a TTL=127 for a duplicate packets ?
Your answer has been converted to a comment as that's how this site works. Please read the FAQ for more information.
I would assume, somehow a router is influencing it's TTL. Awkward indeed.
As @Bob Jones has already explained - the same "logical packet" is captured twice, before and after passing through a router.
each pass through a router decrements packet's TTL to prevent packets to loop through the network forever if routing errors create a loop. This explains why the two copies of the packet have a TTL differing by 1,
the mirroring mechanism in the switch may not deliver frames grabbed at different sources in the same order in which they passed the source ports. This would explain why a packet with lower TTL was captured before a packet with higher TTL, but not why there is a negative timestamp delta between them, because the timestamps are assigned by the capturing machine, not the mirroring switch,
this leads to suspicion that the capture has been taken at several interfaces simultaneously and their timestamper-to-file propagation times were different (so the packet with earlier timestamp was written to the file later than the one with later timestamp) or that the capture file has been merged from two source files captured on different machines with slightly offset real time clock.