From: Pablo Neira Ayuso <pablo@netfilter.org>
To: CeR <cer.inet@linuxmail.org>
Cc: netfilter@vger.kernel.org
Subject: Re: Conntrackd+Keepalived, active/active firewall cluster
Date: Tue, 02 Aug 2011 22:26:39 +0200 [thread overview]
Message-ID: <4E385D7F.4020309@netfilter.org> (raw)
In-Reply-To: <BANLkTikiiTuiuNO-DOGjTchanAnTSDME0Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2374 bytes --]
Hi,
Sorry, it seems this email got lost in my box.
On 07/06/11 00:08, CeR wrote:
> Hi there!
> With the last package I got of conntrack-tools I see some config files
> and shell scripts supposed to work in an active/active firewall
> cluster.
> Configuration files for keepalived are included.
> I have configured my system in the way I guess it may work, but have
> some doubts about the configuration and the system isn't working at
> all.
I expect that you're using the experimental scripts available here:
http://1984.lsi.us.es/git/?p=cluster-match-scripts/.git;a=tree
> Some issues:
> · I think keepalived should give both nodes both IPV resources, so the
> load balancing can be succefully done with iptables (as seen in
> multiprimary.sh)
You have to define two resources (one for each node) without virtual IPs
(since both nodes will share the same IPs).
Please, find attached some toy-example file for keepalived. It needs to
be improved for the case when one dead node comes back to life, among
other things.
This stuff is still work-in-progress, I've been looking for some sponsor
to boost this development with no success so far. I'm busy with other
things that prevent me from prioritizing this feature.
> · With the give configuration, Keepalived sometimes gives IPV
> resources to just one node, the other remains inactive and seems like
> a passive-backup node.
> · In some cases, I have both nodes with both IPV resources, but it
> seems that some misconfiguration in iptables DROP packages needed by
> clients connections through the firewall. Maybe conntrackd not working
> properly in state replication?
>
> If anyone gives me some clues I could just write some documentation
> regarding this configuration, maybe with a little explanation of
> protocols and tools being implied. Or is there already some
> documentation?
All the documentation that you can find is available in the website.
There's another article that I wrote which I expect to release once it
is published in one journal. However, it does not describe how to deploy
this setup, it's more about design, implementation and evaluation.
> As you can see, right now i'm working in a non-production environment,
> but with more investigation and develop all can be done. I'm really
> interested in this.
Good luck with it.
[-- Attachment #2: keepalived-multi1.conf --]
[-- Type: text/plain, Size: 2091 bytes --]
#
# Simple script for multi-primary setups
#
vrrp_sync_group G1 { # must be before vrrp_instance declaration
group {
VI_1
VI_2
}
notify_master "/home/pablo/devel/cluster-match-scripts/cluster-node1.sh primary 1"
notify_master_sync
notify_backup "/home/pablo/devel/cluster-match-scripts/cluster-node1.sh backup 1"
notify_fault "/home/pablo/devel/cluster-match-scripts/cluster-node1.sh fault 1"
}
vrrp_sync_group G2 { # must be before vrrp_instance declaration
group {
VI_3
VI_4
}
notify_master "/home/pablo/devel/cluster-match-scripts/cluster-node1.sh primary 2"
notify_master_sync
notify_backup "/home/pablo/devel/cluster-match-scripts/cluster-node1.sh backup 2"
notify_fault "/home/pablo/devel/cluster-match-scripts/cluster-node1.sh fault 2"
}
vrrp_instance VI_1 {
interface eth1
state SLAVE
virtual_router_id 61
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass papas_con_tomate
}
# not needed - only for testing purposes
virtual_ipaddress {
192.168.0.111/24 # default CIDR mask is /32
}
}
vrrp_instance VI_2 {
interface eth2
state SLAVE
virtual_router_id 61
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass papas_con_tomate
}
# not needed - only for testing purposes
virtual_ipaddress {
192.168.1.111/24 # default CIDR mask is /32
}
}
vrrp_instance VI_3 {
interface eth1
state SLAVE
virtual_router_id 62
priority 10
advert_int 1
authentication {
auth_type PASS
auth_pass papas_con_tomate
}
# not needed - only for testing purposes
virtual_ipaddress {
192.168.0.222/24 # default CIDR mask is /32
}
}
vrrp_instance VI_4 {
interface eth2
state SLAVE
virtual_router_id 62
priority 10
advert_int 1
authentication {
auth_type PASS
auth_pass papas_con_tomate
}
# not needed - only for testing purposes
virtual_ipaddress {
192.168.1.222/24 # default CIDR mask is /32
}
}
prev parent reply other threads:[~2011-08-02 20:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-06 22:08 Conntrackd+Keepalived, active/active firewall cluster CeR
2011-08-02 20:26 ` Pablo Neira Ayuso [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E385D7F.4020309@netfilter.org \
--to=pablo@netfilter.org \
--cc=cer.inet@linuxmail.org \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox