TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems!
----------------------------------------------------------------------------
On Thu, 24 Aug 2000, Reddock, Steve (ISS Japan) wrote:
> >>network gear...
>
> If you overload RealSecure in this way then the worst that can happen is it
> misses packets. It really does add no network delay. It really is operating
> in the same way as a sniffer is.
Actually overloading ISS RealSecure OS Senser/Detector/Engine can cause
delay in reporting back to the ISS RealSecure console. Also if and when
the database reaches its limitations, events will be discarded. A full
out targa3 attack will demonstrate this very easily.
>
> I suspect the problem is over-subscribing the monitor port (ie sending more
> bandwidth to it than you can fit into a 100MB segment) and this is slowing
> the switch down. As the cisco description below says, the port is over
> subscribed, not the deivce on the other end (RealSecure).
Please refer to ISS Real Secure 5.0 Getting Started Guide on sizing the
box for the appropriate network traffic. Actually it does not state to
much regarding placement on VLAN. Wish it did.. :)
>
> Regards, Steve
>
>
>
>
> >> 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
> >
> >
>
> ----------------------------------------------------------------------------
> Steve Reddock
> Consulting Manager - Asia Region
> [EMAIL PROTECTED]
>
> Internet Security Systems KK, Japan
> Phone +81-3-5475-6458 Fax +81-3-5475-0557
> http://www.iss.net http://www.isskk.co.jp
>
> PGP keys available on request
>
> Internet Security Systems - The Power to Protect
> ------------------------------------------------------------------------
>
