Maybe maybe not ... it really all depends on how both systems (Cisco and ntop) see the traffic.
WRT Cisco, I don't know for sure. But I highly doubt the article on SPAN is less than accurate. If anything, it may understate the cases where you see duplicates. WRT ntop, I've got a lot more confidence. ntop sees packets. There NO (zip, nada, none) comparison of ANY packet with any previous or future packet, except for a little fragment reassembly. So if you SPAN it and it's on the wire twice, ntop counts it twice. One of my clients puts a full view of their traffic out a single SPAN ports - but they're using 7000 series systems and have a lot more power than the lower end systems including the ability to put packet level filters on the SPANs. But even that won't help YOUR problem. -----Burton > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Markus Rehbach > Sent: Tuesday, April 20, 2004 5:00 PM > To: [EMAIL PROTECTED] > Subject: Re: [Ntop] How to avoid 'hardware duplicates' using span/mirror > ports? > > > 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 _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop
