Avoid advertising default route for Bridge network

I have 2 network interfaces attached to an LXC container:

One is a macvlan interface that is connected to my upstream router and the internet. The container obtains a globally routed address through this interface.

The other is an Incus-managed Bridge interface, which uses an IPv6 ULA address. The address is advertised via BGP, but cannot be used to access the internet.

It looks like the router advertisements on this second Bridge network claim that the gateway is a default route.

# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host proto kernel_lo 
       valid_lft forever preferred_lft forever
26: eth0@if27: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 10:66:6a:71:a8:58 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fd42:7680:d14b:2c96:1266:6aff:fe71:a858/64 scope global mngtmpaddr noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::1266:6aff:fe71:a858/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
28: eth1@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 10:66:6a:2b:a6:d9 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 2001:db8::1266:6aff:fe2b:a6d9/64 scope global dynamic mngtmpaddr proto kernel_ra 
       valid_lft 86032sec preferred_lft 14032sec
    inet6 fe80::1266:6aff:fe2b:a6d9/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
# ip -6 route
2001:db8::/64 dev eth1 proto kernel metric 256 expires 86229sec pref medium
fd42:7680:d14b:2c96::/64 dev eth0 proto ra metric 1024 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
default via fe80::6662:66ff:fe2f:2d18 dev eth1 proto ra metric 1024 expires 1629sec hoplimit 64 pref medium
default nhid 130120035 via fe80::1266:6aff:fe17:d2bd dev eth0 proto ra metric 1024 expires 1687sec pref medium

IPv6 will alway prefer GUA than ULA when accessing internet.

This is only true once an interface is selected.
The routing table determines which outbound interface is chosen, and only then does the source-address selection algorithm come into play (which will choose GUA over ULA).

Because these are two different interfaces, it does matter (ends up being whichever interface was added last winning).

I also want to avoid issues where VMs without internet think the link is down when in reality it doesn’t have a valid route to begin with.

2001:db8::/64 has lower metric, so it’s preferred.

That’s true, but the metric, preference, etc. information is configured at my external router. I shouldn’t need to remember “Incus sets its internal Bridge network at 1024 metric, so I must keep my RA setting lower to avoid Network Unreachable issues”.

The metric and pref options are meant to be used for speed: if 2606:4700:4700::1111 isn’t reachable via eth0 then that address shouldn’t be in the routing table for eth0.

It’s reachable if the host can reach it. Because incus managed bridge’s nated:

In my case, the Bridge network has ipv6.nat: 'false', so the traffic can not be routed outside of the fd42:7680:d14b:2c96::/64 subnet my internal network.

Edit: to make this clear, this is my config:

project: default
name: containers-br
description: ''
type: bridge
config:
  ipv6.routing: 'true'
  ipv4.address: none
  ipv6.address: fd42:7680:d14b:2c96::1/64
  ipv6.nat: 'false'

I just read the doc, I don’t see a way to resolve you problem with incus, I think you need to manually edit routing table.

NAT-ed or not doesn’t matter. Incus doesn’t know what you’re doing on your network.

You could absolutely use a ULA subnet with NAT disabled within Incus, then have a NAT rule on your host or on the router outside of your host. We have no way to detect that nor should we be making assumptions.

I agree that Incus shouldn’t make any assumptions, but I’m surprised that this isn’t configurable on Incus’s side. IPv6 router advertisements support the advertising of a prefix for address autoconfiguration without having clients register the router as a default route, and separately supports adding specific routes. I believe this could be done with dnsmasq command line arguments.

This is a question that was caused by my inability to make the solution here work, so maybe I can skirt the issue by only using one interface.

You may be able to weak the exact behavior through raw.dnsmasq. The ra-param option seems to allow changing the priority and potentially even prevent setting it as a default router.

Thanks. For future reference, the configuration ra-param=*,0,0 tells dnsmasq to advertise the prefix, but to not advertise any routes, which works for my purposes.

# ip -6 r
2001:db8::/64 dev eth1 proto kernel metric 256 expires 86317sec pref medium
fd42:7680:d14b:2c96::/64 dev eth0 proto ra metric 1024 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::6662:66ff:fe2f:2d18 dev eth1 proto ra metric 1024 expires 1717sec hoplimit 64 pref medium