Note: This is possible, but not the intended use. Enjoy it as a fun experiment.
On Sakura Cloud, it is not possible to connect using a bridge.
Can I assign a fixed MAC address or change it to an arbitrary one?
It is presumed that packets with MAC addresses other than those of the created VM cannot leave the VM on Sakura Cloud’s switch.
Creating a bridge within a VM to connect LXD containers directly to the router + switch IP address or the switch’s local IP address for communication is not possible.
Typically, the configuration would look like this:
However, since only packets with the MAC address attached to eth0 can communicate outside the VM, this configuration cannot connect to the internet.
Communication using the MAC address attached to veth0 of Container 1 cannot leave the VM.
This led me to wonder about the handling of virtual MAC addresses in VRRP.
Are there any restrictions on using a Virtual IP address (VIP) with VRRP?
VRID 1 to 4 are available.
Only the following four types of virtual MAC addresses can be used:
00:00:5e:00:01:01
00:00:5e:00:01:02
00:00:5e:00:01:03
00:00:5e:00:01:04
So, could it be possible to communicate from the VM using these MAC addresses? Let’s try!
network:
ethernets:
eth0:
dhcp4: 'no'
dhcp6: 'no'
bridges:
br0:
interfaces: [ eth0 ]
macaddress: <MAC address of eth0>
addresses:
- XXX.XXX.XXX.5/29
dhcp4: 'no'
dhcp6: 'no'
gateway4: XXX.XXX.XXX.1
First, create br0.
Then, create a container connected to br0.
In the default profile of lxd, set it to connect to br0.
devices:
eth0:
nictype: bridged
parent: br0
type: nic
Set up the network normally in the container.
# lxc launch images:ubuntu/22.04 c1
# lxc exec c1 bash
root@c1:~# cat << _EOF_ > /etc/netplan/10-lxc.yaml
network:
ethernets:
eth0:
dhcp4: 'no'
dhcp6: 'no'
addresses:
- XXX.XXX.XXX.8/29
gateway4: XXX.XXX.XXX.1
nameservers:
addresses:
- 133.242.0.3
- 133.242.0.4
renderer: networkd
version: 2
root@c1:~# netplan apply
It doesn’t connect normally.
root@c1:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 133.242.60.197 icmp_seq=1 Destination Host Unreachable
From 133.242.60.197 icmp_seq=2 Destination Host Unreachable
From 133.242.60.197 icmp_seq=3 Destination Host Unreachable
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4088ms pipe 4
Let’s set a VRRP virtual MAC address.
network:
ethernets:
eth0:
dhcp4: 'no'
dhcp6: 'no'
addresses:
- XXX.XXX.XXX.8/29
macaddress: 00:00:5e:00:01:01
gateway4: XXX.XXX.XXX.1
nameservers:
addresses:
- 133.242.0.3
- 133.242.0.4
renderer: networkd
version: 2
root@c1:~# netplan apply
Successfully connected to the outside!
root@c1:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=18.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=18.2 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=18.3 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 18.120/18.195/18.267/0.060 ms
Since up to four can be used, it seems possible to assign IP addresses directly using the bridge for communication with up to four containers within a single L2 network.
However, as this is not the intended use, it’s best to enjoy it as an interesting experiment.