TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems!
----------------------------------------------------------------------------
Ooops.
My sentence should have read:
SS RealSecure should not be used as in-line filter as described
below. Sorry, typo..
As described in the Real Secure Getting Started Guide:
NOTE: No matter how you set up your system, there may be some environments
in which the RealSecure network sensor cannot process the network traffic.
If this happens, reconfigure the network sensor to reduce the number of
active signatures or responses. Dedicated hosts You should run RealSecure
network sensors on dedicated systems to maximize performance and to protect
both the system and the data gathered by RealSecure from unauthorized
access. Network sensors and consoles should run on separate systems,
Multiple collision domains
Today's networks have multiple collision domains. Devices like fire-walls,
routers, bridges, and switches divide a large collision domain into several
smaller ones. These devices are usually installed to
improve network performance and network security.
Important : A network sensor operates only within its local collision
domain. You must install a network sensor for each local collision domain
you want to monitor.
/end quoting from Manual..
:)
At 04:23 PM 8/23/00 -0400, Charles C. Lindsay wrote:
>It sounds like the cisco/ISS configuration was being used to monitor
>several cisco ports with a single ISS engine, probably over-subscribing
>the monitor port, and trusting to the ISS sampling to detect attacks.
>While it is feasible to monitor several ports with a single ISS sensor
>in this way, with decreased coverage, it might require alternative
>network gear...
>
>
> From: [EMAIL PROTECTED]
> Date: Wed, 23 Aug 2000 10:19:52 -0700
> Sender: [EMAIL PROTECTED]
>
>
>----------------------------------------------------------------------------
>
> http://www.shomiti.com/products/index.html
>
> Should solve some of the issues you may be experiencing.
>
> ISS RealSecure should be used as in-line filter as described below. It
> appears that there are configuration issue as described below that is
> causing performance issues other than the placement of ISS RealSecure.
>
>
> At 06:09 PM 8/22/00 -0400, [EMAIL PROTECTED] wrote:
>
> >Our online store has been suffering significant performance impacts the
> >last several weeks. Real Secure on the CISCO monitoring port was the
> >cause. I have been running Real Secure for three years and
> subscribed to
> >this list since its inception. Either I have not been paying
> attention or
> >this is the first I have heard of this issue. My mantra of it is just a
> >sniffer and will not impact the network has lost all credibility. The
> >following is a message from our network guys after talking to CISCO.
> >
> >---start--
> >I have been working with Cisco tech support on the problem we have been
> >seeing with regards to the increased On-line response times during busy
> >parts of the day. The question posed to Cisco was, what impact does a
> >monitoring port (Real Secure) have on the overall traffic on the switch,
> >if any.
> >
> >The way it works is like this (re: Cisco 2900XL and 3500XL switches); A
> >packet enters the switch and is held in a shared memory buffer until
> it is
> >delivered to it's destination port(s). The catch is, that it cannot
> leave
> >the buffer until all destination ports have been satisfied. If one port
> >is congested and cannot receive the packet, the packet must remain in
> the
> >buffer until it can be delivered to the congested port. When congestion
> >occurs on a monitor port, slowing the delivery process, the destination
> >ports will also be slowed down!! So, if a monitor port is receiving
> >packets destined to all other ports on the switch and it becomes
> >congested, it would in turn slow all ports that it is monitoring! Not a
> >good thing.
> >
> >This seems to be the case with the 220 network. We disabled the
> >monitoring port (Real Secure) last week and the response times
> >dropped. This is something that needs to be addressed as quickly as
> >possible. Since Real Secure is active on several critical networks. (I
> >am not sure if this applies to the 6500 and 5000 switches yet. The
> ticket
> >had to be transferred to the 5000/6000 switch support group.) As a
> >temporary fix, I have again disabled the monitoring capability on the
> 220
> >network. A longer term solution may be accomplished by limiting the
> >number of devices (ports) that are monitored. If this problem is
> relevant
> >only to the 2900/3500 family (pending), a permanent solution could be
> >achieved by use of a 5505 switch. This would require the use of VLANS
> >however. Things to consider.
> >
> >-- end --
>
>--
>Charles C. Lindsay TopLayer Networks, Inc. 508-870-1300 x147
>[EMAIL PROTECTED] "Layers Above The Rest" 508-870-9797 FAX
> 2400 Computer Drive, Westboro, MA 01581
