netdev - [PATCH net-next 2/3] Provide man section for IPVLAN and IPVTAP Type Support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251120181248.3834304-3-skorodumov.dmitry@huawei.com>
Date: Thu, 20 Nov 2025 21:12:47 +0300
From: Dmitry Skorodumov <skorodumov.dmitry@...wei.com>
To: <netdev@...r.kernel.org>
CC: <stephen@...workplumber.org>, Dmitry Skorodumov
	<skorodumov.dmitry@...wei.com>
Subject: [PATCH net-next 2/3] Provide man section for IPVLAN and IPVTAP Type Support

A small section about ipvlan/ipvtap link types.
Most of the phrases are taken from Documentation/networking/ipvlan.rst

Signed-off-by: Dmitry Skorodumov <skorodumov.dmitry@...wei.com>
---
 man/man8/ip-link.8.in | 56 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
index ef45fe08..def83184 100644
--- a/man/man8/ip-link.8.in
+++ b/man/man8/ip-link.8.in
@@ -1652,6 +1652,62 @@ a multicast address will be queued as broadcast if the number of devices
 using it is greater than the given value.
 .in -8
 
+.TP
+IPVLAN and IPVTAP Type Support
+For a link of type
+.I IPVLAN
+or
+.I IPVTAP
+the following additional arguments are supported:
+
+.BI "ip link add link " MASTER " name " SLAVE
+.BR type " { " ipvlan " | " ipvtap " } "
+.RB " [ " mode " { " l3 " | " l3s " | " l2 " } ] "
+.RB " [ { " bridge " | " private " | " vepa " } ] "
+
+.in +8
+.sp
+.BR type " { " ipvlan " | " ipvtap " } "
+- specifies the link type to use.
+.BR ipvlan " creates just a virtual interface, while "
+.BR ipvtap " in addition creates a character device "
+.BR /dev/tapX " to be used just like a " tuntap " device."
+
+.B mode l3
+- Default mode. Layer 3 mode: Packets are routed by the host network stack. Slaves do
+not receive multicast or broadcast traffic. Provides stronger isolation
+between slaves.
+
+.B mode l3s
+- Very similar to the
+.BR l3
+mode except that iptables (conn-tracking) works in this mode
+and hence it is L3-symmetric (L3s).
+
+.B mode l2
+- In this mode TX processing happens on the stack instance attached to the
+slave device and packets are switched and queued to the master device to send
+out. In this mode the slaves will RX/TX multicast and broadcast (if applicable)
+as well.
+
+.B bridge
+- Default option. All endpoints are directly connected to each other,
+communication is not redirected through the physical interface's peer.
+
+.B private
+- Do not allow communication between
+instances on the same physical interface, even if the external switch supports
+hairpin mode.
+
+.B vepa
+- Virtual Ethernet Port Aggregator option. Data from one
+instance to the other on the same physical interface is transmitted over the
+physical interface. Either the attached switch needs to support hairpin mode,
+or there must be a TCP/IP router forwarding the packets in order to allow
+communication.
+
+.in -8
+
 .TP
 High-availability Seamless Redundancy (HSR) Support
 For a link of type
-- 
2.25.1