1

I have learned how to add virtual NICs to a guest system in VirtualBox, just using Shared Adapter, then all the virtual NICs and my host's NIC will appear as real NICs to the ISP.

So I guess there must be a way to add those virtual NICs to my PC without resolving VBox. I tried with ip link add link enp0s3 type macvlan.

ip netns add ns
ip link add link enp0s3 type macvlan
ip link set netns ns macvlan0
ip netns exec ns ip link set up macvlan0
ip netns exec ns ip addr add 192.168.222.101/24 dev macvlan0
ip addr add 192.168.222.1/24 dev enp0s3
ping 192.168.222.101
PING 192.168.222.101 (192.168.222.101) 56(84) bytes of data.
^C
--- 192.168.222.101 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

I also tried ip link add link enp0s3 type macvlan mode bridge and ip link add link enp0s3 type macvtap [mode bridge], but it doesn't help.

1

The easiest solution is probably to use macvlans. Similar solutions are macvtap and ipvlan, which differ only minimally from the above; it is difficult to choose one rather than the other, without many more details. But the following will surely work.

For every network namespace, assign a macvlan interface as follows:

 NNS=TheNameOfYourNetworkNamespace
 ip netns add $NNS
 ip link add link eth0 mac$NNS address 56:61:4f:7c:77:db type macvlan mode bridge
 ip link set dev mac$NNS netns $NNS

I have used a specific MAC address, you may simply drop the part address 56:61:4f:7c:77:db if you are not interested in specifying it, thus leaving it to chance.

Now enter the network namespace and configure the network:

 ip netns exec $NNS xterm

and from within the open xterm, do:

 ip link set dev $NAME_OF_MAC_INTERFACE up
 ip link set dev lo up
 ip addr add 127.0.0.1 dev lo
 dhclient -v mac$NNS

and you are done.

One last comment: the option mode bridge used above allows all network namespaces to talk to each other directly, i.e. without passing thru a switch. However, whether you use such an option or not, your host will be unable to talk to the network namespaces, unless you build a macvlan for the host itself, in which case it will be able to communicate with the other NNSes as if it itself were one of them.

EDIT:

it does not work because I should have remembered that, once inside the NNS, environment variables like $NNS are not defined any longer, so that I should correct the line above. In fact, on my system,

 # ip addr show dev eth0
   2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether e8:e0:b7:be:72:6a brd ff:ff:ff:ff:ff:ff
   inet 192.168.73.55/24 brd 192.168.73.255 scope global eth0
   valid_lft forever preferred_lft forever
   inet6 fe80::eae0:b7ff:febe:726a/64 scope link 
   valid_lft forever preferred_lft forever
  # NNS=ns1
  # ip netns add $NNS
  # ip link add link eth0 mac$NNS address 56:61:4f:7c:77:db type macvlan 
  # ip link set dev mac$NNS netns $NNS
  # ip netns exec $NNS /bin/bash
  # ip link set dev macns1 up
  #  ip link set dev lo up
  #  ip addr add 127.0.0.1 dev lo
  # dhclient -v macns1
    Internet Systems Consortium DHCP Client 4.2.4
    Copyright 2004-2012 Internet Systems Consortium.
    All rights reserved.
    For info, please visit https://www.isc.org/software/dhcp/

    Listening on LPF/macns1/56:61:4f:7c:77:db
    Sending on   LPF/macns1/56:61:4f:7c:77:db
    Sending on   Socket/fallback
    DHCPDISCOVER on macns1 to 255.255.255.255 port 67 interval 3 (xid=0x473d2846)
    DHCPREQUEST of 192.168.73.48 on macns1 to 255.255.255.255 port 67 (xid=0x46283d47)
    DHCPOFFER of 192.168.73.48 from 192.168.73.1
    DHCPACK of 192.168.73.48 from 192.168.73.1
    bound to 192.168.73.48 -- renewal in 21288 seconds.
  # ping -c1 superuser.com
    PING superuser.com (104.16.127.192) 56(84) bytes of data.
    64 bytes from 104.16.127.192: icmp_seq=1 ttl=53 time=12.9 ms

    --- superuser.com ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 12.927/12.927/12.927/0.000 ms

As you can see, it works perfectly on my system. You can check that the IP address I get within the NNS (192.168.73.48) differs from that on the host, 192.168.73.55.

If it does not work on your system, I will need something more than just a it does not work, because I am unable to reproduce your error.

| improve this answer | |
  • I tried your answer, but I'm sorry to tell you it doesn't work. In fact, I tried arp -s in $NNS and it gives 192.168.42.129 (incomplete). The IP is my gateway. I tried in the default namespace it gives the right MAC. – TorosFanny Jan 11 '16 at 16:33
  • @TorosFanny Pls read my Edit. – MariusMatutiae Jan 11 '16 at 17:01
  • It's really strange. I have forgotten to tell you, I do nearly all of my experiments in VirtualBox. Once I gave the guest Ubuntu a bridged adapter, and then dhclient -v mac$NNS failed, and I tried to give the guest a NAT, and then dhclient -v mac$NNS success. With the NAT mode, I can also ping -c1 superuser.com, but can not still ping the NIC of guest os's default namespace. It's really strange, it can ping the outside world but not the NIC linked to it. I tried your answer with my real PC, it works fine. Maybe there's something wrong with shared adapter mode. Thank you. – TorosFanny Jan 11 '16 at 17:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.