@FrankZ said:
Is the /17 you talking about in the 47.87.xx.xx range ?
Yes
@lesuser said: Which company are you talking about here? Hivelocity?
It's the Alibaba IPv4 from Zenlayer. After NYC gets forced to change because they didn't respond with LOA, the major location left over that uses them is LAX.
@FrankZ said:
Is the /17 you talking about in the 47.87.xx.xx range ?
Yes
@lesuser said: Which company are you talking about here? Hivelocity?
It's the Alibaba IPv4 from Zenlayer. After NYC gets forced to change because they didn't respond with LOA, the major location left over that uses them is LAX.
But also Dallas, Atlanta & Seattle, at least I have IPs in that range there. Unless you are saying those aren't major or aren't going to be locations due to the Dedipath stuff.
Due to the way everything works, logistically speaking, it's best to remove the old IPv4 address completely. It's already much more complicated than usual since we're doing larger VLANs and I'm afraid if we keep the old addresses the steps will be even more convoluted and open the door for the process not going very smoothly. Basically for every step that used to be one step, it's now three to four, multiply that out and it makes it much less straightforward.
Plus adding in the old subnets back was basically a "maybe" meaning we had concerns it could end up bringing back our old large VLANs issue, so I think it's best to leave it alone and just focus on making sure everything works well and the process doesn't get riddled with mishaps.
With all that said, what this means is we won't bring back the old IPv4 for the rest of the month for NYC. For others, we can still be more flexible and they'll have access to both old and new for a longer time. We do technically still have them so if it goes super smoothly and we get a lot of requests for it, we'll take a second look and see what's actually plausible.
@tetech said: But also Dallas, Atlanta & Seattle, at least I have IPs in that range there. Unless you are saying those aren't major or aren't going to be locations due to the Dedipath stuff.
I was basically leaving out anything Dedipath, those are still up in the air since it could end up being an IP change required unrelated to anything else. But there are a small number of servers elsewhere that aren't Dedipath and using ZL outside of LAX, yes.
The locations you mentioned could still end up getting migrations to other locations.
I would expect that for those of you who have turned off VNC in the SolusVM panel, it is time to turn it back on. At least for DCs that have potential IP changes.
@tetech said: But also Dallas, Atlanta & Seattle, at least I have IPs in that range there. Unless you are saying those aren't major or aren't going to be locations due to the Dedipath stuff.
I was basically leaving out anything Dedipath, those are still up in the air since it could end up being an IP change required unrelated to anything else. But there are a small number of servers elsewhere that aren't Dedipath and using ZL outside of LAX, yes.
The locations you mentioned could still end up getting migrations to other locations.
Thanks for the clarification. The only thing I hope is that there's a Dallas option. Other stuff I don't care where it ends up or if IPs change.
NYCB020 is going to end up being short some IPv4 addresses, we're moving forward with doing a lot of other things that have a more crucial timeline, but in case it reaches worst case scenario it means some people will not receive a notice and their service will go back online with the old IPv4 address that won't be working.
Same thing for few people on NYCB038 most likely (so to be clear I'm speaking about maybe 5 to 10% of the people on here.)
If there's time beforehand, I'll definitely send something out, the solution will be to migrate those over after maintenance completes so it just means a little bit extra time.
I will also say after we're done with NYC maintenance, IPv4 connectivity is going to be a little rocky. Similar to last time where the /17 got pulled away, it will take some time for all routes to start working perfectly and it may even be inaccessible to some people entirely. This is still the best we can do, all other options are worse. If ZL did reply back when we contacted them it would possibly be have been a little bit more smooth. Just wanted to re-iterate that while we did find a solution (new blocks) it's not perfect.
@lesuser said:
One of my DediPath VPS starting with 47.xxx.xxx.xxx is still online while other one 45.xxx.xxx.xxx is offline.
In case it's useful to you so you can back up your stuff, you may just find spotty routing and might find a host you can copy your stuff to. I have a VPS with them in 45.42.214.0/23 and can route to/from some hosts, but not others:
traceroute to 8.8.4.4 (8.8.4.4), 30 hops max, 60 byte packets
1 45.42.215.1 2.298 ms 2.264 ms 2.288 ms
2 * * *
3 45.92.192.124 0.220 ms 0.228 ms 0.216 ms
4 74.201.164.149 0.261 ms 0.293 ms 64.74.240.241 0.238 ms
5 216.52.95.56 0.736 ms 0.723 ms 0.711 ms
6 198.232.115.145 1.511 ms * 1.646 ms
7 156.146.105.165 1.881 ms 1.911 ms 1.797 ms
8 * * *
9 8.8.4.4 2.405 ms 2.411 ms 2.437 ms
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 45.42.215.1 2.413 ms 2.380 ms 2.351 ms
2 45.11.82.30 12.637 ms 12.622 ms 12.604 ms
3 45.92.192.124 0.240 ms 0.223 ms 0.226 ms
4 74.201.164.149 4.122 ms 4.104 ms 4.127 ms
5 216.52.95.89 0.916 ms 216.52.95.25 0.732 ms 216.52.95.89 0.886 ms
6 * * *
7 * * *
8 * * *
9 * * *
odin@loki:1[~]$ ping -qnc 5 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
--- 8.8.4.4 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 1.907/1.942/1.985/0.029 ms
odin@loki:1[~]$ ping -qnc 5 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
--- 1.1.1.1 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4082ms
SolusVM was acting up, unfortunately it wasn't doing well trying to process all the changes, so notifications couldn't finish going on for the changes and they'll have to continue after re-racked.
@JoeMerit said:
My NY, Atlanta & Denver all died. I dont really mind because I backed everything up and moved some processes to other servers.
Kudos. This is a really good answer. There was a surprisingly long time to backup and move services given I thought everything DediPath was going to go down on Friday.
@JoeMerit said:
My NY, Atlanta & Denver all died. I dont really mind because I backed everything up and moved some processes to other servers.
A couple of them are not responding now, it makes me think it's possibly routing related since when you originally mentioned it, they were accessible from the master server. Going to check further.
--
Anyway, SolusVM is not having a good time right now, I'm unable to restore any of Denver. It was already struggling earlier today on the IPv4 changes hence why we couldn't finish them in time. About 40~ of them are ready and waiting for SVM to function.
Okay so the two in Atlanta and two in Denver that went offline are all on the same /22. This is the one we were moving to LAX, perhaps they misunderstood the instructions, could make sense. I could see how this would happen if they went further than I thought with the plan.
Only weird part is the IPMI isn't working either, I wonder if they sent Flex a de-announcement request or something.
(edit) Read through the communication, doesn't seem like they did that, RADB still shows FLEX. Okay, I'm getting some more coffee.
Okay there we go RPKI updated, sort of, routing issue. Contacting IPv4 provider to have it changed back and we'll just scrap the moving blocks idea moving forward. Probably my fault somewhere down the line.
@VirMach said: . Okay, I'm getting some more coffee.
Update on the coffee, I pressed the grind button, packed it down, put my cup and pressed the brew button and heard the wrong noise, turns out I pressed grind (again) and there's ground coffee everywhere. Yeahhhhh I may be exhausted.
Comments
Yes
It's the Alibaba IPv4 from Zenlayer. After NYC gets forced to change because they didn't respond with LOA, the major location left over that uses them is LAX.
But also Dallas, Atlanta & Seattle, at least I have IPs in that range there. Unless you are saying those aren't major or aren't going to be locations due to the Dedipath stuff.
Due to the way everything works, logistically speaking, it's best to remove the old IPv4 address completely. It's already much more complicated than usual since we're doing larger VLANs and I'm afraid if we keep the old addresses the steps will be even more convoluted and open the door for the process not going very smoothly. Basically for every step that used to be one step, it's now three to four, multiply that out and it makes it much less straightforward.
Plus adding in the old subnets back was basically a "maybe" meaning we had concerns it could end up bringing back our old large VLANs issue, so I think it's best to leave it alone and just focus on making sure everything works well and the process doesn't get riddled with mishaps.
With all that said, what this means is we won't bring back the old IPv4 for the rest of the month for NYC. For others, we can still be more flexible and they'll have access to both old and new for a longer time. We do technically still have them so if it goes super smoothly and we get a lot of requests for it, we'll take a second look and see what's actually plausible.
I was basically leaving out anything Dedipath, those are still up in the air since it could end up being an IP change required unrelated to anything else. But there are a small number of servers elsewhere that aren't Dedipath and using ZL outside of LAX, yes.
The locations you mentioned could still end up getting migrations to other locations.
I would expect that for those of you who have turned off VNC in the SolusVM panel, it is time to turn it back on. At least for DCs that have potential IP changes.
For staff assistance or support issues please use the helpdesk ticket system at https://support.lowendspirit.com/index.php?a=add
Time to test if my idea to throw my proxy behind tailscale network will work and I don't have to adjust anything after IP migration
Haven't bought a single service in VirMach Great Ryzen 2022 - 2023 Flash Sale.
https://lowendspirit.com/uploads/editor/gi/ippw0lcmqowk.png
For me IP change doesn't matter as I am just using VPS to host blogs. So no matter what the IP is, I am fine with it.
Fast as fuck Core i9 VPS (aff) | Powerful AMD Ryzen VPS (aff)
Thanks for the clarification. The only thing I hope is that there's a Dallas option. Other stuff I don't care where it ends up or if IPs change.
NYCB020 is going to end up being short some IPv4 addresses, we're moving forward with doing a lot of other things that have a more crucial timeline, but in case it reaches worst case scenario it means some people will not receive a notice and their service will go back online with the old IPv4 address that won't be working.
Same thing for few people on NYCB038 most likely (so to be clear I'm speaking about maybe 5 to 10% of the people on here.)
If there's time beforehand, I'll definitely send something out, the solution will be to migrate those over after maintenance completes so it just means a little bit extra time.
I will also say after we're done with NYC maintenance, IPv4 connectivity is going to be a little rocky. Similar to last time where the /17 got pulled away, it will take some time for all routes to start working perfectly and it may even be inaccessible to some people entirely. This is still the best we can do, all other options are worse. If ZL did reply back when we contacted them it would possibly be have been a little bit more smooth. Just wanted to re-iterate that while we did find a solution (new blocks) it's not perfect.
One of my DediPath VPS starting with 47.xxx.xxx.xxx is still online while other one 45.xxx.xxx.xxx is offline.
Fast as fuck Core i9 VPS (aff) | Powerful AMD Ryzen VPS (aff)
+1 hoping Dallas is able to remain
In case it's useful to you so you can back up your stuff, you may just find spotty routing and might find a host you can copy your stuff to. I have a VPS with them in 45.42.214.0/23 and can route to/from some hosts, but not others:
It's time to ditch IPv4 completely and give everyone a routed /56.
Accepting submissions for IPv6 less than /64 Hall of Incompetence.
SolusVM was acting up, unfortunately it wasn't doing well trying to process all the changes, so notifications couldn't finish going on for the changes and they'll have to continue after re-racked.
NY, denver gone offline
Yep, me too. DENZ001 NYCB015
For staff assistance or support issues please use the helpdesk ticket system at https://support.lowendspirit.com/index.php?a=add
NYCB028 is down
New York expected, Denver, not so much. Taking a look and then most likely loading in from backups.
All in NY are offline.
https://status.virm.ac
ServerStatus , slackvpn <-- openVPN auto install script for Slackware 15
My NY, Atlanta & Denver all died. I dont really mind because I backed everything up and moved some processes to other servers.
Atlanta's should still be online.
Denver, evaluating still, that one's unplanned.
NYC is scheduled maintenance, the hardware was handed over basically it's being moved into a new cabinet.
Kudos. This is a really good answer. There was a surprisingly long time to backup and move services given I thought everything DediPath was going to go down on Friday.
For staff assistance or support issues please use the helpdesk ticket system at https://support.lowendspirit.com/index.php?a=add
A couple of them are not responding now, it makes me think it's possibly routing related since when you originally mentioned it, they were accessible from the master server. Going to check further.
--
Anyway, SolusVM is not having a good time right now, I'm unable to restore any of Denver. It was already struggling earlier today on the IPv4 changes hence why we couldn't finish them in time. About 40~ of them are ready and waiting for SVM to function.
Okay so the two in Atlanta and two in Denver that went offline are all on the same /22. This is the one we were moving to LAX, perhaps they misunderstood the instructions, could make sense. I could see how this would happen if they went further than I thought with the plan.
Only weird part is the IPMI isn't working either, I wonder if they sent Flex a de-announcement request or something.
(edit) Read through the communication, doesn't seem like they did that, RADB still shows FLEX. Okay, I'm getting some more coffee.
Okay there we go RPKI updated, sort of, routing issue. Contacting IPv4 provider to have it changed back and we'll just scrap the moving blocks idea moving forward. Probably my fault somewhere down the line.
Update on the coffee, I pressed the grind button, packed it down, put my cup and pressed the brew button and heard the wrong noise, turns out I pressed grind (again) and there's ground coffee everywhere. Yeahhhhh I may be exhausted.
Get some sleep. Monday is coming oh so soon.
For staff assistance or support issues please use the helpdesk ticket system at https://support.lowendspirit.com/index.php?a=add
Monday is federal holiday.
Accepting submissions for IPv6 less than /64 Hall of Incompetence.
NYC is all racked up and getting wired.
@VirMach, is Denver moving to L.A currently?
oh my sides the setup fee is increased to $30. that's it, I'm going to renew my tokyo into yearly.
Thank you for your effort fighting those cheap mjj abusing resources in tokyo region. finally i can at ease knowing i have decent dns mirror in jp
Fuck this 24/7 internet spew of trivia and celebrity bullshit.