tickets #160221
openRefactor Nuremberg/IPX networking
0%
Description
We have two hypervisors in Nuremberg:
- slimhat
- stonehat
The network setup is dual stack with some routing through the hypervisor and some bridged connectivity. Some of the virtual machines have a second network interface with public IP addresses. Site to site connectivity currently happens through a mix of OpenVPN and WireGuard tunnels, some on the hypervisors, some inside the VMs.
The setup should be adjusted to align with the standard we already implement in Prague. This means:
- isolated hypervisor network
- preference for IPv6 (single stack for hosts which only provide internal services)
- site to site connectivity through WireGuard + dynamic routing through OSPF
- fully managed by Salt
We do not have the benefit of a separate machine to act as a router/firewall there. Hence we can either install gateway VM's on the hypervisors or use the hypervisor hosts themselves as gateways (as is already partially done on stonehat). I prefer the VMs as it allows for better isolation with the hypervisors, however care must be taken to not loose connectivity to the hypervisor if the virtualization stack is down.
I could not get information from someone with access to the hosting panel, and the IP configuration on the machines seems incomplete, but with some reverse engineering I found we have the following address space graciously provided by IPX:
- 2a01:138:a004::/48 (routed to both slimhat and stonehat?)
- 62.146.92.200/29 (routed to slimhat?)
- 62.146.92.208/29 (routed to stonehat?)
We could split the IPv6 space into two /49 prefixes, one for each hypervisor + guests, and then implement /64 VLANs.
Updated by crameleon 4 months ago
For a test about my prefix discovery, I transiently added 2a01:138:a004:8000:100::1/49
to br0 on slimhat and watched tcpdump - no packets came in. Traceroute from the internet shows it stopping at the IPX router, suggesting it's routed to a different place (or nowhere, which would be surprising, given it's allocated).
Means we do still need to properly confirm which prefix(es) are routed to us at IPX.