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.]
