A faster crossover cable won't matter. I believe it is the sync interval
that is the issue (happens every 50ms). I have been waiting for an answer
from one of the Checkpoint engineers, but he must be on vacation. =)
I know true load balancing is NOT part of the package. I have been told
by my Nokia rep that if you want to load balance you need to get something
like an Alteon AceSwitch that will balance between the two IP's on the
firewall (you wouldn't use VRRP.. redundancy and load balancing are
handled by this "intellegent device".. oddly enough these devices are not
free).
I am digging through everything in $FWDIR/lib to see if there is any
mention in the .def files of the sync interval, but as yet, this is
fruitless (grep is your freind only if you know what you are looking for).
I am going to ask some other engineers to see what they think.
Carric Dooley CNE
COM2:Interactive Media
http://www.com2usa.com
"Talent does what it can; genius does what it must."
- Edward George Bulwer-Lytton
On Tue, 31 Aug 1999, Litney, Tom wrote:
> Gary,
>
> I will confirm your findings (if any further confirmation is required). I
> didn't want to announce this issue publicly, but since the kitty is already
> out of the liter ...... We have reported this issue to the vendor and they
> are looking into it. We are running a very high speed network and our
> experience was that our network was much faster than the session management
> (and updating) between the load balancing hosts. This appeared most
> frequently resolving DNS queries and FTP sessions. Our assumptions are that
> the packets would travel out one of the Nokia's and return through the peer.
> Since the state information had not yet been created/updated, the peer had
> no knowledge of the session and dropped the packet. I removed the load
> balancing machine and things went back to normal. The one Nokia handled the
> load successfully and I'm using the other as a hot backup until the vendor
> can provide a resolution. I don't see any reason for anyone to panic.
> Nokia has been very responsive and I'm sure they are working hard to resolve
> this issue. It will only affect people trying to install them in high speed
> networks and trying to run them in a load balancing scenario. hmmmm maybe a
> faster crossover cable ????? :-))
>
> Tom
>
> On Thu, 26 Aug 1999, Gary Ramah wrote:
>
> > Ouch!
> >
> > We have been trying to get several Nokia IP440's to do asymmetrical load
> > balancing using Nokia's OSPF implementation It turns out that when these
> > boxes are running on fast Ethernet they do not share state information
> > quickly enough so that when the ICMP reply packets come back, a different
> > route then the request packets went out (asymmetrical), the firewall1
> > software drops packets because it has no state info about this flow.
> >
> > There is no policy rule for dropping the packet, implicit or otherwise.
> > There is no log message recording the dropped packet, nor any entry in the
> > messages log about the action.
> >
> > When we de-install the policy everything works fine but with the FW policy
> > installed, state problems.
> >
> > We have been working on this for weeks and the Nokia engineers just
> > confirmed our findings this morning here's what they wrote.
> >
> > >Because XXXXX is connected to both XXXXXX by Fast Ethernet, the
> turnaround
> > >time is very low, probably less than 10-20 ms. In this situation, like
> > >others Nokia has observed previously, there is not enough time for the
> > >state table information to propagate across the sync link and make it
> into
> > >the peer's state table before the reply arrives at the peer. In this
> case,
> > >XXXXX echo reply arrives at XXXXXXX before the security information
> > >has arrived from XXXX. There's no entry in the state table of Nokia A,
> so the
> > >reply is dropped.
> >
> > An interesting undocumented "feature" that they have observed previously.
> >
> > Does anyone here have any similar experiences with this equipment?
> >
> > --
> > Gary Ramah
> > Advanced Network Technology and Applications
> > NASA Ames Research Center
> > Mail Stop 233-21
> > Moffett Field, CA 94035-1000
> > USA
> >
> > mailto:[EMAIL PROTECTED]
> > http://www.nren.nasa.gov
> >
> > 650-604-0890 (voice)
> > 650-604-3080(fax)
> > -
> > [To unsubscribe, send mail to [EMAIL PROTECTED] with
> > "unsubscribe firewalls" in the body of the message.]
> >
>
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
