Lots of good information here. The informal internal announcement that the FDX Pod was no longer to be available was disemminated in the US market several months ago.
Distributed v4.3 does in fact support FDX and there is a specific card being offered for it. if you already have an ET05 in hand (multi card Ethernet Sniffer with four monitor cards) there are special drivers available that bind the first two cards together so that they function as a dual receive FD NIC.
The question of identical delta times is an interesting one and I don't know of any solution short of appropriate analyzer intelliegence that address this one.
I would be remiss if I failed to mention that my employer also offers a full duplex copper tap identical in functionality to the NetOptics product. Something we also offer for the Distributed Snifefr that is not available from them is an in-line matrix switch that combines sixteen fault tolerant passive copper FD taps into a 1.75" high chassis. It allows the user to share a single FDX Distributed Sniffer among mutliple links and switch among them remotely from within the Sniffer Console software. please note that this product DOES not support the old FDX pod that has been discussed here - it is specifically targeted at products with true dual receive NIC's and native FD support.
Many people are doing analysis of FD links through SPAN ports and although it's a necessary evil.... it's best to remain ware of the limitations:
You can send a copy of the FD traffic but as Robert so aptly pointed out, the SPAN/Mirror port is half duplex by nature. Even if you could configure it as FD, it's still doing "send-only" to the Sniffer NIC, which is "receive-only" in promiscuous mode. The important thing to remember is that a SPAN port can never send more than 100mbs and a FD link has a theoretical capacity of 200mbs. It's easy to oversubscribe it if trying to SPAN a very busy link (or links). You will NOT be notified of the dropped packets and there is no retransmission (you could check the MIB at port level on the Ethernet switch and compare it to the packet count on the trace file but few peopl have the time to do this.
Also.... layer 1 and 3 errors are NOT propogated by SPAN ports - they are discarded at port level. Few of us spend time chasing down jabbering NIC's these days and cabling infrastructures are more reliable and robust than ever but CRC errors are still a fact of life on networks and a high level of them implies that lots of retransmissions are going to be occurring, potentially slowing down the network. On a large, well instrumented network that has good management platforms in place (Concord, Lucent, HP Openview etc) you may already have a way to be notified of such instances but in smaller organizations it's critical to keep track of them. SPAN port connectivity for analysis is a necessity for most of us but placing taps in a few key locations may be very helpful.
Owen O'Neill
Datacom Systems Inc.
Northeastern SE
