You're SOL. Unless you're doing full connection tracking, like the end-points are, there's no way to tell.
Remember - those could be legit retransmits (only the receiver knows the last byte number it received). Could be legit retransmits (if the ack was lost, only the source knows what it's sent last). Or they could be SPAN port artifacts. Or both. The end-points manage this by simple byte # counters. Nobody else even tries, because - as you've found out - it's a memory vacuum. Read up on the problems re fragment reassembly in IDSes and assume it's worse... -----Burton > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Markus Rehbach > Sent: Tuesday, April 20, 2004 1:45 PM > To: [EMAIL PROTECTED] > Subject: [Ntop] How to avoid 'hardware duplicates' using span/mirror > ports? > > > Hi all, > > perhaps not 100% on topic here but I'm sure there are a lot of > readers with > more knowledge than me concerning this issue. > > Problem: The measurement method is producing hardware duplicates. In my > scenario these packets are not wanted, because these packets will > destroy the > correctness of the traffic volumes for e.g. a group of servers. The are > primarily characterized having the same ip id and the same tcp sequence > number (tcptrace is identifying the duplicates that way). Most of > the time > the packets are following each other or are having a small gap between. > > References: from http://www.cisco.com/en/US/products/hw/switches/ps708/ > products_configuration_guide_chapter09186a008007e6fa.html : > > "Duplicate Traffic > > In some configurations, SPAN sends multiple copies of the same > source traffic > to the destination port. For example, in a configuration with a > bidirectional > SPAN session (both ingress and egress) for two SPAN sources, > called s1 and > s2, to a SPAN destination port, called d1, if a packet enters the switch > through s1 and is sent for egress from the switch to s2, ingress > SPAN at s1 > sends a copy of the packet to SPAN destination d1 and egress SPAN > at s2 sends > a copy of the packet to SPAN destination d1. If the packet was Layer 2 > switched from s1 to s2, both SPAN packets would be the same. If > the packet > was Layer 3 switched from s1 to s2, the Layer-3 rewrite would alter the > source and destination Layer 2 addresses, in which case the SPAN packets > would be different. " > > Affected should be bidirectional RSPANs and VSPANs on Cisco > switches. Nortel > Passport 8600 have a similar 'problem' while bidirectional > mirroring ports > n:1. I'm quite sure other switches will produce these hardware duplicates. > > Solution: ?. > > Is anybody out there who solved this problem? My first thought > was to write a > genereric filter for it but I stalled at the point I was thinking about a > suitable fast data structure for it.... naively I would take a > array of fixed > size.... > > What do you think? > > Cheers > > Markus > > _______________________________________________ > Ntop mailing list > [EMAIL PROTECTED] > http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop
