LXD

Networking

notes from Network management with LXD (2.3+)

create a new network with a random IPv4 and IPv6 subnet and NAT enabled:

$ lxc network create testbr0

look at its config with:

$ lxc network show testbr0

to manual configure subnets:

$ lxc network create testbr0 ipv6.address=none ipv4.address=10.0.3.1/24 ipv4.nat=true

attach to all containers:

$ lxc network attach-profile testbr0 default eth0

attach to a single existing container:

$ lxc network attach my-container default eth0

convert bridge to an openvswitch bridge (need openvswitch installed first):

$ lxc network set testbr0 bridge.driver openvswitch

edit the network configuration interactively in your text editor:

$ lxc network edit

LXD manages the DHCP server for you.

a full example:

$ lxc init ubuntu:16.04 c1
$ lxc network attach testbr0 c1 eth0
$ lxc config device set c1 eth0 ipv4.address 10.0.3.123
$ lxc start c1
$ lxc list c1

DNS

LXD runs a DNS server on the bridge.

On top of letting you set the DNS domain for the bridge (dns.domain network property),

it also supports 3 different operating modes (dns.mode):

managed will have one DNS record per container, matching its name and known IP addresses. The container cannot alter this record through DHCP.
dynamic allows the containers to self-register in the DNS through DHCP. So whatever hostname the container sends during the DHCP negotiation ends up in DNS.
none is for a simple recursive DNS server without any kind of local DNS records.

The default mode is managed and is typically the safest and most convenient as it provides DNS records for containers but doesn’t let them spoof each other’s records by sending fake hostnames over DHCP.

Using tunnels

LXD also supports connecting to other hosts using GRE or VXLAN tunnels.

A LXD network can have any number of tunnels attached to it.

production environment usually preferring VLANs for that kind of segmentation.

example of connecting two hosts using VXLAN tunnel:

lion $ lxc network create testbr0 tunnel.lan.protocol=vxlan

lion $ lxc network attach-profile testbr0 default eth0

lion will be the one acting as a router for that network, providing DHCP, DNS, … the other hosts will just be forwarding traffic over the tunnel.

tiger $ lxc network create testbr0 ipv4.address=none ipv6.address=none tunnel.lan.protocol=vxlan

tiger $ lxc network attach-profile testbr0 default eth0

Now you can start containers on either host and see them getting IP from the same address pool and communicate directly with each other through the tunnel.

this uses multicast, which usually won’t do you much good when crossing routers. For those cases, you can use VXLAN in unicast mode or a good old GRE tunnel.

To join another host using GRE:

lion $ lxc network set testbr0 tunnel.tiger.protocol gre

lion $ lxc network set testbr0 tunnel.tiger.local 172.17.16.2

lion $ lxc network set testbr0 tunnel.tiger.remote 172.17.16.9

on "client* host:

tiger $ lxc network create testbr0 ipv4.address=none ipv6.address=none tunnel.lion.protocol=gre tunnel.lion.local=172.17.16.9 tunnel.lion.remote=172.17.16.2

tiger $ lxc network attach-profile testbr0 default eth0

to use vxlan:

lion $ lxc network set testbr0 tunnel.lion.id 10
lion $ lxc network set testbr0 tunnel.lion.protocol vxlan

and:

tiger $ lxc network set testbr0 tunnel.lion.id 10
tiger $ lxc network set testbr0 tunnel.lion.protocol vxlan

The tunnel id is required here to avoid conflicting with the already configured multicast vxlan tunnel.