Retransmissions will have other IP IDs for it. This objection seems to be not valid for me.
Mirror artifacts could happen but the things I mentioned are switch mirror locics duplicating the packets. And the probability of the artifacts are zero in contrast to the duplicates by method. The result must be much better to filter these hardware duplicates. IP fragments will have the same IP ID but if you are using e.g. pkt_part = (*(pkt_data + 0x12)<<24) + (*(pkt_data + 0x13)<<16) + (*(pkt_data + 0x28)<<8) + *(pkt_data + 0x29) for comparison whether 2 fragments are the same (0x12 and 0x13 for the IP ID and 0x28 and 0x29 for the lower 2 bytes of the seq nr) there must be the inprobable case that bytes 28 and 29 are equal (in the search array of say 100 packets) to define these fragments as hardware duplicates spuriously. Despite the fact that we have 0.01% IP fragments in our net maximum. That's a bit fuzzy. But often it is very handy to mirror a complete VLAN or a bunch of servers and get statistics from it as a whole. And the hardware duplicates are problematic in doing so. And a fast filter would be helpful. No hard feelings;-) Markus P.S.: SOL the beer no shit I got it! On Tuesday 20 April 2004 21:55, Burton M. Strauss III wrote: > 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 _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop
