3

Is there a way I can move a secondary IP into its own namespace while keeping the primary IP on the original device?

If I have 10.0.0.1 and 10.0.0.2 on device eth0, but I want 10.0.0.2 to be in its own netns test, the closest I've come to that involves adding a veth pair and a bridge, and moving the eth0 primary IP to the bridge:

  netns: test              netns: default
==============     ===============================
vethB:10.0.0.2 <-> vethA <-> br0:10.0.0.1 <-> eth0

Unfortunately moving the 10.0.0.1 IP off of eth0 will confuse a few opaque legacy applications on the box, so I'd prefer to keep that on eth0.

pilcrow
  • 449
  • 5
  • 19

2 Answers2

4

The Linux macvlan device is a workable solution here.

It instantiates a layer 2 subinterface which is a bona fide logical device, unlike the eth0:1 administrative fiction to manage secondary IPs, which I may then move into a network namespace and address. Example:

#  netns: test        netns: default
# ==============     ================
# test0:10.0.0.2 <->  eth0:10.0.0.1

# Create "test" network namespace
ip netns add test
ip netns exec test ip link set lo up

# Create subinterface and move to "test"
ip link add link eth0 name test0 type macvlan
ip link set test0 netns test

# Configure the subinterface
ip netns exec test ip addr add 10.0.0.2/24 brd + dev test0

This preserves the "primary" IP on eth0 and thus keeps the existing system more-or-less unaware of my hidden "secondary" IP.

Addendum for wifi interfaces

User pts points out that macvlan devices won't work if eth0 is a wifi interface. Instead, use interface type ipvlan mode 12.

pilcrow
  • 449
  • 5
  • 19
  • 1
    This doesn't work (e.g. `ping 10.0.0.2` from another machine on the local network) if a wifi interface is used instead of eth0. To make it work, replace `type macvlan` with `type ipvlan mode l2`. More info here: https://unix.stackexchange.com/q/622914 – pts Dec 04 '20 at 15:35
  • To make it work with wiifi instead of Ethernet, replace *type macvlan* with *type ipvlan mode l2*. See details here: https://unix.stackexchange.com/questions/622914/create-additional-ip-address-in-a-separate-network-namespace/622934 – pts Dec 06 '20 at 11:01
1

A given device can only be in one namespace, see https://lwn.net/Articles/580893/ :

Aside from the loopback device, each network device (physical or virtual interfaces, bridges, etc.) can only be present in a single network namespace.

So your eth0 can only be in one. Your setup, with two virtual interfaces and a bridge is a solution to this problem. I do not understand what it changes for applications if the IP is tied to br0 instead of eth0, they should not see a difference. Otherwise you will need to provide more details. Did you really get problems, and if so, which ones, or do you just expect them?

If you can uses them, have a look at VLANs: you can put each of them (off the same physical interface) in different namespaces. This is detailed here: https://blog.scottlowe.org/2014/03/21/a-follow-up-on-linux-network-namespaces/

If you can not use a bridge or VLANs, you will need to setup some IP forwarding or NAT.

Patrick Mevzek
  • 9,273
  • 7
  • 29
  • 42
  • Thanks. Can you elaborate on the L3 forwarding or NAT'ing? 802.1q VLANs are infeasible as I don't control the wire/trunking, and my veth-pair-bridge approach, again, would be too intrusive. (I'm not pleased with that constraint, but so it is.) – pilcrow Mar 06 '18 at 18:00
  • Have a look at https://unix.stackexchange.com/a/393468/211833 Basically the default route of vethB should be pointing to eth0 IP. – Patrick Mevzek Mar 07 '18 at 22:19