0

I’m working on a Raspberry Pi-based network device that moves between several known locations, each with its own IPv4 and IPv6 subnet. To streamline connectivity, I’m considering assigning multiple static IP addresses (both IPv4 and IPv6) to the eth0 interface, so that it can communicate without reconfiguration at each site. My current setup:

  • Using dhcpcd with a custom exit-hook to programmatically assign addresses based on the environment.

  • I plan to assign something like:

    # IPv4 ip addr add 192.168.1.100/24 dev eth0 ip addr add 10.11.12.13/24 dev eth0 # IPv6 ip -6 addr add 2405:200:185:2666::4c82/64 dev eth0 ip -6 addr add 2406:300:abcd:7890::5/64 dev eth0

  • The Pi will not be connected to more than one network at a time, but I want the addresses preconfigured for seamless usage.

Concerns I have:

  • Potential routing conflicts, especially if multiple addresses try to inject default routes.
  • How Linux chooses the source IP for outbound packets when multiple global IPs exist on one interface.
  • Whether this could interfere with RA handling or DHCPv6 behavior.
  • If it’s better to use policy routing or interface metrics to manage this cleanly.

Questions:

  1. Is this approach viable and stable for production usage?
  2. What are the best practices for ensuring predictable routing and IP selection in this setup?
  3. Would policy routing (e.g., using ip rule + custom tables) be required to maintain clean behaviour?
  4. Should I be flushing routes on each network change to avoid stale or conflicting entries?

Additional context:

  • Temporary commands are acceptable since configuration is injected by dhcpcd exit hooks.
  • I don’t want to rely on dynamic DHCP or RA configuration at each site.
Improve this question
3
  • 1
    If you can pick some random IP on each network to assign statically without worrying about conflicts, presumably you have some control of these networks as well? Then why not just configure the DHCP servers on these networks to assign those IPs instead? I don't understand what problem you're trying to solve here by doing this. Commented May 13 at 4:38
  • I want the Raspberry Pi to come up and be reachable with the same set of known IPs, without relying on external services like DHCP or RA. Commented May 13 at 4:56
  • Do these networks have DHCP servers? If so, do you know what addresses ranges they use? If you don't know that, you cannot reliably configure some random IP for use with your device. Commented May 13 at 5:06

1 Answer 1

Reset to default
2

Potential routing conflicts, especially if multiple addresses try to inject default routes.

Addresses don't inject default routes. (They only inject "local subnet" routes.)

Default routes come from the same mechanisms that provide you with your address. So if you're going to use DHCP or IPv6 RA to obtain a default route, then there is no point in your plan, because the network will also provide you with an address appropriate for that network, therefore there is no need to pre-add all possible addresses.

If you are using static configuration only, then unless you manually add a default route, there won't be a default route at all. Similarly:

Should I be flushing routes on each network change to avoid stale or conflicting entries?

Without DHCP or RA, this question does not make sense because the set of routes will be static as well – there won't be any new entries added dynamically, so there won't be any entries that can go stale, either.

With DHCP, it is the DHCP client's job to automatically remove all routes it has added.

How Linux chooses the source IP for outbound packets when multiple global IPs exist on one interface.

"Longest common prefix" is the main rule in IPv6. I think it also applies to IPv4. For example, accessing 192.0.1.2 would choose 192.168.1.100 – even if you're actually on the 10.11.22 network right now – because it shares a common prefix of 192/8 with the destination, while the common prefix for the other address would be 0 bits.

You can influence this by setting a "preferred source" attribute (RTA_PREFSRC) on your routes, using the src keyword in ip route add.

Beyond that, the OS is not aware that some addresses should be ignored because they're invalid for the current network; after all, you've assigned them to an interface, so you declared them valid.

I want the Raspberry Pi to come up and be reachable with the same set of known IPs

It won't be reachable with the same set of known IPs, because the networks will not route all those IPs towards the Raspberry Pi.

For example, if you are currently 192.168.1.100/24, then your adjacent hosts will also generally be 192.168.1.x/24. They will have a "local subnet" route for 192.168.1.0/24, allowing them to reach 192.168.1.100.

But those hosts are only 192.168.1.x/24 and not 10.11.12.0/24 – so they will not be aware of 10.11.12.13 being local, and any attempts to contact 10.11.12.13 will get routed through those hosts' "default gateway" (the subnet router). That subnet router likewise is unaware of the Pi being here and will forward the packets somewhere further away from the network the Pi is in.

For the Pi to become reachable using its alternate address you'd need to manually configure all those hosts (or the subnet router) to have 10.11.12.0/24 as an additional local subnet route. Might as well configure them to resolve the Pi's hostname via mDNS instead.

If you're in the 10.11.12.0/24 network, you will have the opposite situation with none of the local network equipment being aware that 192.168.1.100 is a locally reachable address. The same goes for IPv6, which follows the same model as far as local subnets are concerned.

The only way this could possibly work is if all sites spoke RIP or OSPF or Babel or similar, with the Pi also acting as an OSPF neighbor and advertising a route that way. (Unlikely to happen in regular LANs – it's "a bit of a security risk" to allow random hosts to pull traffic for arbitrary addresses.)

Is this approach viable and stable for production usage?

No.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.