Hi all,
This week the bare-metal provider that I rent servers from, for all of my online stuff, let me know that there's an IPv6 misconfiguration on the server that hosts Beyond3D that upsets some new monitoring they have in place on the switches the servers are connected to.
I spent a whole bunch of time this week trying to correct that, which resulted in some brief periods of downtime up to 15 mins each while the entire host was rebooted. There was also an extended period of over an hour where the provider automatically paused all networking for a brief period because I was triggering their monitoring system, locking out all connectivity to the outside world.
I could have avoided the full reboots, but I'm pretty inexperienced in the particular networking technology in question and misconfigured the main network interface twice. So I apologise for all of the cumulative downtime spread out this week.
The upshot is that I can't solve the problem quickly, so in order to stop my provider from being upset I'm going to have to remove IPv6 connectivity from that server altogether while I learn how to configure it properly. IPv4 will still work just fine, so we won't fall off the Internet, but IPv6 will stop.
I aim to bring it back at the end of the year when I have more time to learn, practice the configuration on a test server, and then apply it to the production server.
There might be some minor downtime while I remove IPv6, but I can hopefully avoid that. I'll start with removing the AAAA records from DNS, before tearing down the connectivity on the VM interfaces, then the top level host.
I doubt anyone really cares, but transparency to let you know what's going on is best.
Also, love you lots
This week the bare-metal provider that I rent servers from, for all of my online stuff, let me know that there's an IPv6 misconfiguration on the server that hosts Beyond3D that upsets some new monitoring they have in place on the switches the servers are connected to.
I spent a whole bunch of time this week trying to correct that, which resulted in some brief periods of downtime up to 15 mins each while the entire host was rebooted. There was also an extended period of over an hour where the provider automatically paused all networking for a brief period because I was triggering their monitoring system, locking out all connectivity to the outside world.
I could have avoided the full reboots, but I'm pretty inexperienced in the particular networking technology in question and misconfigured the main network interface twice. So I apologise for all of the cumulative downtime spread out this week.
The upshot is that I can't solve the problem quickly, so in order to stop my provider from being upset I'm going to have to remove IPv6 connectivity from that server altogether while I learn how to configure it properly. IPv4 will still work just fine, so we won't fall off the Internet, but IPv6 will stop.
I aim to bring it back at the end of the year when I have more time to learn, practice the configuration on a test server, and then apply it to the production server.
There might be some minor downtime while I remove IPv6, but I can hopefully avoid that. I'll start with removing the AAAA records from DNS, before tearing down the connectivity on the VM interfaces, then the top level host.
I doubt anyone really cares, but transparency to let you know what's going on is best.
Also, love you lots
