Renumbering for customers

From BitFolk
Jump to navigation Jump to search

This article should provide all of the information BitFolk customers will need to renumber the IP address(es) of their VPSes from 212.13.194.0/23 to 85.119.80.0/21.

Background

This article only covers customer concerns. For a full overview of the renumbering, please see the overall plan.

Do I need to renumber?

If you VPS currently has only IP addresses of the form 85.119.82.* or 85.119.83.* then you're already using the new IP address range. This would be the case for VPSes set up on or after 4th November 2011. You can ignore all of this if so.

Timeline

Here are some hints as to when you can expect things to happen. You should consider these dates as a "not before this date" rather than "exactly on this date".

Friday 4th November 2011

All customers received email notification that renumbering their VPSes will be necessary, and that the new IP addresses have been routed to them.

From this point forward, BitFolk will be reconfiguring the secondary name servers to take an AXFR from both the old and new master IP addresses. This will ensure that AXFR continues to work for those customers making use of BitFolk's secondary name service.

Also for those customers making use of BitFolk's free backups service, BitFolk will be checking whether the new IP address assigned to each customer becomes active, and reconfiguring backups to use it if so.

Wednesday 7th December 2011

BitFolk's Nagios monitoring was switched to only monitor the new IP addresses.

This resulted in alerts being sent to any customer with monitoring set up who hadn't yet renumbered their VPS. The alerts will fix themselves once you complete the renumbering.

If you are not yet ready to do the renumbering, you should acknowledge the alerts. They will not notify you again until after the host comes up on the new IP.

Tuesday 7th February 2012

212.13.194.0/23 will cease being routed, meaning that old IP addresses will stop receiving traffic.

How to renumber

Warning Warning: It is advisable to do all work below from your VPS's console as accessed via the Xen Shell. If you make a mistake with your network configuration and you're connected over SSH, your session will become inaccessible, whereas a console session would be unaffected. This also makes sure that you do have access to your Xen Shell; the worst time to discover you've forgotten the password is when your VPS is down!

These instructions should be correct for any modern Linux kernel, and will reconfigure the networking of the running VPS without outage.

Should you encounter any problems with this procedure, check the list of common issues at the bottom of this article.

Your IP address(es) and default gateway

Every BitFolk VPS has at least one IPv4 address from the deprecated range, of the form 212.13.194.x or 212.13.195.x. To determine your new IPv4 address(es), just translate as follows:

  • 212.13.194.x → 85.119.82.x
  • 212.13.195.x → 85.119.83.x

So, for example, 212.13.194.70 would become 85.119.82.70 and 212.13.195.95 would become 85.119.83.95.

Your new netmask is 255.255.248.0 (a /21) and your new default gateway is 85.119.80.1.

At the moment both the deprecated IP addresses and the new IP addresses are routed to your VPS. You can verify that this is the case by doing a tcpdump of "ARP" traffic on your VPS while pinging one of your new IP addresses from elsewhere: 

root@vps# tcpdump -pni eth0 'arp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
08:53:59.063598 arp who-has 85.119.82.70 tell 85.119.80.16
08:54:00.063615 arp who-has 85.119.82.70 tell 85.119.80.16
08:54:01.059631 arp who-has 85.119.82.70 tell 85.119.80.16
08:54:03.067666 arp who-has 85.119.82.70 tell 85.119.80.16
Ctrl-c
root@vps#

This shows that packets for 85.119.82.70 would be routed to you if your VPS knew to respond to them.

What you need to do now is:

  1. Bring up each of your new IPv4 addresses and reconfigure networking so that your old IP addresses are just aliases.
  2. Make sure all your services are listening on both the new and old IP addresses.
  3. Make sure any external references to IP addresses such as DNS are updated to use the new addresses.
  4. Disable the old IP addresses to be sure that everything still works without them.

You do not need to reboot your VPS in order to complete the renumbering. You may wish to shut down and boot up again anyway as a final check that you have everything configured correctly on boot.

Single IPv4 address

Check out your existing IP address setup: 

# ip -4 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 212.13.195.104/23 scope global eth0

And your routing table: 

# ip -4 route show
212.13.194.0/23 dev eth0  proto kernel  scope link  src 212.13.195.104 
default via 212.13.194.1 dev eth0 metric 100

Add your new IP address: 

# ip addr add 85.119.83.104/21 dev eth0

At this point your new IP address, 85.119.83.104, should be fully working and pingable from outside your VPS (unless you block ICMP ping, in which case you are a despicable human being you may be making life hard for yourself and others).

If you can't get your new IP address working at this stage, something may be broken. You should contact BitFolk support before proceeding.

