[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <trinity-4af44d6e-0702-41de-880a-95b7181570dd-1631956430822@3c-app-gmx-bap22>
Date: Sat, 18 Sep 2021 11:13:50 +0200
From: Michael Hubmann <michael.hubmann@....net>
To: netdev@...r.kernel.org
Subject: Adaption request: IP-VRF(8)
Hi,
checking through the man page for the ip vrf command I have detected a wording issue which should be adapted in my humble opinion.
I am referring to the word 'enslaving' used in the following extract from the mentioned man page:
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
DESCRIPTION
A VRF provides traffic isolation at layer 3 for routing, similar to how a VLAN is used to isolate traffic at layer 2. Fundamentally, a VRF is a separate routing table. Network devices are associated with a VRF by enslaving the device to the VRF. At that point network addresses assigned to the device are local to the VRF with host and connected routes moved to the table associated with the VRF.
A process can specify a VRF using several APIs -- binding the socket to the VRF device using SO_BINDTODEVICE, setting the VRF association using IP_UNICAST_IF or IPV6_UNICAST_IF, or specifying the VRF for a specific message
using IP_PKTINFO or IPV6_PKTINFO.
By default a process is not bound to any VRF. An association can be set explicitly by making the program use one of the APIs mentioned above or implicitly using a helper to set SO_BINDTODEVICE for all IPv4 and IPv6 sockets
(AF_INET and AF_INET6) when the socket is created. This ip-vrf command is a helper to run a command against a specific VRF with the VRF association inherited parent to child.
ip vrf show [ NAME ] - Show all configured VRF
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Thanks in advance for taking the time for having a look on that.
kr
Michael Hubmann
Powered by blists - more mailing lists