[SOLVED] Adding the main network interface to a bridge on GCP

x-yuri · 2024-04-08 12:58:36

In the wiki there's a description of how to add the main network interface to a bridge. I'm trying it on a GCE VM running Debian 12, but after the last command the connection hangs and I can't connect anymore:

$ ip address show ens4
2: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc mq state UP group default qlen 1000
    link/ether 42:01:0a:00:00:21 brd ff:ff:ff:ff:ff:ff
    altname enp0s4
    inet 10.0.0.33/32 metric 100 scope global dynamic ens4
       valid_lft 3527sec preferred_lft 3527sec
    inet6 fe80::4001:aff:fe00:21/64 scope link
       valid_lft forever preferred_lft forever
$ ip route show dev ens4
default via 10.0.0.1 proto dhcp src 10.0.0.33 metric 100
10.0.0.1 proto dhcp scope link src 10.0.0.33 metric 100
169.254.169.254 via 10.0.0.1 proto dhcp src 10.0.0.33 metric 100
# ip link add name br0 type bridge
# ip link set dev br0 up
# ip address add 10.0.0.33/20 dev br0
# ip route append default via 10.0.0.1 dev br0

It's strange that `ip a` says "10.0.0.33/32" because the netmask should be /20. If I do `ip address add 10.0.0.33/32 dev br0` then the next (last) command fails with:

> Error: Nexthop has invalid gateway.

Any ideas what I might be doing wrong?

Last edited by x-yuri (2024-04-16 06:11:55)

Lone_Wolf · 2024-04-09 11:29:53

GCE = Google Compute Engine ?

No idea how they setup the network interface for the VM, but your route table looks weird.

Please post the output of route so we can see how the kernel represents it.

x-yuri · 2024-04-09 14:12:09

Thanks for the reply. You're right about GCE. I'm doing this in a VM on Google Cloud Platform. The details can be found here (this is a new VM, as such the IP is 10.0.0.30, not 10.0.0.33). It appears I can do this and not lose the connection by using serial console/ports. What I think is strange:

* `ip a` says 10.0.0.30/32 although the subnetwork should be /20
* 10.0.0.1 supposedly in place of a 10.0.0.0/20 route

That is, it looks like no more machines in the subnetwork are expected. At least that's the only interpretation I can think of. And what exactly do you think is strange? What can I check or do to further investigate or resolve this?

The initial `route` output can be found in the gist (the first link), but also here:

root@test-vpn:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    100    0        0 ens4
_gateway        0.0.0.0         255.255.255.255 UH    100    0        0 ens4
169.254.169.254 _gateway        255.255.255.255 UGH   100    0        0 ens4

Last edited by x-yuri (2024-04-10 00:18:03)

Lone_Wolf · 2024-04-10 11:52:16

169.254.x.y is a link-local address which often means a system is not connected to the outside world.

The ip route output in #1 lists no networks only a dedicated connection to 10.0.0.1 .
The route output fromthe kernel clarifies you indeed are not connected to other networks directly and everything needs to go through the _gateway .

This kind of setup does occur in environments where outside access is needed but should be monitored/restricted/censored/tracked (sometimes all of them).

The _gateway puzzled me but https://unix.stackexchange.com/question … stead-of-g helped to pinpoint the cause to systemd-resolved .

When bridging you have to work with what is already present.

The wiki section you followed is intended for a network connection that's managed by iproute2 but your network connection is not managed that way.
systemd-resolved is often used together with systemd-network , but can also function with NetworkManager .

The gist you posted shows systemd-networkd is handling the network in the debian 12 guest.
Follow https://wiki.archlinux.org/title/System … _interface to create the bridge (read the whole page, you may need to follow other parts of it to get things working)

x-yuri · 2024-04-14 13:07:19

To be frank, I was sceptical about this, but suddenly after one of my attempts it worked. Or so it seems at this stage (you can check out the case #3 and #4 logs). The trick was to use the main network interface's MACAddress for the bridge.

The things I'm not sure about though:

1. Is it okay if the bridge and the main network interface have the same MACAddress? Or should I change the latter?

2. Should I copy the main network interface settings?

There's /run/systemd/network/10-netplan-all-en.network on the host which reads:

[Match]
Name=en*

[Network]
DHCP=yes
LinkLocalAddressing=ipv6

[DHCP]
RouteMetric=100
UseMTU=true
UseDomains=true

(There's also /run/systemd/network/10-netplan-all-eth.network, but there are no eth* interfaces on the host, as such it can apparently be ignored.)

One way (case #3) is to do just as the wiki says:

/etc/systemd/network/25-br0.network:

[Match]
Name=br0

[Network]
DHCP=yes

Another way (case #4) is to copy the settings from the main network interface:

/etc/systemd/network/25-br0.network:

[Match]
Name=br0

[Network]
DHCP=yes 
LinkLocalAddressing=ipv6

[DHCP]
RouteMetric=100
UseMTU=true
UseDomains=true

Intuitively copying the main network interface settings sounds better, but I'm not sure.

Anything else I'm missing here?

169.254.169.254 acts as a metadata server (is used to obtain access tokens to access the API, and holds some additional data), a DNS server and maybe more.

Last edited by x-yuri (2024-04-14 13:11:34)

Lone_Wolf · 2024-04-16 10:29:04

1. Is it okay if the bridge and the main network interface have the same MACAddress? Or should I change the latter?

That depends entirely on hot the external network is configured . filtering based on mac address is rather common, so keeping uit the same is often best choice.

Copying tends to have a better chance of working with the external network.
One thing the logs show is that you may have conflicting tooling, as both dhclient and systemd-netword are running.

dhclient aborts, but you should check why/how it is started.

Arch Linux

#1 2024-04-08 12:58:36

[SOLVED] Adding the main network interface to a bridge on GCP

#2 2024-04-09 11:29:53

Re: [SOLVED] Adding the main network interface to a bridge on GCP

#3 2024-04-09 14:12:09

Re: [SOLVED] Adding the main network interface to a bridge on GCP

#4 2024-04-10 11:52:16

Re: [SOLVED] Adding the main network interface to a bridge on GCP

#5 2024-04-14 13:07:19

Re: [SOLVED] Adding the main network interface to a bridge on GCP

#6 2024-04-16 10:29:04

Re: [SOLVED] Adding the main network interface to a bridge on GCP

Board footer