TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to [EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems! ----------------------------------------------------------------------------
If it is a copper tap, most likely during a TCP session you will lose about 5 seconds of connectivity when the tap loses power. We tested this with Smartbits using a century tap connected to a Cisco 5500. It takes the switch a few seconds to re-establish the connection. This was with PortFast enabled on the switch. In TCP it shouldn't be a big deal since it has its own error checking built in. Our FTP, SSH and telnet sessions didn't die, but our business folks weren't comfortable with the 5 second delay nonetheless. Fiber taps have no delay since there is no power to them. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 5:11 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: How to merge several switched LAN segments TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to [EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems! ---------------------------------------------------------------------------- I have tested the Shomiti Century Single Port Tap this morning and it worked just fine. No packets were dropped when unplugging the power line of the tap. I've just tested pings at 10Mbit/s, so I cannot tell how the tap reacts on high density udp traffic at 100Mbit/s during power failure. If anyone has the opportunity of performing tests with a smartbits at his company, I would be very interested in the results. But for now it seems, that the tap does a pretty good job. Greetings, D. Liesen > > TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message > to > [EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any > problems! > ---------------------------------------------------------------------------- > > Just to add to what Chris says, I did know one company that trialled > the taps and claimed that some packets were lost for a brief period of > time following a power fail - not necessarily a big issue for TCP > sessions but not very good for UDP packets (without a higher level > application handling reliability) or if you want to see everything. > Therefore I'd try and get some kit on trial and test it yourself (i > suppose you could set up a client on one end, a sniffer on the other, > and do a high density UDP port scan - cut the tap's power during that > scan then compare what you send to what you receive). > > With regard to the prolonged outage caused by spanning tree, which I > hadn't heard of before but I can see might happen if the tap does a > reset, check whether your switch supports disabling spanning tree for > individual ports. For example some Cisco kit lets you set 'portfast' > which tells it that you've got a host on the port, not any other comms > kit, and so the switch needn't go through the lengthy spanning tree > phases which prohibit sending traffic on a port until it calculates > the topology. > > I've personally never used a tap so i can't really comment on tap > reliability myself. > > Jason > > > On Tue, 16 Apr 2002 17:37:42 -0400, you wrote: > > > > >TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message > to > >[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any > problems! > >------------------------------------------------------------------------ > ---- > > > >I will just throw my two cents in here about the taps formerly from > Shomiti, > >which I think you were referring to. The documentation provided by both > ISS > >and Shomiti had lead me (and it seems you also) to believe that the taps > >were completely passive, but during my testing here, they were not. > When > >using the taps between any device and a Cisco Catalyst Switch, the port > on > >the switch would reset itself when the power was cut on the tap, causing > a > >one minute outage on that device connection. This had something to do > with > >the way Cisco handles spanning trees and traffic looping. If more > details > >are necessary, let me know. > > > >This is a serious issue not to be overlooked since the Shomiti taps are > >built with a very crappy power supply connection. Just moving the taps > >could cause the cable to fall out. We chose to pipe the SPAN ports of > our > >Cisco Catalysts into the Top Layer switches. > > > >Chris > > > > > >-----Original Message----- > >From: Rob Keown [mailto:[EMAIL PROTECTED]] > >Sent: Monday, April 15, 2002 7:08 PM > >To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] > >Cc: [EMAIL PROTECTED] > >Subject: RE: How to merge several switched LAN segments > > > > > > > >TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message > to > >[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any > >problems! > >------------------------------------------------------------------------ > ---- > > > >http://www.finisar.com/product/product.php?product_id=68&product_categ > ory_id > >=41 > > > >Look into their multi-port taps. I use their single-ports all over the > place > >(Finisar bought Shotomi). > > > >You will need to call them as I spent days trying to find a reseller. > > > >These are high-reliability units that fail "closed" meaning if they lose > >power, etc. they do not interrupt traffic flow. > > > >I am not sure if the multiports merge or just let you rove. > > > >Obviously it also depends on how much traffic you have. > > > >Rob Keown > >MAC DIRECT > > > > > >-----Original Message----- > >From: Jason Renard [mailto:[EMAIL PROTECTED]] > >Sent: Monday, April 15, 2002 3:38 PM > >To: [EMAIL PROTECTED] > >Cc: [EMAIL PROTECTED] > >Subject: Re: How to merge several switched LAN segments > > > > > > > >TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message > to > >[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any > >problems! > >------------------------------------------------------------------------ > ---- > > > >On Mon, 15 Apr 2002 09:29:10 +0200, you wrote: > > > >>I am looking for a trick to merge the traffic of about 5 switched Fast > >>Ethernet LAN segments together in order to monitor the total traffic > >>with only one RS Network Sensor. Most of the LAN segments are on > >>different physical switches (DMZ, RAS, WAN Segments), but in the same > >>physical location. > > > >Watch out for how much load you have on these segments compared to how > much > >you can monitor, in terms of (a) whatever you use to 'merge' the traffic > (b) > >the NIC on your network sensor (c) the CPU on your network sensor. > > > >>All links are Full-Duplex - and we would like to keep that up to the > >>IDS Interface (to prevent packet loss due to collisions). > > > >Ok, here when you say "IDS interface" you don't necessarily mean the > network > >sensor NIC do you? You mean whatever device / technology is used to > merge > >the five full duplex ethernet connections into one stream? > > > >>All this traffic should then be collected on a single 'IDS-Switch', > >>which then mirrors all the incoming segments/traffic to the IDS > >>interface port. > > > >I assume you've done the maths, such that it is theoretically possible > to > >merge the total network traffic of your five full duplex segments out on > to > >a single wire? After all, whatever device you use to merge the traffic, > if > >you've only got ONE network sensor then it will only be able to process > the > >traffic on its RECEIVE wire which is essentially half-duplex. (In other > >words, even if you combine 200 Mbps of full-duplex traffic, when you > squirt > >it at the sensor it will be down a wire rated at 100 Mbps - and that's > >assuming 100% utilisation). > > > >As a technical aside I believe Network Sensors support more than one NIC > >(possibly two, not sure if three's official) so if you had a single > >full-duplex wire to be monitored then you could tap both directions and > feed > >each into a NIC on the same network sensor - although of course (a) > would > >both be loading the CPU etc on the sensor > >(b) would lose some functionality because each NIC's would be examined > >separately and you'd have problems with 'syn flood' detection etc. > > > >Incidentally i've not dabbled with dual sniffing NICs on a Network > Sensor so > >don't take anything i've just said as the word of an experienced man! > > > >>As this IDS switch (Cisco 2924) does not support *unidirectional* port > >>mirroring (SPAN), we need another solution to prevent the mix-up or > >>backflow of traffic to the source switches (also for security reasons). > > >>I've heard something about cutting the TX lines in the Twistet-Pair > >>patch cables that lead to the IDS switch, to prevent the back-flow of > >>traffic. Has anyone done this already, and if so, how do I trick the > >>switch to keep the port 'up', despite the cut TX line? > > > >I've heard of cutting the TX line but haven't done so myself. > > > >Interesting, yes, I'd never thought what the switch would do in that > case - > >hopefully some other readers will have done this and know. > > > >I am a little confused here - is the Cisco 2924 a normal switch without > >SPAN, or does it have SPAN abilities but you can't customise it to > prevent > >injection of packets? > > > >You can buy "wire taps" which are little boxes that you can think of as > >going instream into an ethernet cable and presenting copies of both the > >wires to you. I think they're called Schomiti or something like that. > For > >example you could plug a cable between your switch and the tap, then > take > >one of the feeds and connect it to your sensor. The only thing I'm not > sure > >of is whether the tap would needed to be connected to something else, > >properly, since it's designed to sit "instream". I've not used these > taps > >so, once again, am only talking from what i've picked up from others. > > > >>Any other ideas or tricks to merge multiple switched LAN segments onto > >>the IDS network interface? > > > >"Top Layer" switches used to be mentioned a lot alongside ISS - I've > never > >used them but apparently they can take multiple feeds and present them > to a > >network sensor or stripe them across several sensors. Again, i should > say > >that i've not used these switches personally. > > > >>Many thanks! > >>Andres > > > >Don't forget... > > > >- if you use a span port to combine multiple segments, make sure that > span > >port can handle the combined amount of traffic > > > >- make sure the final wire to the network sensor, and the sensor itself, > can > >handle the final amount of traffic > > > >- if you split TX and RX to different sensors then you will lose a > little > >functionality > > > >- bear in mind whether now, or in the future, you might want the ability > to > >send TCP resets > > > >Um, that's it for now... > > > >Jason > >Jason Renard > > > >Warning - all views expressed are my own. > >I cannot guarantee the accuracy of everything > >I've said - use it at your own risk. > > > > > > > > > > Jason Renard > > Warning - all views expressed are my own. > I cannot guarantee the accuracy of everything > I've said - use it at your own risk. > > -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net ********************************************************************** This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you **********************************************************************
