This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RED 50 does not start - even though it is shown online in the ASG

Hey there!

We are facing a more or less huge problem in our company at the moment. Maybe someone of you can help.

The problem occurs with a RED50. It is shown online in our ASG 220 (UTM 9.1), and a few seconds later it is shown offline. This state changes about three times in ten seconds. So it always says "Last contact 3 seconds ago" in the ASG.

We have faced similar issues with older RED 10s. In those cases the problem could be solved by just powering off the RED for a while.
But in this case it does not work this way. Even deleting the RED from our ASG and re-adding it did not help.
The RED 50's display keeps saying "Starting RED.. "

Attached you find an extract of the RED log. 
It would be awesome if someone of you knew how to get me out of this, as this means a huge problem to us. 

2014:03:14-20:15:07 gw01 red_server[7681]: A340076EE0A7DED is disconnected.
2014:03:14-20:15:08 gw01 red_server[8042]: SELF: Starting REDv2 protocol
2014:03:14-20:15:08 gw01 red_server[8042]: A340076EE0A7DED: connected OK, pushing config
2014:03:14-20:15:08 gw01 red_server[8042]: A340076EE0A7DED: Sending PEERS+92.50.119.19+80.152.160.31+80.152.160.50
2014:03:14-20:15:10 gw01 red_server[8042]: A340076EE0A7DED: command 'UMTS_STATUS value=OK'
2014:03:14-20:15:11 gw01 red_server[8042]: A340076EE0A7DED: command 'PING 0 uplink=WAN'
2014:03:14-20:15:11 gw01 red_server[8042]: id="4201" severity="info" sys="System" sub="RED" name="RED Tunnel Up" red_id="A340076EE0A7DED" forced="0"
2014:03:14-20:15:11 gw01 red_server[8042]: A340076EE0A7DED: PING remote_tx=0 local_rx=0 diff=0
2014:03:14-20:15:11 gw01 red_server[8042]: A340076EE0A7DED: PONG local_tx=0
2014:03:14-20:15:20 gw01 red2ctl[5024]: Overflow happened on reds3:0
2014:03:14-20:15:20 gw01 red2ctl[5024]: Missing keepalive from reds3:0, disabling peer 80.101.150.67
2014:03:14-20:15:25 gw01 red_server[8042]: A340076EE0A7DED: command 'PING 0 uplink=WAN'
2014:03:14-20:15:25 gw01 red_server[8042]: A340076EE0A7DED: PING remote_tx=0 local_rx=0 diff=0
2014:03:14-20:15:25 gw01 red_server[8042]: A340076EE0A7DED: PONG local_tx=0
2014:03:14-20:15:30 gw01 red2ctl[5024]: Received keepalive from reds3:0, enabling peer 80.101.150.67
2014:03:14-20:15:50 gw01 red2ctl[5024]: Missing keepalive from reds3:0, disabling peer 80.101.150.67
2014:03:14-20:15:56 gw01 red_server[8042]: A340076EE0A7DED: No ping for 30 seconds, exiting.
2014:03:14-20:15:56 gw01 red_server[8042]: id="4202" severity="info" sys="System" sub="RED" name="RED Tunnel Down" red_id="A340076EE0A7DED" forced="0"
2014:03:14-20:15:56 gw01 red_server[8042]: A340076EE0A7DED is disconnected.


Thank you very much in advance!

Best Regards,
Sebastian


This thread was automatically locked due to age.
Parents Reply

  • beside that, i'll run some test with the 9.3090003 which was release today. It has a fix for some other RED issues... 

     Fix [34558]: RED frequently reconnecting because configuring an Additional Address as UTM-Hostname


    We had the "overflow happened" issue on our RED 50 with UTM release 9.308-16. A lot of troubleshooting together with the support, but nothing helped. Then because of another issue we just rebooted the UTM - and the issue was gone!

    To be sure we upgraded to 9.3090003, and in the last 24 hours there was not one "overflow" error.
Children
  • We had the "overflow happened" issue on our RED 50 with UTM release 9.308-16. A lot of troubleshooting together with the support, but nothing helped. Then because of another issue we just rebooted the UTM - and the issue was gone!

    To be sure we upgraded to 9.3090003, and in the last 24 hours there was not one "overflow" error.



    Unfortunately the overflow problem with RED50 still exists in 9.3090003
    Rebooting the Devices is also no solution.
  • Unfortunately the overflow problem with RED50 still exists in 9.3090003
    Rebooting the Devices is also no solution.


    You are right, the issue reappeared at the next reboot of the UTM. Premium support is working on it right now...