CPUG: The Check Point User Group

Resources for the Check Point Community, by the Check Point Community.


First, I hope you're all well and staying safe.
Second, I want to give a "heads up" that you should see more activity here shortly, and maybe a few cosmetic changes.
I'll post more details to the "Announcements" forum soon, so be on the lookout. -E

 

Results 1 to 2 of 2

Thread: IP290 Gaia R77.20 VRRP backup becomes master problem

  1. #1
    Join Date
    2012-08-06
    Posts
    63
    Rep Power
    8

    Default IP290 Gaia R77.20 VRRP backup becomes master problem

    Hi all,

    We have problems where the backup VRRP routers of one of two IP290s running Gaia R77.20 becomes VRRP master thus trashing the network until we power it off.

    It seems to be related to enabling DHCP relay on one VLAN. (Don't ask me what that would have anything to do with it. Rather I am asking you. :) )

    It's not assuming VRRP master role for all the interfaces, but a random subset, different each time.

    The backup appliance is totally unresponsive trying to capture what's going on:

    Code:
    CLISH> show vrrp summary
    RTGRTG0019  tclproc: {Timeout waiting for response from database server.
    I've turned tracing and everything on.

    The following section in routed.log repeats as long as everything is ok.

    Code:
    Jan 11 05:58:48 MonAccept: connection from 
    Jan 11 05:58:48 task_alloc: allocated task block for MON_SESSION priority 70
    Jan 11 05:58:48 task_set_socket: task MON_SESSION socket 25
    Jan 11 05:58:48 task_set_option: task MON_SESSION. socket 25 option ReUseAddress(3) value 1
    Jan 11 05:58:48 task_set_option: task MON_SESSION. socket 25 option RecvBuffer(0) value 65535
    Jan 11 05:58:48 task_set_option: task MON_SESSION. socket 25 option SendBuffer(1) value 65535
    Jan 11 05:58:48 task_set_option: task MON_SESSION. socket 25 option NonBlocking(8) value 1
    Jan 11 05:58:48 task_set_socket: task MON_SESSION. socket 25
    Jan 11 05:58:48 task_create: MON_SESSION.  socket 25
    Jan 11 05:58:48 MonRecv: end of session from 
    Jan 11 05:58:48 task_delete: deleting task MON_SESSION.
    Jan 11 05:58:48 task_close: close socket 29 task MON_SESSION.
    Jan 11 05:58:48 task_reset_socket: task MON_SESSION. socket 29
    Jan 11 05:58:48 task_job_delete_task: deleting all jobs for task MON_SESSION.
    Jan 11 05:58:48 task_job_deleted_task: no jobs found for task MON_SESSION.
    Jan 11 05:58:48 task_job_create: create foreground job task_collect for task Scheduler
    Jan 11 05:58:48 task_job_fg_dispatch: running foreground job task_collect for task Scheduler
    Jan 11 05:58:48 task_collect_job: freeing task MON_SESSION (DELETED)
    Jan 11 05:58:48 task_job_fg_dispatch: completed foreground job task_collect for task Scheduler
    Then this starts:

    Code:
    Jan 11 05:58:48 
    Jan 11 05:58:48 
    Jan 11 05:58:48 task_process_sockets: recv ready for VRRP
    Jan 11 05:58:48 vrrp_recv:
    Jan 11 05:58:48 task_receive_packet: task VRRP from 192.168.215.9 to 224.0.0.18 socket 24 length 40
    Jan 11 05:58:48 VRRP RECV 192.168.215.9 -> 224.0.0.18  Inteface: eth2.215
    	vers 2, cmd Advertise, length 20
    	vrid 11, priority 248, advertise interval 1
    	addresses: 192.168.215.1
    	authentication: xxxx
    Jan 11 05:58:48 task_timer_uset: timer VRRP_VRRP <OneShot> set to offset 3.043137 at 06:00:52
    Jan 11 05:58:48 
    Jan 11 05:58:48 task_process_sockets: recv ready for VRRP
    Jan 11 05:58:48 vrrp_recv:
    Jan 11 05:58:48 task_receive_packet: task VRRP from 192.168.222.9 to 224.0.0.18 socket 24 length 40
    Jan 11 05:58:48 VRRP RECV 192.168.222.9 -> 224.0.0.18  Inteface: eth2.35
    	vers 2, cmd Advertise, length 20
    	vrid 11, priority 248, advertise interval 1
    	addresses: 192.168.222.1
    	authentication: xxxx
    Jan 11 05:58:48 task_timer_uset: timer VRRP_VRRP <OneShot> set to offset 3.043137 at 06:00:52
    Jan 11 05:58:48 task_receive_packet: task VRRP from 172.31.32.124 to 224.0.0.18 socket 24 length 40
    Jan 11 05:58:48 VRRP RECV 172.31.32.124 -> 224.0.0.18  Inteface: eth2.57
    	vers 2, cmd Advertise, length 20
    	vrid 11, priority 248, advertise interval 1
    	addresses: 172.31.32.126
    	authentication: xxxx
    There's lots more output, and it stops right after this:

    Code:
    Jan 11 05:58:53 task_ifaddr_change(427): Set the cluster flag for 192.168.222.1(eth2.35) if clustered
    Jan 11 05:58:53 task_ifaddr_change(447): Setting cluster flag for 192.168.222.1(eth2.35) 
    Jan 11 05:58:53 
    Jan 11 05:58:53 task_ifaddr_change: Starting ifaddr_change of 192.168.222.1(eth2.35) for task IF for instance default
    Jan 11 05:58:53 task_ifaddr_change: Finished ifaddr_change of 192.168.222.1(eth2.35) for task IF for instance default
    Jan 11 05:58:53 
    Jan 11 05:58:53 task_ifaddr_change: Starting ifaddr_change of 192.168.222.1(eth2.35) for task BOOTPGW.0.0.0.0+67 for instance default
    Jan 11 05:58:53 task_ifaddr_change: Finished ifaddr_change of 192.168.222.1(eth2.35) for task BOOTPGW.0.0.0.0+67 for instance default
    Jan 11 05:58:53 Adding Virtual MAC 00:00:5e:00:01:0b for Virtual IP 10.30.10.1 on interface eth5.212, vmac mode 0
    Jan 11 05:58:53 task_send_packet_iovec: task VRRP socket 24 length 40 if_index 15 to 224.0.0.18
    Jan 11 05:58:53 VRRP SENT 10.30.10.8 -> 224.0.0.18 
    	vers 2, cmd Advertise, length 20
    	vrid 11, priority 244, advertise interval 1
    	addresses: 10.30.10.1
    	authentication: xxxx
    Jan 11 05:58:53 VRRP SENT 10.30.10.8 -> 224.0.0.18 
    	vers 2, cmd Advertise, length 20
    	vrid 11, priority 244, advertise interval 1
    	addresses: 10.30.10.1
    	authentication: xxxx
    Jan 11 05:58:53 task_timer_uset: timer VRRP_VRRP <Processing> set to interval 1 at 06:00:52
    Jan 11 05:58:53 vrrp_vr_master: interface eth5.212, VRID 11: state=MASTER
    Then everything is dead. Including access to all those VLANs because both appliances wanna be master. Until I shut down the backup VRRP appliance.

    Using fw mon you clearly see both receiving each other's advertisements.

    I'm in contact with support but still no valuable results.

    What does this sound like to you? Anyone here wanna try a shot in the dark?

    Thanks!

  2. #2
    Join Date
    2012-08-06
    Posts
    63
    Rep Power
    8

    Default Re: IP290 Gaia R77.20 VRRP backup becomes master problem

    FYI I may have found something.

    It turns out that issuing SNMP requests during a failover will bring routed to a halt.

    Do not try this at home: Start an snmpwalk loop over the VRRP MIB from your management station, and then go play with interfaces etc. to provoke a failover, and there you go. OMG.

    I am not yet 100% sure if this is our original scenario (both becoming master), but in any case this brings us very much closer.

    Let's see what the support people say. This week everything has been very quiet. Everybody including the reseller support seems to be on vacation, well....

Similar Threads

  1. VRRP is master-Master in External Interface
    By fasuha in forum Management High Availability
    Replies: 1
    Last Post: 2013-09-25, 23:57
  2. VRRP Issue, effective priority has been decreased on both master and backup firewall
    By Justinmelani in forum Check Point IP Appliances and IPSO (Formerly Sold By Nokia)
    Replies: 3
    Last Post: 2011-09-04, 03:27
  3. Script for IPSO/VRRP: Switch VRRP-Master > Backup
    By area51 in forum Scripts and Tools
    Replies: 3
    Last Post: 2011-03-13, 06:22
  4. Master - Master VRRP State
    By v33dubya in forum Check Point IP Appliances and IPSO (Formerly Sold By Nokia)
    Replies: 4
    Last Post: 2010-06-02, 01:07
  5. VRRP master issues....
    By mattylad in forum Check Point IP Appliances and IPSO (Formerly Sold By Nokia)
    Replies: 5
    Last Post: 2006-08-18, 09:58

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •