Isn't there a way to adjust the sync transfer. I know by default it's
every 50ms or so, but if it coujld be set lower than that (i.e. to 10ms or
so), that would fix it. Also, how low could you set the interval
(obviously requiring it's own link) before it wasn't enough time to sync
the whole table?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Carric Dooley CNE
COM2:Interactive Media
http://www.com2usa.com
"Talent does what it can; genius does what it must."
- Edward George Bulwer-Lytton
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1
iQA/AwUBN8Qm3jAINgHnOVgZEQLkSwCgppFgWa9hrcnbePGnfvs3vVrQu+cAniLx
4Ru0tIf3Ulz16YfVvNWbuCaH
=KUJG
-----END PGP SIGNATURE-----
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.]
