Simon Morvan <gar...@zone84.net> wrote: > After a couple of hours/days one of the box stop functioning properly : > no ping, no more SSH access but I still capture CARP avertisement on the > network segments (when it occurs on the master). As a result, when it > happens on the master, the slave does not take over.
A few ideas... Do you have any different hardware you can try instead to rule out some incompatibility with the machines? Have you checked for BIOS updates etc that might help? Can you break into DDB when this happens? (You'll need to set ddb.console=1 in sysctl.conf and reboot if it's not already set). If you can, trace/ps might be useful. If not it's a useful data point. (make sure you can trigger it correctly while the system is running normally; ctrl+alt+esc on glass console, or BREAK on serial console; then you can 'c'ontinue). > Le 27/05/2009 12:08, Jussi Peltola a icrit : >> I'd rather run pfsync in its own vlan than over a realtek card. It's >> probably not any slower (what could be slower than a realtek...) and Plenty of 100Mb only cards are slower than a realtek. re(4) here is good for about 550Mb/s of large packets (via tcpbench on a Core2 system), or about 50Mb/s of small-ish datagrams before it starts dropping too many on the floor. >> it's not really any less reliable (what use is pfsync if your "business" >> network goes down?) >> > I tought I'd better run pfsync over a direct connection rather that > through the switches. In case of failure of a switch, the sync has a > chance to be complete and the failover "cleaner", but maybe I'm wrong... If your firewalls are connected to different switches, that does make sense (unless your CPUs are saturated, in which case em(4) might indeed be a bit better).
