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

Astaro Rebooting for no Reason

I have UTM 9 with a purchased subscription.
Here's the background info:
Had Astaro 8 in a physical machine serving 50 or 60 devices. It never crashed or gave me any issues at all.
Decided to virtualize in Hyper-V and upgrade to UTM 9 serving the same amount of devices. Server randomly reboots
Spent multiple hours with support, this form, log files, reconfiguring from scratch, etc. Nothing helped. I still exprienced random reboots.
Moved UTM 9 to a physical machine last Friday: same random reboots for no apparent reason.

This situation is extremely frustrating. I'm going to downgrade to 8 -- when all users leave the office and waste just a little bit more of my time to keep giving this distro a shot as I already paid for it.

If anyone has got ANY suggestion please help! I'm desperate and extremely frustrated now. Please do NOT suggest:
It's a UPS problem
CPU cooling issue
Reconfigure from scratch
Serious corruption


This thread was automatically locked due to age.
  • keep giving this distro a shot as I already paid for it.

    The licensing for the UTM is valid for V9 and V8 interchangably.  Licensing for your own hardware is the same as licensing for a virtual instance; it's only in the case of the Astaro/Sophos appliances that different licenses are required.  Your reseller should have sold you a renewal of your existing license, not a new one.

    If you loaded the zip instead of installing from the software ISO, that also might be your problem.

    It's great to have a hardware geek like William around - I think you nailed that one, my friend!

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • No problems with the licensing. I did get a renewal, and I did install from scratch from the software ISO. But many thanks for the suggestion!

    So, after disabling uplink monitoring, reboots seem to happen every few hours now instead of every few minutes. I was thinking back to when I used to have no problems with Astaro at all and why it started acting up.

    Before, when I had no issues:
    Single Internal NICs, 2 addresses on different subnets -- note the subnets are not physically distinct.

    Today:
    2 different NICs, each with their own address. -- note the subnets are not physically distinct, so both NICs go to the same network.

    I see a lot of martian packet messages in the kernel log so I have the suspicion that the 2 different NICs with different addresses, going to the same physical network might be causing an issue. Can anyone confirm that this was a bad idea/bad setup? Or is this a valid setup? My intent was to increase perfromance but I am no expert here and maybe link aggregation would've been a much better option... Any help is appreciated!
  • I see a lot of martian packet messages in the kernel log so I have the suspicion that the 2 different NICs with different addresses, going to the same physical network might be causing an issue. Can anyone confirm that this was a bad idea/bad setup? Or is this a valid setup? My intent was to increase perfromance but I am no expert here and maybe link aggregation would've been a much better option... Any help is appreciated!

    Yes, link aggregation is the right answer.  I would have expected you to have routing problems not random reboots. 

    Cheers - Bob

    Sorry for any short responses!  Posted from my iPhone.
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I would expect Network errors rather than reboots too. As a side note and Reading my post again, I Just want to make it clear that in both scenarios the addresses are in 2 different logical Networks. So far no reboots after 15 hours going back to my original setup. Will check for Martian packets shortly.
  • Normal load -- around 60 users. No martian packet kernel messages. No reboots. Looks like adding a logical subnet on the same NIC rather than having them on separate NICs did the trick. Running on Hyper-V 2012 without issues so far. 

    I still don't think it's good practice to have 2 subnets on the same NIC but again, I am no expert. Can anyone provide some advice? Is this ok, or is this really poor practice? I can't use bridging because the subnets are disjoint... one on 192.168.42.0/255.255.255.0 and the other on 172.16.16.0/255.255.252.0 and I think link aggregation just adds bandwidth which I don't need at this point as I have 1Gbps links. Some advice from anyone would be  very helpful.
  • The only thing is that you will not have traffic isolation between the two subnets. A system in one IP subnet will be able to use proxy ARP to communicate directly with a system in the other IP subnet without going through a router. Also, broadcasts/multicasts in the one subnet will be seen by all nodes in the broadcast domain, regardless of the IP subnet in which they reside.

    bryan
  • Thanks so much Bryan. I trust my users so the disadvantages you mention are fine in this particular case.
  • Hi,

    You could use VLANs if you wanted more isolation.

    Barry
  • VLANs would be a good idea. Thanks for your suggestion! 
    Back to the main issue: 21 hours and 30 minutes without restarts. Heavy user load.

    I think the issue is gone now. I moved the firewall back to Hyper-V without problems. Will post again if this issue comes back.
    Thanks everybody for your suggestions.
  • Yes, that would cause the martians.  It sounds like you'd be better off with Link Aggregation.  Probably you also only want a single subnet. 

    Cheers - Bob

    Sorry for any short responses!  Posted from my iPhone.
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA