CARP Problems
-
In terms of having interfaces being master or backup and being wrong, this means that carp is not communicating on the interface themselves. It needs to be able to broadcast and talk to the other firewall on that interface in question.
How could I test it. Because I'm facing the similar problem, one of my carp interfaces out of the four are "master-master" no matter what I do. Simple ping goest fine to and fro'. Nothing seems to be blocked in the logs. I have already changed NIC's and switches without success.
-
In terms of having interfaces being master or backup and being wrong, this means that carp is not communicating on the interface themselves. It needs to be able to broadcast and talk to the other firewall on that interface in question.
How could I test it. Because I'm facing the similar problem, one of my carp interfaces out of the four are "master-master" no matter what I do. Simple ping goest fine to and fro'. Nothing seems to be blocked in the logs. I have already changed NIC's and switches without success.
If you have not seen the CARP tutorial on our site then you need to follow it. It will guide you in setting up the primary box which sycns the configuration to the secondaries. The reason this is important is because it ensures that the advskew and also the vhid are correct across all cluster members. It also ensures that the passwords match per vhid. Place a crossover cable between the two wan interfaces. Does the problem persist? If so you have a mismatched configuration somewhere.
-
If you have not seen the CARP tutorial on our site then you need to follow it.
I did exatly that.
It will guide you in setting up the primary box which sycns the configuration to the secondaries. The reason this is important is because it ensures that the advskew and also the vhid are correct across all cluster members. It also ensures that the passwords match per vhid. Place a crossover cable between the two wan interfaces.
I have already tried this. Not only the wan but all the interface pairs, one by one. I will make some other xover cables tomorrow and will make a try with connecting all interface pairs (WAN, WAN2, DMZ and LAN) with xover (they carp syncronization interface is ofcourse permanently xovered).
Does the problem persist?
Yes :(
If so you have a mismatched configuration somewhere.
Yes probably, but I have tried to build up several times from scratch, with only the (as I guess) the minimal neccessary configuration. So now I have no idea what could be the problem.
Anyhow, it seems to function well, on all the two WAN interfaces either from LAN or DMZ, but I afraid that there is a hidden problem which can cause a collapse in the worst moment. -
Post screen shots of each of the machines virtual ips configuration so we can inspect.
-
Post screen shots of each of the machines virtual ips configuration so we can inspect.
I attached as you asked. I reduced the sizes as possible, hoping that they are still readable.
Thank you for your helpImre
-
Each of the same ip's need to share the same vhid group… They are unique in your setup which also tells me that you didnt follow the tutorial as it would have sync'd the configuration to the backup node ensuring this is all the way it should be. >:(
-
Each of the same ip's need to share the same vhid group… They are unique in your setup which also tells me that you didnt follow the tutorial as it would have sync'd the configuration to the backup node ensuring this is all the way it should be. >:(
Sorry .then I probably misunderstandig something :(
xxx.xxx.xxx.165's VHID=1
xxx.xxx.xxx.116's VHID=2
10.0.254.4'd VHID=3
192.168.0.10's VHID=4
the same kind of interfaces have the same vhid group number.
I'm confused. All of the 4 should have the same? -
Each of the same ip's need to share the same vhid group… They are unique in your setup which also tells me that you didnt follow the tutorial as it would have sync'd the configuration to the backup node ensuring this is all the way it should be. >:(
Sorry .then I probably misunderstandig something :(
xxx.xxx.xxx.165's VHID=1
xxx.xxx.xxx.116's VHID=2
10.0.254.4'd VHID=3
192.168.0.10's VHID=4
the same kind of interfaces have the same vhid group number.
I'm confused. All of the 4 should have the same?Each unique IP needs to have its on VHID. The VHID needs to match on each machine.
If you are using the Sync option as the tutorial shows, this is all automatic.
-
Each unique IP needs to have its on VHID.
It is.
The VHID needs to match on each machine.
They do.
If you are using the Sync option as the tutorial shows, this is all automatic.
I did and I see them to be the same, but please let me know which one is not matching. it is probably my fault, but I really don't see.
-
I just want to add something to know before activating sync over XML-RPC. When having a lot of rule in the filter, it is not possible (in terms of 'useability') to use the rule sync over XML-RPC. I have tested it on a cluster wich have between 700 and 800 rules… when you modify one thing the sync starts and then the firewall goes to 100% CPU (php process) during many many minutes loosing control on everything. This was tested on 2 IBM x336 intel Xeon 3.2Ghz dual core with 2Gb of RAM and 80Gb SATA hard drives.
What I do is manual sync using partial backups ;-) and it's fine I'm not adding rules every minute ;-)
-
I just want to add something to know before activating sync over XML-RPC. When having a lot of rule in the filter, it is not possible (in terms of 'useability') to use the rule sync over XML-RPC. I have tested it on a cluster wich have between 700 and 800 rules… when you modify one thing the sync starts and then the firewall goes to 100% CPU (php process) during many many minutes loosing control on everything. This was tested on 2 IBM x336 intel Xeon 3.2Ghz dual core with 2Gb of RAM and 80Gb SATA hard drives.
What I do is manual sync using partial backups ;-) and it's fine I'm not adding rules every minute ;-)
I don't really want to hijack this thread but could you please start a new topic that explains the pain and frustration of managing such a large ruleset in a new topic? We can begin to brainstorm how to improve this situation.
-
I really hope you don't think I'm complaining. The previous post was just a sort of "advice" for those who have not tried it yet.
Regards.
-
I really hope you don't think I'm complaining. The previous post was just a sort of "advice" for those who have not tried it yet.
Regards.
Not at all. I just can imagine that managing that large amount of rules must be painful. I am looking for information on what you don't like, what is hard to do, etc for future improvements…
-
Hi,
Just for the record, my problem is solved. It was a ruling mistake on DMZ, ie. a directed all traffic destined to elswhere then LAN or DMZ to the load balancer (WAN1 + WAN2), but this way the traffic to 224.0.0.x went out to the net.
Thanks for all who tried to help me to solve this problem.