SOWN IPv4 Migration

From SOWNWiki
Jump to: navigation, search

For some time SOWN has been on 10.13.0.0/16 and although we have our own VLAN so it is not specifically a problem that we share this address space with other hosts at the University of Southampton, it is not ideal. iSolutions has suggested we could move to 10.5.0.0/16 and therefore we need to consider what and where we need to make changes to facilitate this without things dropping of the network in a terminal way.

Tasks

  • Ideally get all node tunnels moved onto 169.254.0.0/16 addresses so they are resilient to the change from 10.13.0.0/16 to 10.5.0.0/16 change.
  • Add virtual interfaces for all equivalent 10.5.0.0/16 on all servers, so we can gradually migrate.
    • [CM 2017-12-29] Added on Auth2, Monitor, Gateway.
  • Update all routing configuration to use 10.5.0.0/16 instead. In particular Quagga and /etc/network/interfaces configurations. 10.5.0.0/16 routes will be advertised using BGP whereas 10.13.0.0/16 addresses will continue to use RIP until they are removed.
    • [CM 2017-12-29] BGPD enabled on Monitor, Auth and Gateway
    • [CM 2017-12-29] BGP configured to send routes from Gateway, Auth2 and VPN to Monitor
  • Once 10.5.0.0/16 addresses are working on Sown-gw and Sown-auth2 (DNS servers) and all other SOWN servers can route to them. Update resolv.conf configurations on all servers to use the DNS servers' new IPv4 addresses.
  • Update DNS zone files on sown-auth2 to use 10.5.0.0/16 addresses.
    1. Update config file for admin site from 10.13.0.0/16 subnet to 10.5.0.0/16 subnet.
    2. Update IPv4 addresses of SOWN servers through the admin site.
    3. Update updatednszones script on Sown-auth2 where appropriate to refer to 10.5.0.0/16.
    4. Update BIND on sown-auth2 configuration files to use 10.5.0.0/16 where appropriate.
    5. Run updatednszones script.
    6. Run updateicingaconf script on Sown-monitor.
  • Update VM templates on Sown-vms to use 10.5.0.0/16 addresses/subnet.

Allocation Plan

As we are migrating IPv4 address space it is worth reallocating the IPv6 address now we wil have a whole /56 routed to SOWN. Below is the prospective allocation plan:

Servers Subnet

IPv4 
10.5.0.0/24 - This is a direct transfer from 10.13.0.0/24. Although that may require modifying the subnet on some servers as we reduced it to a 10.13.0.192/26.
IPv6 
2001:630:d0:f700::/64 - This is completelty unchanged.

Production Node VPN Tunnels

IPv4 
10.5.128.0/24 - This allows for 64 production node VPN tunnels using /30s. This will require renumbering from the current 10.13.112.0/24 and 169.254.8.0/21 /30s.
IPv6 
2001:630:d0:f740::/58 - This allows for 64 production node VPN tunnels using /64s. This in the minimum size subnet allowed by OpenVPN that is big enough. If a node host has native IPv6 it is preferable to use this over one of these subnets to save having to route general Internet traffic via SOWN. Although different /64s are currently allocated to production nodes, these are not actually deployed.

Development Node VPN Tunnels

IPv4 
10.5.130.0/24 - This allows for 64 development node VPN tunnels using /30s. This will require renumbering from the current 10.13.112.0/24 and 169.254.8.0/21 /30s. Previously there were not different subnets used for production and devlopment node VPN tunnel subnets.
IPv6 
2001:630:d0:f7c0::/58 - This allows for 64 development node VPN tunnels using /64s. This in the minimum size subnet allowed by OpenVPN that is big enough. Although different /64s are currently allocated to production nodes, these are not actually deployed.

Production Node Wi-Fi Pools

IPv4 
10.5.192.0/18 - This allows for 64 production node Wi-Fi pools using /24s. These new subnets will larger than some of the subnets currently used, as we reduced subnets to /27s to save space. Therefore some careful translation will be required.
IPv6 
2001:630:d0:f780::/58 - This allows for 64 production node Wi-Fi pools using /64s. Although different /64s are currently allocated to production nodes, these are not actually deployed.

Development Node Wi-Fi Pools

IPv4 
There is no plan to reserve IPv4 subnets to allocate to development nodes Wi-Fi pools. If they are needed then they can be allocated on a case by case basis from the 10.5.0.0/17 subnet (excluding 10.5.0.0/24).
IPv6 
There is no plan to reserve IPv4 subnets to allocate to development nodes Wi-Fi pools. If they are needed then they can be allocated on a case by case basis from the 2001:630:d0:f700::/58 subnet (excluding 2001:630:d0:f700::/64).

Unallocated Subnets

IPv4 
10.5.0.0/24 - 10.5.127.0/24 - These could be used for allocating Wi-Fi pool subnets either for development nodes or additional pools for production nodes. Alternatively, they may be used for other network experimetation.
IPv6 
2001:630:d0:f701::/64 - 2001:630:d0:f73ff::/64 - These could be used for allocating Wi-Fi pool subnets either for development nodes or additional pools for production nodes. Alternatively, they may be used for other network experimetation.


Retrieved from ‘https://www.sown.org.uk/w/index.php?title=SOWN_IPv4_Migration&oldid=12863’
... more about "SOWN IPv4 Migration"
RDF feed
Has contributor
User:DavidNewman +, User:Cmalton +  and User:Heliosfa +