4

When I use separate network namespace, I often set up networking there using veth:

ip link add type veth
ip link set veth0 netns 1
ifconfig veth1 192.168.60.2
ip route add default via 192.168.60.1

This includes unnecessary random MAC addresses for this "virtual Ethernet".

For example in other mechanism (TUN/TAP) there are two modes: "tap" for Ethernet-like mode and "tun" for IP mode (i.e. without ARP, MAC address, neightbors, frame headers, promisc mode and other extra entities).

Maybe there is similar "other mode" for veth?

        |  connects          |  networking level
----------------------------------------
tap     |  IF to userspace   |  Ethernet
tun     |  IF to userspace   |  IP
veth    |  two IFs together  |  Ethernet
I want  |  two IFs together  |  IP
Vi.
  • 5,528
  • 7
  • 34
  • 68
  • 1
    Sorry @Vi, this sounds like a case of the [XY Problem](http://mywiki.wooledge.org/XyProblem). What are you actually trying to accomplish here? You can create a tun device with `ip tuntap add tun0 mode tun` – GnP Apr 10 '15 at 18:06
  • 2
    @gnp, `tun0` appeared. Where is the other end? It should be moved to other network namespace. – Vi. Apr 10 '15 at 19:44
  • Outer problem is setting up networking in a network namespace using custom program. MAC addresses were a problem, I worked it around by using "ff:ff:ff:ff:ff:ff". But it's even cleaner to get rid of random MAC addresses entirely. – Vi. Apr 10 '15 at 19:46
  • Still doesn´t makes sense why you need so much an interface with no Mac Address just to "look clean"... NAT will create excessive work, and an interface with other IP but same mac adress inside an aditional namespace is just madness!! –  Dec 23 '15 at 19:50
  • 5
    It is perfectly clear what he is asking. Linux has veth (both ends in the kernel, has ethernet stuff), tap (one end in the kernel, the other in userspace, has ethernet stuff), and tun (one end in the kernel, the other in userspace, no ethernet stuff). He is asking if the fourth possibility "both ends in the kernel, no ethernet stuff" exits. – plugwash Dec 02 '16 at 03:45
  • 1
    Probably thereis no such module yet, but when it appear in future I want to get notified by having an answer here. – Vi. Dec 02 '16 at 18:36
  • Looks like Virtuozo/OpenVZ has `venet` interfaces for that but vanilla Linux has no requivalent. – Stéphane Chazelas Dec 02 '16 at 19:16
  • I upvoted this a year and a half ago when it was new because I want this too and now I see there is activity again so I want to put in my 2¢ :) One of the reasons to want this is to do away with layer 2 rubbish for locating neighbours and addressing packets on a multiaccess network when the network in question is known *a priori* to be fundamentally and inherently point to point. You don't need ARP in this situation: you *know* whom you're sending the packet to — there can be only one™. I thought maybe it was possible that the kernel optimizes ARP away because of this, but alas it does not. – Celada Dec 03 '16 at 05:14
  • Does [br_select.c](http://tun.sourcearchive.com/documentation/1.1/br__select_8c-source.html) with two *tun* interfaces count? There's no "unnecessary" MAC address, but it goes through userspace, and is therefore probably less efficient than *veth*. – dirkt Dec 03 '16 at 07:15
  • 1
    There's also [ipvlan](https://www.kernel.org/doc/Documentation/networking/ipvlan.txt), where the slave devices share the MAC address with the master device, and packets are processed at L3. But you need an independent master device, which has a MAC, and the master device still does any L2 processing. – dirkt Dec 03 '16 at 07:24
  • @dirkt, br_select is a workaround. – Vi. Dec 03 '16 at 15:54

0 Answers0