Renumbering for customers: Difference between revisions

From BitFolk
Jump to navigation Jump to search
Line 267: Line 267:
* etc.
* etc.


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



Revision as of 21:02, 4 November 2011

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 will receive 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.

Monday 5th December 2011

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

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

Monday 6th 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.

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.x85.119.82.x
  • 212.13.195.x85.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

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:

# ip route change default via 85.119.80.1

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

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:

# ip route change default via 85.119.80.1

Now verify that your connectivity to your VPS still works.

Making the new configuration permanent

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.

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.

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 BitFok'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.

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.

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.