Re: prioritizing carp interfaces

2009-07-13 Thread Toni Mueller
Hi,

On Mon, 23.03.2009 at 17:22:55 +0100, Joerg Streckfuss streckf...@dfn-cert.de 
wrote:
 In my opinion preemption on both nodes effects that advskew is set to 240 on 
 all
 interfaces and as a consequence there is no host which could advertise faster
 then the other host in the carp group.

that sounds plauible.

 Am I right in thinking that no failover should happen regardless of the number
 of failed carp interfaces?

I guess that you could end up with both nodes in MASTER or SLAVE state,
then, because it's clearly an undefined situation to have advskew at
the same value on several nodes unless you want load balancing using
the carpnodes option. In any case, my guess is that in this situation,
communication becomes quite lossy (both are MASTER), or stops
completely (both are BACKUP).

I don't know whether there's some magic (or protocol definition)
involved in setting the advskew value to 240, but otherwise, one could
expose this value through a sysctl and set individual values on the
various hosts.


-- 
Kind regards,
--Toni++



Re: prioritizing carp interfaces

2009-03-21 Thread Toni Mueller
Hi,

On Fri, 20.03.2009 at 14:28:46 +0100, Joerg Streckfuss streckf...@dfn-cert.de 
wrote:
 How does CARP behaves when on the master node two unimportantly interfaces
 fail and on the backup node only the uplink interface fails? Does CARP
 failover
 to the backup node and as consequence the whole network will be disconnected
 from the internet?

my reading of carp(4) is that the behaviour depends on the setting of

net.inet.carp.preempt

If set to 1, then firewalls only fail over as a whole, while if set to
0, interfaces fail over individually. With interfaces failing over
individually, and with appropriate routing between your firewalls,
traffic should flow through the remaining interfaces.

Please note that having interfaces fail over individually makes playing
with pfsync and sasync *quite* interesting.
Please also note that you could have more than two firewalls running
CARP, so maybe the third (fourth, ...) firewall will keep you online.

I guess that the real solution is to have a known-good hardware that
you can bring up in minutes sitting on the shelf, and yes, to live with
some downtime.


Kind regards,
--Toni++



Re: prioritizing carp interfaces

2009-03-20 Thread Kamil Monticolo
 Hi list,
 
 I have a theoretical question regarding a CARP cluster and many CARP
 interfaces
 
 Assume we have a firewall comprising of two notes, each with 4 or more
 interfaces and only one uplink to the internet. The Cluster is in
 master/backup mode
 
 How does CARP behaves when on the master node two unimportantly
 interfaces fail and on the backup node only the uplink interface
 fails? Does CARP failover
 to the backup node and as consequence the whole network will be
 disconnected from the internet?
 
 In my mind one solution to avoid this situation is to rate the CARP
 interfaces.
 For example a more important interface gets a higher rate than a less
 important
 interface.
 
 Probably the ifstated deamon and the demotion counter are the topics
 to get around with this.
 
 Does anybody have experiences demotion couter and ifstated?
 
 Thanks in advance.
   

Well, looks interesting, but I didn't try it. It maybe too
complicated, when redundancy need to be as simply as possible. Instead
of this, you can just add another node(s), this is the safest solution,
I think.
-- 
Kamil Monticolo



Re: prioritizing carp interfaces

2009-03-20 Thread Joerg Streckfuss
 Well, looks interesting, but I didn't try it. It maybe too
 complicated, when redundancy need to be as simply as possible. Instead
 of this, you can just add another node(s), this is the safest solution,
 I think.

Well, another node implies two nodes for redundancy. And two independant
firewall clusters means two independent rulsets to manage.
I think i will try ifstated with a finite state machine based on ping test
and
demotion counter.



--
Dipl.-Ing. (FH) Joerg Streckfuss, Phone: +49 40 808077-631

DFN-CERT Services GmbH, https://www.dfn-cert.de/, Phone  +49 40 808077-555
Sitz / Register: Hamburg, AG Hamburg, HRB 88805,  Ust-IdNr.:  DE 232129737
Sachsenstra_e 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which 
had a name of smime.p7s]