Warning Warning: So far you've done nothing that could affect your existing service. From this point on, a mistake could break things. You haven't yet changed any configuration files, so in the worst case you could shut down and boot again to get things back how they were before.

Change your default route by copying what came out of ip route show but using change: 

# ip route change default via 85.119.80.1 dev eth0 metric 100

Now verify that your connectivity to your VPS still works.

Multiple IPv4 addresses

Here's an example of the work needed on a VPS with a main IP address of 212.13.195.104 and an additional address 212.13.195.11.

Check out your existing IP address setup: 

# ip -4 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 212.13.195.104/23 scope global eth0
    inet 212.13.195.11/32 brd 212.13.195.255 scope global eth0:1

And your routing table: 

# ip -4 route show
212.13.194.0/23 dev eth0  proto kernel  scope link  src 212.13.195.104 
default via 212.13.194.1 dev eth0 metric 100

Add your new main IP address: 

# ip addr add 85.119.83.104/21 dev eth0

Add your additional IP address: 

# ip addr add 85.119.83.11/32 dev eth0
Warning Warning: Note that additional IP addresses have a prefix size (the last part after the forward slash) of /32, not /21! Only the first IPv4 address in any subnet would have a prefix size other than /32.

Do this for each additional IP address you have.

Change your default route by copying what came out of ip route show but using change. So, if your current routing table had: 

default via 212.13.194.1 dev eth0

then you'd need to do: 

# ip route change default via 85.119.80.1 dev eth0

But if your routing table had: 

default via 212.13.194.1 dev eth0 metric 100

then you'd need to do: 

# ip route change default via 85.119.80.1 dev eth0 metric 100

Your default gateway will always be 85.119.80.1.

Now verify that your connectivity to your VPS still works.

Making the new configuration permanent


Warning Warning: After you've made the changes below, the only way to be absolutely sure they work would be to shut down and boot again. Please do not do this unless you're absolutely sure you have both console and root access. Any error is likely to be very simple and easy to fix, as long as you have access to do so.


Debian/Ubuntu

On Debian-like hosts, network configuration is in the file /etc/network/interfaces. Before you start it will look something like this:

