TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to [EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems! ----------------------------------------------------------------------------
We haven't had to move them much. But I'll agree the power supplies are not what should be in a "fault tolerant" unit. We haven't had a problem, but then we Velcro the power supplies down at the power controller and the unit itself (yah, I know, Velcro and fault tolerance should not be used in the same email!). We had one issue where the power was cut because of a power failure and the unit wasn't plugged into a UPS/Genset jack. I don't remember how long it took to failover (but it did ultimately keep the network connected). A minute is a long time at high-bandwidth. Overall I haven't had a problem, but your comments should be considered. Rob Keown MAC DIRECT -----Original Message----- From: Lanzilotta, Chris S. (MBS) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 5:38 PM To: 'Rob Keown'; '[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! ---------------------------------------------------------------------------- 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_category_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.
