Does anyone have a method or process to match up traces that have gone through a network compression device, that has changed both the datagram ids and seq/ack numbers. We get traces fairly often where we encounter this issue, it would be great if we could somehow match up the traces from both sides. asked 28 Mar '17, 07:24  mnmoose |
One Answer:
A compression device changes basically every bit and byte that you could use to match, so the only thing you might still be able to do is to work on meta information. E.g. "when an unencrypted packet arrives with x bytes, we see y bytes coming out of the device z milliseconds later, so chances are high that those two match" (with y < x within reasonable compression rates). Other than that, it's just guesswork I'm afraid. Out of curiosity - why do you need to do that "fairly often"? I always never have to do that except for HTTP proxies, trying to match multiplexed connections... answered 28 Mar '17, 12:41  Jasper ♦♦ |
I work lots of remote journaling(RJ) issues, customers uses compression devices before the WAN. So I end up with a source system trace and Remote system trace. They are complaining about RJ issues, backlogs and slow performance. Most of the time it's a network issues either retrans, or latency issues. But to prove it I need to match the traces up and try show their network team packets 1-7 leaving the source but only packets 1,3,4,6,7 make it to the target.