On 29/12/10 12:40, Simone Zaffalon wrote: > Hi Pablo. > Thank you for the answer. >> >> Better use the primary-backup.sh script that is included in the >> conntrack-tools package. You can find it under doc/sync. That script >> should be called by your HA manager during the failover. > > Already done. I've included > /usr/share/doc/conntrackd/examples/sync/ftfw/script_master.sh in > vip-up.sh (the ucarp script called when failover occours): > -----------vip-up.sh-------------------------- > #! /bin/sh > exec 2> /dev/null > > /sbin/ip addr add "$2"/24 dev "$1" > > # or alternatively: > # /sbin/ifconfig "$1":254 "$2" netmask 255.255.255.0 > #!/bin/sh > > /usr/sbin/conntrackd -c # commit the cache > /usr/sbin/conntrackd -f # flush the caches > /usr/sbin/conntrackd -R # resync with kernel conntrack table > ----------------------------------------------- > > and of course i did the same with script_backup.sh in vip-down.sh This seems to be an old script version. What conntrack-tools version are you using? > Now I'm switching to keepalived (to stick more with provided examples) > and i am doing some other experiment and i let you know how far i'll > go with that. > In the meantime, as i asked before, is there any way to increment log > verbosity to understand what's going on (in /var/log/conntrackd.log)? You cannot increase verbosity but you have plenty of conntrackd -s information to know what is going on (see manpage for -s option parameters). I still don't know what is your problem, please provide a more detailed procedure of what you're testing and I'll be happy to help you. To test conntrackd, it's a good idea to start with something simple: 1) create a TCP connection between two peers that are firewalled. 2) check in the primary firewall that `conntrackd -i' shows the flow (this is to display the internal cache). 3) check in the backup firewall that `conntrackd -e' show the foreign flow, that means it has been correctly propagated (-e shows the external cache). 4) for a simple failover scenario, set a link down in the primary to trigger the failover. 5) the new primary must contain the entry with `conntrack -L' (to display the kernel conntrack table). 6) check the logs, they must contain that one flow was injected (committed). -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html