I think Bob has an interesting observation regarding the value of an HA
solution
that maintains session state. I have dealt with many customers where
minutes
means money, so there are many who value this technology.
In the context of load sharing, there are other methods that are available
with
the Nokia Appliance through the use of routing protocols. They are
deterministic and are
not sensitive to load, but they are bundled. (OSPF Equal Cost Multipath)
The actual failover is fairly impressive, although not all types of
connections are synchronized.
Generally, any connection that involves an application layer daemon, such as
Connection Control,
Content Security, Authentication, etc... is not going to failover and must
be restarted.
--- Jerald Josephs
----- Original Message -----
From: "Bob Brandt" <[EMAIL PROTECTED]>
To: "John Loshbough" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, July 06, 2000 11:21 AM
Subject: Re: [FW1] High Availability (Solaris and Nokia)
>
> As mentioned in several of the replies to your post it was noted that
Nokia's HA solution relies on VRRP, which provides failover, but not
> load sharing in an of itself. You can, as mentioned, configure "static"
load sharing (i.e. one subnet uses one firewall as primary, and another
> subnet uses a different firewall, etc.). You can then go even further
and use the state sharing feature of the Checkpoint point (costs extra) so
> that sessions remain active after their primary firewall's failure (have
never heard great raves about this feature on this list however so you
> may want to dig deeper).
>
> This whole discussion relates to maintaining high availiability however.
I don't see where load sharing is as critical an attribute for the bulk of
> the problem. If a single Nokia can firewall, at wire speed, all of your
traffic, then a backup firewall (or static redundancy with multiple
> VRRP groups) really is probably sufficient. People make a big deal out
of maintaining firewall session state, but I have yet to see any
> hard numbers on how beneficial this really is. Chances are investing
your dollars with multiple ISPs to ensure always on Internet connecitivyt
> has more measureable payback from a business perspective, as the chances
of having an Internet ISP outage is higher than your firewalls
> going down (as you don't have control over your ISPs maintenance
schedules, and all ISPs do maintenance on the border router you connect
> to on a regular basis). It really gets down to where you are going to
spend your money to maximize availability, and this question has to include
> other components such as servers, ISP redundancy, bandwidth, load
balancers, etc. Maintaining state across firewalls has its benefits, but
> also some significant costs. Moving the problem out of Checkpoint's box
and into somebody elses box may be a solution, but it doesn't
> necessarily solve all of the problems (e.g. what happens when that box (or
boxes) go down, how to they syncronize their states, etc.).
>
> Bob Brandt, [EMAIL PROTECTED]
>
>
>
> John Loshbough wrote:
>
> > I am currently running our Firewall (version 4.0) on a Solaris 2.6 box
and am looking to upgrade the hardware and software. Shortly after the
hardware is upgraded I'll have budget to add a high availability option.
> >
> > One of our people went to a Nokia sales presentation and said that we
don't need to purchase the Checkpoint or other vendors high availability
product because high availability comes with a Nokia box.
> >
> > Could someone knowledgeable about these issues help with the pros and
cons of switching from Solaris to a Nokia box. Also I'd appreciate some
comments about Nokia's (free) high availability vers Checkpoint's.
> >
> >
============================================================================
====
> > To unsubscribe from this mailing list, please see the instructions
at
> > http://www.checkpoint.com/services/mailing.html
> >
============================================================================
====
>
>
>
>
============================================================================
====
> To unsubscribe from this mailing list, please see the instructions at
> http://www.checkpoint.com/services/mailing.html
>
============================================================================
====
================================================================================
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
================================================================================