(All IPv6-related sections omitted from examples since they don't need to be changed) 

# The primary network interface
auto eth0
iface eth0 inet static
        address 212.13.195.104
        netmask 255.255.254.0
        gateway 212.13.194.1

You need to change this for your new main IP address, and add the deprecated IP address as an alias: 

# The primary network interface
auto eth0
iface eth0 inet static
        address 85.119.83.104
        netmask 255.255.248.0
        gateway 85.119.80.1

auto eth0:1
iface eth0:1 inet static
        address 212.13.195.104
        netmask 255.255.255.255

Things to note:

  • The main IP's netmask is different; the new IP allocation is 255.255.248.0 (/21) as opposed to 255.255.254.0 (/23).
  • The new gateway is different; 85.119.80.1 as opposed to 212.13.194.1.
  • Interfaces for IP aliases go eth0:1, eth0:2, etc.
  • IP aliases don't have a gateway.

If you have multiple IP addresses then they'll already be present in /etc/network/interfaces. You just need to add the corresponding new addresses in there too.

For example, a VPS with a main IP of 212.13.195.104 and an additional IP 212.13.195.11 should be changed to something like this: 

# New main IP
auto eth0
iface eth0 inet static
        address 85.119.83.104
        netmask 255.255.248.0
        gateway 85.119.80.1

# Former main IP, now deprecated and kept as an alias
auto eth0:1
iface eth0:1 inet static
        address 212.13.195.104
        netmask 255.255.255.255

# My additional IP address
auto eth0:2
iface eth0:2 inet static
        address 85.119.83.11
        netmask 255.255.255.255

# Its deprecated counterpart
auto eth0:3
iface eth0:3 inet static
        address 212.13.195.11
        netmask 255.255.255.255

CentOS/Scientific Linux

On CentOS, Scientific Linux and similar distributions the network configuration can be found in:

  • /etc/sysconfig/network
  • /etc/sysconfig/network-scripts/ifcfg-eth0

Configuration for additional IP addresses would be found in:

  • /etc/sysconfig/network-scripts/ifcfg-eth0:1
  • /etc/sysconfig/network-scripts/ifcfg-eth0:2
  • etc.

First /etc/sysconfig/network which would start out looking something like: 

NETWORKING=yes
NETWORKING_IPV6=yes
HOSTNAME=some.vps.bitfolk.com
GATEWAY=212.13.194.1

The only thing that needs changing here is the GATEWAY, which needs to be changed to 85.119.80.1.

Then change the main IP address details in /etc/sysconfig/network-scripts/ifcfg-eth0. Before: 

# Xen Virtual Ethernet
DEVICE=eth0
BOOTPROTO=static
HWADDR=00:16:5E:00:00:51
IPADDR=212.13.195.104
NETMASK=255.255.254.0
ONBOOT=yes

After: 

# Xen Virtual Ethernet
DEVICE=eth0
BOOTPROTO=static
HWADDR=00:16:5E:00:00:51
IPADDR=85.119.83.104
NETMASK=255.255.248.0
ONBOOT=yes

Finally, create an alias interface file for your deprecated main IP; /etc/sysconfig/network-scripts/ifcfg-eth0:1: 

DEVICE=eth0:1
BOOTPROTO=static
IPADDR=212.13.195.104
NETMASK=255.255.255.255
ONBOOT=yes

If you have multiple IP addresses, create them like /etc/sysconfig/network-scripts/ifcfg-eth0:1 above, but in /etc/sysconfig/network-scripts/ifcfg-eth0:2, /etc/sysconfig/network-scripts/ifcfg-eth0:3 and so on.

Gentoo

Under baselayout-2, network configuration is in the file /etc/conf.d/net. Before any changes, it should look something like this: 

config_eth0="212.13.195.104/23"
routes_eth0="default via 212.13.194.1"

dns_domain="example.com"
dns_servers="85.119.80.232 85.119.80.233"

To permanently add your new IP address to the config, insert the address (complete with /21) into the config_eth0 line, leaving a space between addresses: 

config_eth0="85.119.83.104/21 212.13.195.104/32"
routes_eth0="default via 85.119.80.1"

dns_domain="example.com"
dns_servers="85.119.80.232 85.119.80.233"

Ensure to change the suffix on the deprecated address to /32, as detailed in the previous section.

If you've been following the instructions on this page so far, the dns_servers line will have probably already updated itself; if not, change it to match the addresses given.

For multiple IP addresses, continue to add them to the config_eth0 line. If it's getting too unwieldy for your purposes, you can add each address to a new line, as long as you keep them properly quoted. 

config_eth0="85.119.83.104/21
85.119.83.11/32
212.13.195.104/32
212.13.195.11/32"

routes_eth0="default via 85.119.80.1"

dns_domain="example.com"
dns_servers="85.119.80.232 85.119.80.233"

Reconfiguring services

Many services will listen on all interfaces, so don't need any explicit reconfiguration. Some of your services probably have been configured to only listen on particular IP addresses though, so you will need to go through them all to see what needs to be changed.

In particular you should check /etc/hosts as your old IP address and host name are likely to be hard coded there, and this will affect how your VPS resolves its own name.

If you are running BIND, you may need to edit any zone files (probably located in /etc/bind/) that reference your old IP, then run rndc reload to ensure the updated zone information is used.

It's no harm to leave your services listening on both your new IP addresses and your deprecated ones.

BitFolk Backups

For those taking advantage of BitFolk's free backups service, you should be aware that the backup hosts connect to your VPS by rsync-over-ssh to your IP address.

We would recommend that you leave it at least a week between enabling your new IP addresses and disabling the old ones. During this time we should be able to notice that your new IP address is available and reconfigure our backups to use it without you having to do anything.

In any case, if we notice that your backups have started to fail we will retry them against the new IP address. We should notice this within a day.

If you absolutely want to make sure that your backups have been reconfigured then please feel free to create a support ticket after you've enabled your new IP address, and we'll take care of it.

BitFolk Monitoring

A host that Nagios thinks is down.

For customers whose services are monitored by BitFolk, please note that your host is monitored by IP address.

Acknowledging a host problem.

If you are quick off the mark and manage to complete your renumbering in the first month then you'll start to receive alerts. BitFolk support will notice and update configuration, although it would help if you could acknowledge the alerts (see below) with a useful comment.

Otherwise, one month after the renumbering is announced, BitFolk's monitoring will switch to your new IP address and you'll start receiving alerts. Once you renumber your VPS and reconfigure your services the alerts will go away.

If you wish to stop the alerts firing then you should log in to the Nagios web interface (using your normal BitFolk account credentials) and acknowledge the alerts. They will not fire again until the state changes.

To do this:

  1. Follow the "Service Problems" link at the left.
  2. Click on the link for your host.
  3. Click on "Acknowledge this host problem" from the "Host Commands" box on the right.
  4. Type a comment and hit submit.

You will then receive no more alerts until the status changes (e.g. host recovers because you complete your renumbering).

You can also perform the same steps for individual services. Start with the individual service link instead.

Reverse DNS

Whatever reverse DNS you had set for your deprecated IP addresses has been copied over to your new IP addresses, so should just work. However if you had reverse DNS delegated to your nameservers do bear in mind that you'll probably need to create new zones for those as the zone names are based on the IP addresses themselves.

You will no longer be able to edit the reverse DNS for deprecated IP addresses. Please renumber to the new IP addresses, then you'll be able to edit the reverse DNS for them from the panel as usual.

Your next reboot

All of the new IP addresses have been routed to your running VPS. Because of a curiosity of the way Xen works, that means that if you reboot your VPS it will come back up with only the routes it had last time the virtual machine was created, i.e. none of the new IPs. To avoid this, the next time you want to reboot you should instead shut down and boot again from the Xen Shell.

If you do forget and reboot by accident, log in to your Xen Shell, shut down and boot again.

When to disable your old IP addresses

Technically you don't need to ever disable your old IP addresses. Some time after 6th February 2012 the old IP addresses will stop being routed to you, so you will simply cease receiving packets directed at them.

It's a good idea to disable them yourself though, to reassure yourself that you don't have anything that relies on them working. You could either do this by removing the IP addresses from your running system using ip address delete, or you could remove them from your config files then shutdown and boot again.

IPv6?

Customer IPv6 assignments are also going to need to change eventually, but this will be in some ways easier (because fewer customers actively use IPv6) and in other ways more complex (because each /64 is going to need to change to a /56 or /48). It will be tackled at a later date.

Reinstalling your VPS

If you use the self-serve installer to reinstall your VPS then it will only configure your new IP address(es) in the new VPS. Your deprecated IP address(es) are still routed to you so if you still need to use them you can bring them up and they will continue to work until February 2012.

Questions?

Unless your VPS was set up on or after 4th November 2011 and is already using the new IP range then you are going to have to complete this work in order to avoid disruption to your service. It's therefore very important that you understand what you need to do.

If you have any questions please do not hesitate to ask them, preferably on BitFolk's users mailing list. Other customers are usually very helpful, and BitFolk staff can often find time to respond too.

BitFolk will not be able to carry out this systems administration work for you except as a consultancy service.

Need consultancy?

If you need someone to carry out this work for you then BitFolk staff are available to do so as a consultancy service. This will cost £50+VAT per hour, minimum one hour.

You will need to fully describe what services your VPS is running and list all places that may be referring to your deprecated IP addresses (both within your VPS and outside of BitFolk) before BitFolk is able to provide a quote for this work.

Common problems

"No such process" when attempting to change default route

# ip route change default via 85.119.80.1 dev eth0
RTNETLINK answers: No such process

This indicates that the route can't be added because there is no way to reach 85.119.80.1. The most common reason for that would be that you forgot to add your new IP address(es) first, or you forgot to put the /21 on the end of your address when you added it.

"No such file or directory" when attempting to change default route

# ip route change default via 85.119.80.1 dev eth0
RTNETLINK answers: No such file or directory

Does your existing default route as shown by ip route show have something like metric 100 on the end? You need to copy the existing route as well as the metric: 

# ip route show
212.13.194.0/23 dev eth0 proto kernel scope link src 212.13.194.104
85.119.80.0/21 dev eth0 proto kernel scope link src 85.119.83.253
default via 212.13.194.1 dev eth0 metric 100
# ip route change default via 85.119.80.1 dev eth0 metric 100

Routing to new IP addresses disappears

Have you rebooted your VPS (as opposed to using shutdown or halt and then booting it again from the Xen Shell)? If so, this is due to a peculiarity of how Xen works: rebooting the kernel doesn't cause the virtual machine to be recreated, but does cause your network interface to be brought down and up again.

Bouncing the network interface clears all your routes, then Xen puts back the routes that were in the config file last time it read it. This won't include any routes (IP addresses) added since the last time your VPS was booted from scratch.

To fix, you should use shutdown or halt and then boot again from the Xen Shell. This will cause the VM to be created from your config file, which does include all of your IP addresses.

Hitting "ctrl-o" in the console brings up SysRq

As a nano user you're trying to save a file by hitting ctrl-o, but all it does is print: 

SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E)
memory-full-oom-kill(F) kill-all-tasks(I) thaw-filesystems(J) saK
show-backtrace-all-active-cpus(L) show-memory-usage(M) nice-all-RT-tasks(N)
powerOff show-registers(P) show-all-timers(Q) unRaw Sync
show-task-states(T) Unmount show-blocked-tasks(W) dump-ftrace-buffer(Z)

If you disable magic sysrq: 

# echo 0 > /proc/sys/kernel/sysrq

then you'll get use of ctrl-o back again.

Retrieved from "https://tools.bitfolk.com/w/index.php?title=Renumbering_for_customers&oldid=424"