Hi,
Around 08:06Z today we received an alert regarding host
snaps.bitfolk.com. I found it completely unresponsive over network,
but was still able to connect to its console.
Despite it believing its network interfaces were up and had link, it
was passing no traffic to the colo switches.
I spent about 30 minutes trying to diagnose this and not getting
anywhere, so decided to try rebooting it. As I had console access I
was able to cleanly shut down all VPSes on snaps first.
The shutdown and boot went without incident and things seemed fine
on boot. By about 08:40Z all VPSes that should be running had been
started, and by now Nagios is clear of alerts¹.
I am aware that snaps had an unexplained outage a few months ago, on
28 September. This time the symptoms are not the same, other than
that the problem is unexplained and clears after a reboot.
Clearly there is something wrong there though and it's going to
happen again, so over the next few days we will be moving customers
off of snaps. We will co-ordinate this directly with customers
involved.
Apologies for the disruption,
Andy
BitFolk Ltd
¹ Except for one customer web server which is waiting for a TLS
passphrase to be supplied before it will start.
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hi Andreas,
On Tue, Dec 19, 2017 at 09:17:46AM +0100, Andreas Olsson wrote:
> Is it just me, or has Bitfolk's IPv6 connectivity been a bit unreliably
> these last few months?
I'm sorry about this, it is a known issue that I am working on.
The trigger of the problem is that Jump (our transit provider) has a
router which has some sort of intermittent fault and has been
rebooting itself. For the last few months they've been replacing
bits of it to try to track down where the fault lies, but haven't
got to the bottom of it yet. They're going to replace it entirely in
January.
As far as IPv4 goes, VRRP is in use and so when this router dies you
don't really notice.
On the IPv6 side of things it's relying on the usual IPv6 router
advertisements and something is wrong with BitFolk's configuration
there.
All of BitFolk's hosts have two IPv6 default routes learned from
router advertisements, and what is supposed to happen is that when
of the routers dies the route is removed. This isn't happening, so
the useless route stays there until the expiry time (30 minutes) or
the reconvergence after the faulty router has rebooted (about 10
minutes).
I've been trying to work out why BitFolk's setup doesn't remove the
useless route, trying stuff out in test networks etc and so far I
can't work out what is different in BitFolk's setup to make it not
work. I will continue working on that even after Jump's router is
replaced.
I will keep you up to date on developments with this.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
I've lowered the cost of 10GB of additional data transfer by half,
so the changes are:
----------+-------+------
| Old | New
----------+--------------
Monthly | £0.50 | £0.25
Quarterly | £1.40 | £0.70
Yearly | £5.00 | £2.50
----------+-------+------
If you do not already pay for additional monthly data transfer then
the rest of this email probably won't be of interest.
Those paying by Direct Debit will just be charged less. Those paying
by PayPal have already had their subscription details altered and
PayPal should have told you about that.
Those paying by standing order will need to take care to adjust their
regular payment otherwise you will be paying too much. It will build
up as credit on your account. You can see the cost of your current
spec at:
https://panel.bitfolk.com/account/config/
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting