| CPUG | |
| The Check Point User Group | |
| A Resource For The Check Point Community. Fast. Useful. Independent. | |
|
| |||||||
![]() |
| | LinkBack | Thread Tools | Display Modes |
| |||
| Hi All In a Vrrp setup, master seems to lock up and stops passing traffic, during this time the slave doesn't take over until the master is rebooted. Once the master comes back up, its able to assume responsibility, what are the troubleshooting steps to take in this situation. thanks |
| |||
| Check if can reach all interfaces from both firewalls with icmp where VRRP is configured. When master locks up, are all interfaces on backup in backup state or are some in master???? |
| |||
| You could look in messages to see it there are any errors. I would also make sure that your ISPO (assuming you are using Nokia) is at the latest rev for your release and that you are on the latest HFA for Checkpoint. Can you provide some details of your configuration? |
| |||
| In VRRP-HA constellation there are IMHO two reasons for backup-instance to take over: - no vrrp-advertisements are seen from any vrrp-configured interfaces - vrrp-advertisements are seen with lower prio than the own If so, backup should start to send vrrp-advertisements with its prio. As they are higher, "old master" should stop sending vrrp-advertisements, become backup and "old backup" should become master. Check your vrrp traffic on external and internal clusterinterfaces on both machines (four interfaces in summary) and pay special attention to prios in vrrp-packets. To do so run from a console: tcpdump -i <clusterinterface> ip proto 112 If master/backup state is clear, only master should send advertisements. You will see them only from physical interfaces source address, not from virtual cluster ip. kind regards |
| |||
| thanks for all your input, apparently there was a rogue machine with the same ip address causing the master to lock up, once this was turned off the master is functioning normally thanks |
![]() |
| Thread Tools | |
| Display Modes | |
| |