It’s been a bit quiet around my vSphere pure IPv6 lab setup lately. At first it seemed to be surprisingly easy, but the devil’s in the details…
As already posted, the initial setup went without any problems. The setup required IPv4 just for the kickstart process, or to be more exact for the first boot and installation phase. During the final configuration script the DHCP IPv4 address was dropped and the ESXi hosts were running IPv6 only: Continue reading
The last post was about a simple DNS server installation using Debian / Raspbian and bind. I already mentioned that this approach has the advantage of greater flexibility and more features than the DNS functionality that may come with your NAS or router. Particularly regarding IPv6, and that is what we are going to add to the DNS server now. Continue reading
If you’re using a Linux system to provide IPv6 services, you may notice that some services don’t bind to a specific IPv6 address during system boot. Usually the symptom will be messages in the syslog where the daemons state “bind to port [#] on [IPv6 address] failed: Cannot assign requested address“, and that a simple restart of the service after booting has finished solves the problem.
In my case the issue occured with sshd and sometimes iscsi_trgt on the Debian Wheezy NAS system, which is also the DNS, DHCP, NTP, Kickstart etc server in my lab environment.
The reason is that the IPv6 addresses are not instantly up and usable once the interface is configured. One of the numerous new features of IPv6 are extended states and scopes of interfaces and addresses. Even static global IPv6 addresses go through a “tentative” phase, in which the uniqueness of the address is verified by the host, see RFC 4862. During this phase, which can take some seconds, the address is not finally assigned to an interface and therefore not usable. Daemons trying to bind to that address will fail with the mentioned error message. Continue reading
The lab is (slowly, I have to admit) turning into an IPv6 only configuration.The first question might be “why would somebody want to do that?” Well, because it’s interesting and the main reason to have a lab anyway. But besides that I think every company should do something like this right now, to test their services and hardware (!) for IPv6 readiness. Now.
The basic setup in my lab is working fine, which means the firewall configuration is done and the local DNS is set up. For a start I’ll be using static IPv6 addresses and keep Router Advertisements and DHCPv6 for later. The NAS box (Debian 7.2) is configured with four interfaces for storage, two in VLAN 24 for iSCSI and two in a LACP setup in VLAN 25 for NFS, everything in a dual stack setup. The Kickstart configuration and scripts are modified as well, although I suppose the PXE boot itself will have to stay with IPv4, there’s no support for IPv6 in the firmware. Continue reading
Just to keep you updated (no, this blog is not a straw fire!):
A colleague & I have meanwhile set up an IPv6 test lab on the same hardware I use in my home lab. And this means a complete setup: DHCPv6, RA, static IPv6, tunnels, firewalling, broad range of client OS – the whole nine yards.
It’s going to take some time to write a series of blog posts describing the setup, and I’m still tempted to use IPv6 for the vSphere infrastructure as well. Maybe even for iSCSI, although it’s no longer officially supported…
So stay tuned, there’s a lot of stuff coming soon! Just have to finish the setup, writing – and my holidays. 🙂