요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
=======================================
DSA switch configuration from userspace
=======================================
The DSA switch configuration is not integrated into the main userspace
network configuration suites by now and has to be performed manually.
.. _dsa-config-showcases:
Configuration showcases
-----------------------
To configure a DSA switch a couple of commands need to be executed. In this
documentation some common configuration scenarios are handled as showcases:
*single port*
Every switch port acts as a different configurable Ethernet port
*bridge*
Every switch port is part of one configurable Ethernet bridge
*gateway*
Every switch port except one upstream port is part of a configurable
Ethernet bridge.
The upstream port acts as different configurable Ethernet port.
All configurations are performed with tools from iproute2, which is available
at https://www.kernel.org/pub/linux/utils/net/iproute2/
Through DSA every port of a switch is handled like a normal linux Ethernet
interface. The CPU port is the switch port connected to an Ethernet MAC chip.
The corresponding linux Ethernet interface is called the conduit interface.
All other corresponding linux interfaces are called user interfaces.
The user interfaces depend on the conduit interface being up in order for them
to send or receive traffic. Prior to kernel v5.12, the state of the conduit
interface had to be managed explicitly by the user. Starting with kernel v5.12,
the behavior is as follows:
- when a DSA user interface is brought up, the conduit interface is
automatically brought up.
- when the conduit interface is brought down, all DSA user interfaces are
automatically brought down.
In this documentation the following Ethernet interfaces are used:
*eth0*
the conduit interface
*eth1*
another conduit interface
*lan1*
a user interface
*lan2*
another user interface
*lan3*
a third user interface
*wan*
A user interface dedicated for upstream traffic
Further Ethernet interfaces can be configured similar.
The configured IPs and networks are:
*single port*
* lan1: 192.0.2.1/30 (192.0.2.0 - 192.0.2.3)
* lan2: 192.0.2.5/30 (192.0.2.4 - 192.0.2.7)
* lan3: 192.0.2.9/30 (192.0.2.8 - 192.0.2.11)
*bridge*
* br0: 192.0.2.129/25 (192.0.2.128 - 192.0.2.255)
*gateway*
* br0: 192.0.2.129/25 (192.0.2.128 - 192.0.2.255)
* wan: 192.0.2.1/30 (192.0.2.0 - 192.0.2.3)
.. _dsa-tagged-configuration:
Configuration with tagging support
----------------------------------
The tagging based configuration is desired and supported by the majority of
DSA switches. These switches are capable to tag incoming and outgoing traffic
without using a VLAN based configuration.
*single port*
.. code-block:: sh
# configure each interface
ip addr add 192.0.2.1/30 dev lan1
ip addr add 192.0.2.5/30 dev lan2
ip addr add 192.0.2.9/30 dev lan3
# For kernels earlier than v5.12, the conduit interface needs to be
# brought up manually before the user ports.
ip link set eth0 up
# bring up the user interfaces
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
*bridge*
.. code-block:: sh
# For kernels earlier than v5.12, the conduit interface needs to be
# brought up manually before the user ports.
ip link set eth0 up
# bring up the user interfaces
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
# create bridge
ip link add name br0 type bridge
# add ports to bridge
ip link set dev lan1 master br0
ip link set dev lan2 master br0
ip link set dev lan3 master br0
# configure the bridge
ip addr add 192.0.2.129/25 dev br0
# bring up the bridge
ip link set dev br0 up
*gateway*
.. code-block:: sh
# For kernels earlier than v5.12, the conduit interface needs to be
# brought up manually before the user ports.
ip link set eth0 up
# bring up the user interfaces
ip link set wan up
ip link set lan1 up
ip link set lan2 up
# configure the upstream port
ip addr add 192.0.2.1/30 dev wan
# create bridge
ip link add name br0 type bridge
# add ports to bridge
ip link set dev lan1 master br0
ip link set dev lan2 master br0
# configure the bridge
ip addr add 192.0.2.129/25 dev br0
# bring up the bridge
ip link set dev br0 up
.. _dsa-vlan-configuration:
Configuration without tagging support
-------------------------------------
A minority of switches are not capable to use a taging protocol
(DSA_TAG_PROTO_NONE). These switches can be configured by a VLAN based
configuration.
*single port*
The configuration can only be set up via VLAN tagging and bridge setup.
.. code-block:: sh
# tag traffic on CPU port
ip link add link eth0 name eth0.1 type vlan id 1
ip link add link eth0 name eth0.2 type vlan id 2
ip link add link eth0 name eth0.3 type vlan id 3
# For kernels earlier than v5.12, the conduit interface needs to be
# brought up manually before the user ports.
ip link set eth0 up
ip link set eth0.1 up
ip link set eth0.2 up
ip link set eth0.3 up
# bring up the user interfaces
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
# create bridge
ip link add name br0 type bridge
# activate VLAN filtering
ip link set dev br0 type bridge vlan_filtering 1
# add ports to bridges
ip link set dev lan1 master br0
ip link set dev lan2 master br0
ip link set dev lan3 master br0
# tag traffic on ports
bridge vlan add dev lan1 vid 1 pvid untagged
bridge vlan add dev lan2 vid 2 pvid untagged
bridge vlan add dev lan3 vid 3 pvid untagged
# configure the VLANs
ip addr add 192.0.2.1/30 dev eth0.1
ip addr add 192.0.2.5/30 dev eth0.2
ip addr add 192.0.2.9/30 dev eth0.3
# bring up the bridge devices
ip link set br0 up
*bridge*
.. code-block:: sh
# tag traffic on CPU port
ip link add link eth0 name eth0.1 type vlan id 1
# For kernels earlier than v5.12, the conduit interface needs to be
# brought up manually before the user ports.
ip link set eth0 up
ip link set eth0.1 up
# bring up the user interfaces
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
# create bridge
ip link add name br0 type bridge
# activate VLAN filtering
ip link set dev br0 type bridge vlan_filtering 1
# add ports to bridge
ip link set dev lan1 master br0
ip link set dev lan2 master br0
ip link set dev lan3 master br0
ip link set eth0.1 master br0
# tag traffic on ports
bridge vlan add dev lan1 vid 1 pvid untagged
bridge vlan add dev lan2 vid 1 pvid untagged
bridge vlan add dev lan3 vid 1 pvid untagged
# configure the bridge
ip addr add 192.0.2.129/25 dev br0
# bring up the bridge
ip link set dev br0 up
*gateway*
.. code-block:: sh
# tag traffic on CPU port
ip link add link eth0 name eth0.1 type vlan id 1
ip link add link eth0 name eth0.2 type vlan id 2
# For kernels earlier than v5.12, the conduit interface needs to be
# brought up manually before the user ports.
ip link set eth0 up
ip link set eth0.1 up
ip link set eth0.2 up
# bring up the user interfaces
ip link set wan up
ip link set lan1 up
ip link set lan2 up
# create bridge
ip link add name br0 type bridge
# activate VLAN filtering
ip link set dev br0 type bridge vlan_filtering 1
# add ports to bridges
ip link set dev wan master br0
ip link set eth0.1 master br0
ip link set dev lan1 master br0
ip link set dev lan2 master br0
# tag traffic on ports
bridge vlan add dev lan1 vid 1 pvid untagged
bridge vlan add dev lan2 vid 1 pvid untagged
bridge vlan add dev wan vid 2 pvid untagged
# configure the VLANs
ip addr add 192.0.2.1/30 dev eth0.2
ip addr add 192.0.2.129/25 dev br0
# bring up the bridge devices
ip link set br0 up
Forwarding database (FDB) management
------------------------------------
The existing DSA switches do not have the necessary hardware support to keep
the software FDB of the bridge in sync with the hardware tables, so the two
tables are managed separately (``bridge fdb show`` queries both, and depending
on whether the ``self`` or ``master`` flags are being used, a ``bridge fdb
add`` or ``bridge fdb del`` command acts upon entries from one or both tables).
Up until kernel v4.14, DSA only supported user space management of bridge FDB
entries using the bridge bypass operations (which do not update the software
FDB, just the hardware one) using the ``self`` flag (which is optional and can
be omitted).
.. code-block:: sh
bridge fdb add dev swp0 00:01:02:03:04:05 self static
# or shorthand
bridge fdb add dev swp0 00:01:02:03:04:05 static
Due to a bug, the bridge bypass FDB implementation provided by DSA did not
distinguish between ``static`` and ``local`` FDB entries (``static`` are meant
to be forwarded, while ``local`` are meant to be locally terminated, i.e. sent
to the host port). Instead, all FDB entries with the ``self`` flag (implicit or
explicit) are treated by DSA as ``static`` even if they are ``local``.
.. code-block:: sh
# This command:
bridge fdb add dev swp0 00:01:02:03:04:05 static
# behaves the same for DSA as this command:
bridge fdb add dev swp0 00:01:02:03:04:05 local
# or shorthand, because the 'local' flag is implicit if 'static' is not
# specified, it also behaves the same as:
bridge fdb add dev swp0 00:01:02:03:04:05
The last command is an incorrect way of adding a static bridge FDB entry to a
DSA switch using the bridge bypass operations, and works by mistake. Other
drivers will treat an FDB entry added by the same command as ``local`` and as
such, will not forward it, as opposed to DSA.
Between kernel v4.14 and v5.14, DSA has supported in parallel two modes of
adding a bridge FDB entry to the switch: the bridge bypass discussed above, as
well as a new mode using the ``master`` flag which installs FDB entries in the
software bridge too.
.. code-block:: sh
bridge fdb add dev swp0 00:01:02:03:04:05 master static
Since kernel v5.14, DSA has gained stronger integration with the bridge's
software FDB, and the support for its bridge bypass FDB implementation (using
the ``self`` flag) has been removed. This results in the following changes:
.. code-block:: sh
# This is the only valid way of adding an FDB entry that is supported,
# compatible with v4.14 kernels and later:
bridge fdb add dev swp0 00:01:02:03:04:05 master static
# This command is no longer buggy and the entry is properly treated as
# 'local' instead of being forwarded:
bridge fdb add dev swp0 00:01:02:03:04:05
# This command no longer installs a static FDB entry to hardware:
bridge fdb add dev swp0 00:01:02:03:04:05 static
Script writers are therefore encouraged to use the ``master static`` set of
flags when working with bridge FDB entries on DSA switch interfaces.
Affinity of user ports to CPU ports
-----------------------------------
Typically, DSA switches are attached to the host via a single Ethernet
interface, but in cases where the switch chip is discrete, the hardware design
may permit the use of 2 or more ports connected to the host, for an increase in
termination throughput.
DSA can make use of multiple CPU ports in two ways. First, it is possible to
statically assign the termination traffic associated with a certain user port
to be processed by a certain CPU port. This way, user space can implement
custom policies of static load balancing between user ports, by spreading the
affinities according to the available CPU ports.
Secondly, it is possible to perform load balancing between CPU ports on a per
packet basis, rather than statically assigning user ports to CPU ports.
This can be achieved by placing the DSA conduits under a LAG interface (bonding
or team). DSA monitors this operation and creates a mirror of this software LAG
on the CPU ports facing the physical DSA conduits that constitute the LAG slave
devices.
To make use of multiple CPU ports, the firmware (device tree) description of
the switch must mark all the links between CPU ports and their DSA conduits
using the ``ethernet`` reference/phandle. At startup, only a single CPU port
and DSA conduit will be used - the numerically first port from the firmware
description which has an ``ethernet`` property. It is up to the user to
configure the system for the switch to use other conduits.
DSA uses the ``rtnl_link_ops`` mechanism (with a "dsa" ``kind``) to allow
changing the DSA conduit of a user port. The ``IFLA_DSA_CONDUIT`` u32 netlink
attribute contains the ifindex of the conduit device that handles each user
device. The DSA conduit must be a valid candidate based on firmware node
information, or a LAG interface which contains only slaves which are valid
candidates.
Using iproute2, the following manipulations are possible:
.. code-block:: sh
# See the DSA conduit in current use
ip -d link show dev swp0
(...)
dsa master eth0
# Static CPU port distribution
ip link set swp0 type dsa master eth1
ip link set swp1 type dsa master eth0
ip link set swp2 type dsa master eth1
ip link set swp3 type dsa master eth0
# CPU ports in LAG, using explicit assignment of the DSA conduit
ip link add bond0 type bond mode balance-xor && ip link set bond0 up
ip link set eth1 down && ip link set eth1 master bond0
ip link set swp0 type dsa master bond0
ip link set swp1 type dsa master bond0
ip link set swp2 type dsa master bond0
ip link set swp3 type dsa master bond0
ip link set eth0 down && ip link set eth0 master bond0
ip -d link show dev swp0
(...)
dsa master bond0
# CPU ports in LAG, relying on implicit migration of the DSA conduit
ip link add bond0 type bond mode balance-xor && ip link set bond0 up
ip link set eth0 down && ip link set eth0 master bond0
ip link set eth1 down && ip link set eth1 master bond0
ip -d link show dev swp0
(...)
dsa master bond0
Notice that in the case of CPU ports under a LAG, the use of the
``IFLA_DSA_CONDUIT`` netlink attribute is not strictly needed, but rather, DSA
reacts to the ``IFLA_MASTER`` attribute change of its present conduit (``eth0``)
and migrates all user ports to the new upper of ``eth0``, ``bond0``. Similarly,
when ``bond0`` is destroyed using ``RTM_DELLINK``, DSA migrates the user ports
that were assigned to this interface to the first physical DSA conduit which is
eligible, based on the firmware description (it effectively reverts to the
startup configuration).
In a setup with more than 2 physical CPU ports, it is therefore possible to mix
static user to CPU port assignment with LAG between DSA conduits. It is not
possible to statically assign a user port towards a DSA conduit that has any
upper interfaces (this includes LAG devices - the conduit must always be the LAG
in this case).
Live changing of the DSA conduit (and thus CPU port) affinity of a user port is
permitted, in order to allow dynamic redistribution in response to traffic.
Physical DSA conduits are allowed to join and leave at any time a LAG interface
used as a DSA conduit; however, DSA will reject a LAG interface as a valid
candidate for being a DSA conduit unless it has at least one physical DSA conduit
as a slave device.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
사용자 공간 DSA 수동 구성
1-9이 문서는 `GPL-2.0` 라이선스를 따릅니다.
사용자 공간에서 DSA 스위치 구성
DSA 스위치 구성은 아직 주요 사용자 공간 네트워크 구성 도구 모음에 통합되지 않았으므로 수동으로 수행해야 합니다.
.. SPDX-License-Identifier: GPL-2.0
=======================================
DSA switch configuration from userspace
=======================================
The DSA switch configuration is not integrated into the main userspace
network configuration suites by now and has to be performed manually.
세 가지 구성 예제
10-30구성 예제
DSA 스위치를 구성하려면 여러 명령을 실행해야 합니다. 이 문서는 흔한 세 가지 시나리오를 예제로 다룹니다.
단일 포트 구성에서는 각 스위치 포트가 서로 독립적으로 구성 가능한 이더넷 포트로 동작합니다.
브리지 구성에서는 모든 스위치 포트가 하나의 구성 가능한 이더넷 브리지에 속합니다.
게이트웨이 구성에서는 업스트림 포트 하나를 제외한 모든 스위치 포트가 이더넷 브리지에 속하고, 업스트림 포트는 별도의 구성 가능한 이더넷 포트로 동작합니다.
모든 구성은 `https://www.kernel.org/pub/linux/utils/net/iproute2/`에서 제공하는 iproute2 도구로 수행합니다.
.. _dsa-config-showcases:
Configuration showcases
-----------------------
To configure a DSA switch a couple of commands need to be executed. In this
documentation some common configuration scenarios are handled as showcases:
*single port*
Every switch port acts as a different configurable Ethernet port
*bridge*
Every switch port is part of one configurable Ethernet bridge
*gateway*
Every switch port except one upstream port is part of a configurable
Ethernet bridge.
The upstream port acts as different configurable Ethernet port.
All configurations are performed with tools from iproute2, which is available
at https://www.kernel.org/pub/linux/utils/net/iproute2/
CPU 포트·conduit·사용자 인터페이스
31-46DSA를 사용하면 스위치의 각 포트를 일반 Linux 이더넷 인터페이스처럼 다룹니다. CPU 포트는 이더넷 MAC 칩에 연결된 스위치 포트이며, 이에 대응하는 Linux 이더넷 인터페이스를 conduit 인터페이스라고 합니다. 나머지 인터페이스는 사용자 인터페이스입니다.
사용자 인터페이스가 트래픽을 송수신하려면 conduit 인터페이스가 up이어야 합니다. 커널 v5.12 이전에는 사용자가 conduit 상태를 명시적으로 관리해야 했습니다.
v5.12부터 DSA 사용자 인터페이스를 올리면 conduit가 자동으로 올라가고, conduit를 내리면 모든 DSA 사용자 인터페이스가 자동으로 내려갑니다.
Through DSA every port of a switch is handled like a normal linux Ethernet
interface. The CPU port is the switch port connected to an Ethernet MAC chip.
The corresponding linux Ethernet interface is called the conduit interface.
All other corresponding linux interfaces are called user interfaces.
The user interfaces depend on the conduit interface being up in order for them
to send or receive traffic. Prior to kernel v5.12, the state of the conduit
interface had to be managed explicitly by the user. Starting with kernel v5.12,
the behavior is as follows:
- when a DSA user interface is brought up, the conduit interface is
automatically brought up.
- when the conduit interface is brought down, all DSA user interfaces are
automatically brought down.
예제 인터페이스와 주소 계획
47-81예제에서 `eth0`은 conduit 인터페이스, `eth1`은 또 다른 conduit 인터페이스입니다. `lan1`, `lan2`, `lan3`은 사용자 인터페이스이며 `wan`은 업스트림 트래픽 전용 사용자 인터페이스입니다. 다른 이더넷 인터페이스도 같은 방식으로 구성할 수 있습니다.
세 시나리오에서 인터페이스와 IP 네트워크를 배치하는 방식입니다.
In this documentation the following Ethernet interfaces are used:
*eth0*
the conduit interface
*eth1*
another conduit interface
*lan1*
a user interface
*lan2*
another user interface
*lan3*
a third user interface
*wan*
A user interface dedicated for upstream traffic
Further Ethernet interfaces can be configured similar.
The configured IPs and networks are:
*single port*
* lan1: 192.0.2.1/30 (192.0.2.0 - 192.0.2.3)
* lan2: 192.0.2.5/30 (192.0.2.4 - 192.0.2.7)
* lan3: 192.0.2.9/30 (192.0.2.8 - 192.0.2.11)
*bridge*
* br0: 192.0.2.129/25 (192.0.2.128 - 192.0.2.255)
*gateway*
* br0: 192.0.2.129/25 (192.0.2.128 - 192.0.2.255)
* wan: 192.0.2.1/30 (192.0.2.0 - 192.0.2.3)
태깅 지원 스위치
82-90태깅 지원 구성
태그 기반 구성이 권장되며 대부분의 DSA 스위치가 이를 지원합니다. 이런 스위치는 VLAN 기반 구성을 사용하지 않고도 들어오고 나가는 트래픽에 태그를 붙일 수 있습니다.
.. _dsa-tagged-configuration:
Configuration with tagging support
----------------------------------
The tagging based configuration is desired and supported by the majority of
DSA switches. These switches are capable to tag incoming and outgoing traffic
without using a VLAN based configuration.
태그 기반 단일 포트 구성
91-107단일 포트
각 LAN 사용자 인터페이스에 별도의 /30 주소를 직접 설정합니다. v5.12 이전 커널에서는 사용자 포트보다 먼저 `eth0` conduit를 수동으로 올린 뒤 각 사용자 인터페이스를 올립니다.
# configure each interface
ip addr add 192.0.2.1/30 dev lan1
ip addr add 192.0.2.5/30 dev lan2
ip addr add 192.0.2.9/30 dev lan3
# For kernels earlier than v5.12, the conduit interface needs to be
# brought up manually before the user ports.
ip link set eth0 up
# bring up the user interfaces
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
*single port*
.. code-block:: sh
# configure each interface
ip addr add 192.0.2.1/30 dev lan1
ip addr add 192.0.2.5/30 dev lan2
ip addr add 192.0.2.9/30 dev lan3
# For kernels earlier than v5.12, the conduit interface needs to be
# brought up manually before the user ports.
ip link set eth0 up
# bring up the user interfaces
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
태그 기반 브리지 구성
108-133브리지
필요하면 conduit를 먼저 올리고 세 LAN 사용자 인터페이스를 활성화합니다. `br0`를 만들고 `lan1`~`lan3`을 연결한 뒤 주소 `192.0.2.129/25`를 브리지에 설정하여 올립니다.
# For kernels earlier than v5.12, the conduit interface needs to be
# brought up manually before the user ports.
ip link set eth0 up
# bring up the user interfaces
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
# create bridge
ip link add name br0 type bridge
# add ports to bridge
ip link set dev lan1 master br0
ip link set dev lan2 master br0
ip link set dev lan3 master br0
# configure the bridge
ip addr add 192.0.2.129/25 dev br0
# bring up the bridge
ip link set dev br0 up
*bridge*
.. code-block:: sh
# For kernels earlier than v5.12, the conduit interface needs to be
# brought up manually before the user ports.
ip link set eth0 up
# bring up the user interfaces
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
# create bridge
ip link add name br0 type bridge
# add ports to bridge
ip link set dev lan1 master br0
ip link set dev lan2 master br0
ip link set dev lan3 master br0
# configure the bridge
ip addr add 192.0.2.129/25 dev br0
# bring up the bridge
ip link set dev br0 up
태그 기반 게이트웨이 구성
134-161게이트웨이
`wan`, `lan1`, `lan2`를 올리고 `wan`에 업스트림 주소 `192.0.2.1/30`을 직접 설정합니다. 두 LAN 포트만 `br0`에 연결하고 브리지에 `192.0.2.129/25`를 설정합니다.
# For kernels earlier than v5.12, the conduit interface needs to be
# brought up manually before the user ports.
ip link set eth0 up
# bring up the user interfaces
ip link set wan up
ip link set lan1 up
ip link set lan2 up
# configure the upstream port
ip addr add 192.0.2.1/30 dev wan
# create bridge
ip link add name br0 type bridge
# add ports to bridge
ip link set dev lan1 master br0
ip link set dev lan2 master br0
# configure the bridge
ip addr add 192.0.2.129/25 dev br0
# bring up the bridge
ip link set dev br0 up
*gateway*
.. code-block:: sh
# For kernels earlier than v5.12, the conduit interface needs to be
# brought up manually before the user ports.
ip link set eth0 up
# bring up the user interfaces
ip link set wan up
ip link set lan1 up
ip link set lan2 up
# configure the upstream port
ip addr add 192.0.2.1/30 dev wan
# create bridge
ip link add name br0 type bridge
# add ports to bridge
ip link set dev lan1 master br0
ip link set dev lan2 master br0
# configure the bridge
ip addr add 192.0.2.129/25 dev br0
# bring up the bridge
ip link set dev br0 up
태깅 프로토콜 미지원 스위치
162-170태깅 미지원 구성
일부 스위치는 태깅 프로토콜 `DSA_TAG_PROTO_NONE`만 사용하여 전용 태그를 붙일 수 없습니다. 이런 스위치는 VLAN 기반 구성으로 설정할 수 있습니다.
.. _dsa-vlan-configuration:
Configuration without tagging support
-------------------------------------
A minority of switches are not capable to use a taging protocol
(DSA_TAG_PROTO_NONE). These switches can be configured by a VLAN based
configuration.
VLAN 기반 단일 포트 구성
171-217단일 포트
이 구성은 VLAN 태깅과 브리지 설정을 함께 사용해야 합니다. CPU 포트에 VLAN 1·2·3 서브인터페이스를 만들고 conduit 및 사용자 포트를 올린 뒤 VLAN 필터링 브리지에 사용자 포트를 연결합니다.
`lan1`, `lan2`, `lan3`을 각각 VID 1, 2, 3의 PVID 비태그 포트로 만들고, 해당 CPU VLAN 인터페이스에 각 /30 주소를 설정합니다.
# tag traffic on CPU port
ip link add link eth0 name eth0.1 type vlan id 1
ip link add link eth0 name eth0.2 type vlan id 2
ip link add link eth0 name eth0.3 type vlan id 3
# For kernels earlier than v5.12, the conduit interface needs to be
# brought up manually before the user ports.
ip link set eth0 up
ip link set eth0.1 up
ip link set eth0.2 up
ip link set eth0.3 up
# bring up the user interfaces
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
# create bridge
ip link add name br0 type bridge
# activate VLAN filtering
ip link set dev br0 type bridge vlan_filtering 1
# add ports to bridges
ip link set dev lan1 master br0
ip link set dev lan2 master br0
ip link set dev lan3 master br0
# tag traffic on ports
bridge vlan add dev lan1 vid 1 pvid untagged
bridge vlan add dev lan2 vid 2 pvid untagged
bridge vlan add dev lan3 vid 3 pvid untagged
# configure the VLANs
ip addr add 192.0.2.1/30 dev eth0.1
ip addr add 192.0.2.5/30 dev eth0.2
ip addr add 192.0.2.9/30 dev eth0.3
# bring up the bridge devices
ip link set br0 up
*single port*
The configuration can only be set up via VLAN tagging and bridge setup.
.. code-block:: sh
# tag traffic on CPU port
ip link add link eth0 name eth0.1 type vlan id 1
ip link add link eth0 name eth0.2 type vlan id 2
ip link add link eth0 name eth0.3 type vlan id 3
# For kernels earlier than v5.12, the conduit interface needs to be
# brought up manually before the user ports.
ip link set eth0 up
ip link set eth0.1 up
ip link set eth0.2 up
ip link set eth0.3 up
# bring up the user interfaces
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
# create bridge
ip link add name br0 type bridge
# activate VLAN filtering
ip link set dev br0 type bridge vlan_filtering 1
# add ports to bridges
ip link set dev lan1 master br0
ip link set dev lan2 master br0
ip link set dev lan3 master br0
# tag traffic on ports
bridge vlan add dev lan1 vid 1 pvid untagged
bridge vlan add dev lan2 vid 2 pvid untagged
bridge vlan add dev lan3 vid 3 pvid untagged
# configure the VLANs
ip addr add 192.0.2.1/30 dev eth0.1
ip addr add 192.0.2.5/30 dev eth0.2
ip addr add 192.0.2.9/30 dev eth0.3
# bring up the bridge devices
ip link set br0 up
VLAN 기반 브리지 구성
218-256브리지
CPU 포트에 VLAN 1 서브인터페이스를 만들고 사용자 포트 세 개와 함께 VLAN 필터링 `br0`에 넣습니다. 모든 사용자 포트를 VID 1의 PVID 비태그 포트로 설정하고 브리지에 `192.0.2.129/25`를 할당합니다.
# tag traffic on CPU port
ip link add link eth0 name eth0.1 type vlan id 1
# For kernels earlier than v5.12, the conduit interface needs to be
# brought up manually before the user ports.
ip link set eth0 up
ip link set eth0.1 up
# bring up the user interfaces
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
# create bridge
ip link add name br0 type bridge
# activate VLAN filtering
ip link set dev br0 type bridge vlan_filtering 1
# add ports to bridge
ip link set dev lan1 master br0
ip link set dev lan2 master br0
ip link set dev lan3 master br0
ip link set eth0.1 master br0
# tag traffic on ports
bridge vlan add dev lan1 vid 1 pvid untagged
bridge vlan add dev lan2 vid 1 pvid untagged
bridge vlan add dev lan3 vid 1 pvid untagged
# configure the bridge
ip addr add 192.0.2.129/25 dev br0
# bring up the bridge
ip link set dev br0 up
*bridge*
.. code-block:: sh
# tag traffic on CPU port
ip link add link eth0 name eth0.1 type vlan id 1
# For kernels earlier than v5.12, the conduit interface needs to be
# brought up manually before the user ports.
ip link set eth0 up
ip link set eth0.1 up
# bring up the user interfaces
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
# create bridge
ip link add name br0 type bridge
# activate VLAN filtering
ip link set dev br0 type bridge vlan_filtering 1
# add ports to bridge
ip link set dev lan1 master br0
ip link set dev lan2 master br0
ip link set dev lan3 master br0
ip link set eth0.1 master br0
# tag traffic on ports
bridge vlan add dev lan1 vid 1 pvid untagged
bridge vlan add dev lan2 vid 1 pvid untagged
bridge vlan add dev lan3 vid 1 pvid untagged
# configure the bridge
ip addr add 192.0.2.129/25 dev br0
# bring up the bridge
ip link set dev br0 up
VLAN 기반 게이트웨이 구성
257-298게이트웨이
CPU 포트에 VLAN 1과 2 서브인터페이스를 만들고 `wan`, `eth0.1`, 두 LAN 포트를 `br0`에 넣습니다. LAN은 VID 1, WAN은 VID 2의 PVID 비태그 포트로 지정합니다.
WAN VLAN의 CPU 쪽 `eth0.2`에 `192.0.2.1/30`, 브리지에 `192.0.2.129/25`를 설정합니다.
# tag traffic on CPU port
ip link add link eth0 name eth0.1 type vlan id 1
ip link add link eth0 name eth0.2 type vlan id 2
# For kernels earlier than v5.12, the conduit interface needs to be
# brought up manually before the user ports.
ip link set eth0 up
ip link set eth0.1 up
ip link set eth0.2 up
# bring up the user interfaces
ip link set wan up
ip link set lan1 up
ip link set lan2 up
# create bridge
ip link add name br0 type bridge
# activate VLAN filtering
ip link set dev br0 type bridge vlan_filtering 1
# add ports to bridges
ip link set dev wan master br0
ip link set eth0.1 master br0
ip link set dev lan1 master br0
ip link set dev lan2 master br0
# tag traffic on ports
bridge vlan add dev lan1 vid 1 pvid untagged
bridge vlan add dev lan2 vid 1 pvid untagged
bridge vlan add dev wan vid 2 pvid untagged
# configure the VLANs
ip addr add 192.0.2.1/30 dev eth0.2
ip addr add 192.0.2.129/25 dev br0
# bring up the bridge devices
ip link set br0 up
*gateway*
.. code-block:: sh
# tag traffic on CPU port
ip link add link eth0 name eth0.1 type vlan id 1
ip link add link eth0 name eth0.2 type vlan id 2
# For kernels earlier than v5.12, the conduit interface needs to be
# brought up manually before the user ports.
ip link set eth0 up
ip link set eth0.1 up
ip link set eth0.2 up
# bring up the user interfaces
ip link set wan up
ip link set lan1 up
ip link set lan2 up
# create bridge
ip link add name br0 type bridge
# activate VLAN filtering
ip link set dev br0 type bridge vlan_filtering 1
# add ports to bridges
ip link set dev wan master br0
ip link set eth0.1 master br0
ip link set dev lan1 master br0
ip link set dev lan2 master br0
# tag traffic on ports
bridge vlan add dev lan1 vid 1 pvid untagged
bridge vlan add dev lan2 vid 1 pvid untagged
bridge vlan add dev wan vid 2 pvid untagged
# configure the VLANs
ip addr add 192.0.2.1/30 dev eth0.2
ip addr add 192.0.2.129/25 dev br0
# bring up the bridge devices
ip link set br0 up
소프트웨어·하드웨어 FDB와 구형 self 방식
299-318포워딩 데이터베이스(FDB) 관리
기존 DSA 스위치는 브리지의 소프트웨어 FDB와 하드웨어 테이블을 동기화할 하드웨어 지원이 없으므로 두 테이블을 별도로 관리합니다. `bridge fdb show`는 둘 다 조회하지만 `bridge fdb add`와 `bridge fdb del`은 `self` 또는 `master` 플래그에 따라 한쪽이나 양쪽 테이블의 항목에 작용합니다.
커널 v4.14까지 DSA는 소프트웨어 FDB를 갱신하지 않고 하드웨어만 갱신하는 브리지 우회 작업을 통한 사용자 공간 FDB 관리만 지원했습니다. 이때 선택적인 `self` 플래그를 사용했습니다.
bridge fdb add dev swp0 00:01:02:03:04:05 self static
# or shorthand
bridge fdb add dev swp0 00:01:02:03:04:05 static
Forwarding database (FDB) management
------------------------------------
The existing DSA switches do not have the necessary hardware support to keep
the software FDB of the bridge in sync with the hardware tables, so the two
tables are managed separately (``bridge fdb show`` queries both, and depending
on whether the ``self`` or ``master`` flags are being used, a ``bridge fdb
add`` or ``bridge fdb del`` command acts upon entries from one or both tables).
Up until kernel v4.14, DSA only supported user space management of bridge FDB
entries using the bridge bypass operations (which do not update the software
FDB, just the hardware one) using the ``self`` flag (which is optional and can
be omitted).
.. code-block:: sh
bridge fdb add dev swp0 00:01:02:03:04:05 self static
# or shorthand
bridge fdb add dev swp0 00:01:02:03:04:05 static
self FDB의 static·local 구분 오류
319-339버그 때문에 DSA의 브리지 우회 FDB 구현은 `static`과 `local` 항목을 구분하지 못했습니다. `static`은 전달할 항목이고 `local`은 호스트 포트로 보내 로컬에서 종단할 항목입니다.
DSA는 암시적이든 명시적이든 `self` 플래그가 있는 모든 FDB 항목을 `local`로 지정해도 `static`으로 취급했습니다. 따라서 아래 세 명령은 DSA에서 같은 방식으로 동작했습니다.
bridge fdb add dev swp0 00:01:02:03:04:05 static
bridge fdb add dev swp0 00:01:02:03:04:05 local
bridge fdb add dev swp0 00:01:02:03:04:05
마지막 명령으로 DSA 스위치에 정적 FDB 항목이 추가되는 것은 잘못된 사용법이며 우연히 동작한 것입니다. 다른 드라이버는 같은 명령의 항목을 `local`로 취급하여 전달하지 않습니다.
Due to a bug, the bridge bypass FDB implementation provided by DSA did not
distinguish between ``static`` and ``local`` FDB entries (``static`` are meant
to be forwarded, while ``local`` are meant to be locally terminated, i.e. sent
to the host port). Instead, all FDB entries with the ``self`` flag (implicit or
explicit) are treated by DSA as ``static`` even if they are ``local``.
.. code-block:: sh
# This command:
bridge fdb add dev swp0 00:01:02:03:04:05 static
# behaves the same for DSA as this command:
bridge fdb add dev swp0 00:01:02:03:04:05 local
# or shorthand, because the 'local' flag is implicit if 'static' is not
# specified, it also behaves the same as:
bridge fdb add dev swp0 00:01:02:03:04:05
The last command is an incorrect way of adding a static bridge FDB entry to a
DSA switch using the bridge bypass operations, and works by mistake. Other
drivers will treat an FDB entry added by the same command as ``local`` and as
such, will not forward it, as opposed to DSA.
v4.14~v5.14 전환과 master static
340-366커널 v4.14부터 v5.14 사이에는 기존 브리지 우회 방식과 `master` 플래그를 사용해 소프트웨어 브리지에도 FDB 항목을 설치하는 새 방식을 함께 지원했습니다.
bridge fdb add dev swp0 00:01:02:03:04:05 master static
v5.14부터 DSA와 브리지 소프트웨어 FDB의 통합이 강화되었고 `self` 플래그를 사용하는 브리지 우회 구현은 제거되었습니다.
이후 정적 FDB 항목을 추가하는 유일한 지원 방식은 `master static`이며 v4.14 이상과 호환됩니다. 플래그 없는 항목은 이제 올바르게 `local`로 처리되고, `static`만 지정한 명령은 더 이상 하드웨어에 정적 항목을 설치하지 않습니다.
bridge fdb add dev swp0 00:01:02:03:04:05 master static
bridge fdb add dev swp0 00:01:02:03:04:05
bridge fdb add dev swp0 00:01:02:03:04:05 static
따라서 스크립트 작성자는 DSA 스위치 인터페이스의 브리지 FDB 항목을 다룰 때 `master static` 플래그 조합을 사용해야 합니다.
Between kernel v4.14 and v5.14, DSA has supported in parallel two modes of
adding a bridge FDB entry to the switch: the bridge bypass discussed above, as
well as a new mode using the ``master`` flag which installs FDB entries in the
software bridge too.
.. code-block:: sh
bridge fdb add dev swp0 00:01:02:03:04:05 master static
Since kernel v5.14, DSA has gained stronger integration with the bridge's
software FDB, and the support for its bridge bypass FDB implementation (using
the ``self`` flag) has been removed. This results in the following changes:
.. code-block:: sh
# This is the only valid way of adding an FDB entry that is supported,
# compatible with v4.14 kernels and later:
bridge fdb add dev swp0 00:01:02:03:04:05 master static
# This command is no longer buggy and the entry is properly treated as
# 'local' instead of being forwarded:
bridge fdb add dev swp0 00:01:02:03:04:05
# This command no longer installs a static FDB entry to hardware:
bridge fdb add dev swp0 00:01:02:03:04:05 static
Script writers are therefore encouraged to use the ``master static`` set of
flags when working with bridge FDB entries on DSA switch interfaces.
사용자 포트와 CPU 포트의 결합 방식
367-400사용자 포트의 CPU 포트 affinity
DSA 스위치는 보통 하나의 이더넷 인터페이스로 호스트에 연결되지만, 별도 스위치 칩에서는 종단 처리량을 높이기 위해 둘 이상의 호스트 연결 포트를 사용할 수 있습니다.
첫 번째 방식은 특정 사용자 포트의 종단 트래픽을 특정 CPU 포트에 정적으로 할당하는 것입니다. 사용자 공간은 가용 CPU 포트에 affinity를 분산해 사용자 포트 간 정적 부하 분산 정책을 구현할 수 있습니다.
두 번째 방식은 사용자 포트를 정적으로 배정하지 않고 패킷별로 CPU 포트 사이에서 부하를 분산하는 것입니다. DSA conduit를 bonding 또는 team LAG 인터페이스 아래에 두면 DSA가 이를 감시하고, LAG slave인 물리 DSA conduit와 마주 보는 CPU 포트에 소프트웨어 LAG의 미러를 만듭니다.
여러 CPU 포트를 사용하려면 펌웨어 Device Tree가 모든 CPU 포트와 DSA conduit 사이 링크를 `ethernet` 참조 또는 phandle로 표시해야 합니다. 시작 시에는 `ethernet` 속성이 있는 포트 중 번호가 가장 빠른 CPU 포트와 conduit 하나만 사용하며, 다른 conduit 사용은 사용자가 구성합니다.
DSA는 `dsa` kind의 `rtnl_link_ops`와 u32 netlink 속성 `IFLA_DSA_CONDUIT`를 사용해 사용자 포트의 conduit를 바꿉니다. 값은 각 사용자 장치를 처리하는 conduit 장치의 ifindex입니다. 후보는 펌웨어 노드상 유효한 물리 conduit이거나, slave가 모두 유효한 후보인 LAG여야 합니다.
Affinity of user ports to CPU ports
-----------------------------------
Typically, DSA switches are attached to the host via a single Ethernet
interface, but in cases where the switch chip is discrete, the hardware design
may permit the use of 2 or more ports connected to the host, for an increase in
termination throughput.
DSA can make use of multiple CPU ports in two ways. First, it is possible to
statically assign the termination traffic associated with a certain user port
to be processed by a certain CPU port. This way, user space can implement
custom policies of static load balancing between user ports, by spreading the
affinities according to the available CPU ports.
Secondly, it is possible to perform load balancing between CPU ports on a per
packet basis, rather than statically assigning user ports to CPU ports.
This can be achieved by placing the DSA conduits under a LAG interface (bonding
or team). DSA monitors this operation and creates a mirror of this software LAG
on the CPU ports facing the physical DSA conduits that constitute the LAG slave
devices.
To make use of multiple CPU ports, the firmware (device tree) description of
the switch must mark all the links between CPU ports and their DSA conduits
using the ``ethernet`` reference/phandle. At startup, only a single CPU port
and DSA conduit will be used - the numerically first port from the firmware
description which has an ``ethernet`` property. It is up to the user to
configure the system for the switch to use other conduits.
DSA uses the ``rtnl_link_ops`` mechanism (with a "dsa" ``kind``) to allow
changing the DSA conduit of a user port. The ``IFLA_DSA_CONDUIT`` u32 netlink
attribute contains the ifindex of the conduit device that handles each user
device. The DSA conduit must be a valid candidate based on firmware node
information, or a LAG interface which contains only slaves which are valid
candidates.
iproute2로 CPU 포트 배치와 LAG 구성
401-436iproute2에서는 현재 conduit 확인, 사용자 포트별 정적 CPU 포트 분산, conduit를 명시적으로 LAG에 배정, 기존 conduit의 LAG 편입에 따른 암시적 마이그레이션을 수행할 수 있습니다.
# See the DSA conduit in current use
ip -d link show dev swp0
(...)
dsa master eth0
# Static CPU port distribution
ip link set swp0 type dsa master eth1
ip link set swp1 type dsa master eth0
ip link set swp2 type dsa master eth1
ip link set swp3 type dsa master eth0
# CPU ports in LAG, using explicit assignment of the DSA conduit
ip link add bond0 type bond mode balance-xor && ip link set bond0 up
ip link set eth1 down && ip link set eth1 master bond0
ip link set swp0 type dsa master bond0
ip link set swp1 type dsa master bond0
ip link set swp2 type dsa master bond0
ip link set swp3 type dsa master bond0
ip link set eth0 down && ip link set eth0 master bond0
ip -d link show dev swp0
(...)
dsa master bond0
# CPU ports in LAG, relying on implicit migration of the DSA conduit
ip link add bond0 type bond mode balance-xor && ip link set bond0 up
ip link set eth0 down && ip link set eth0 master bond0
ip link set eth1 down && ip link set eth1 master bond0
ip -d link show dev swp0
(...)
dsa master bond0
Using iproute2, the following manipulations are possible:
.. code-block:: sh
# See the DSA conduit in current use
ip -d link show dev swp0
(...)
dsa master eth0
# Static CPU port distribution
ip link set swp0 type dsa master eth1
ip link set swp1 type dsa master eth0
ip link set swp2 type dsa master eth1
ip link set swp3 type dsa master eth0
# CPU ports in LAG, using explicit assignment of the DSA conduit
ip link add bond0 type bond mode balance-xor && ip link set bond0 up
ip link set eth1 down && ip link set eth1 master bond0
ip link set swp0 type dsa master bond0
ip link set swp1 type dsa master bond0
ip link set swp2 type dsa master bond0
ip link set swp3 type dsa master bond0
ip link set eth0 down && ip link set eth0 master bond0
ip -d link show dev swp0
(...)
dsa master bond0
# CPU ports in LAG, relying on implicit migration of the DSA conduit
ip link add bond0 type bond mode balance-xor && ip link set bond0 up
ip link set eth0 down && ip link set eth0 master bond0
ip link set eth1 down && ip link set eth1 master bond0
ip -d link show dev swp0
(...)
dsa master bond0
LAG 자동 마이그레이션과 유효성 규칙
437-458CPU 포트가 LAG 아래에 있을 때 `IFLA_DSA_CONDUIT` 속성은 필수가 아닙니다. DSA는 현재 conduit인 `eth0`의 `IFLA_MASTER` 변경에 반응하여 모든 사용자 포트를 `eth0`의 새 상위 장치인 `bond0`으로 옮깁니다.
`RTM_DELLINK`로 `bond0`를 제거하면 DSA는 그 인터페이스에 할당됐던 사용자 포트를 펌웨어 설명상 유효한 첫 번째 물리 DSA conduit로 옮겨 시작 구성으로 되돌립니다.
물리 CPU 포트가 셋 이상이면 사용자 포트와 CPU 포트의 정적 배정 및 DSA conduit 사이 LAG를 혼합할 수 있습니다. 다만 상위 인터페이스가 있는 물리 DSA conduit에 사용자 포트를 정적으로 직접 할당할 수는 없습니다. LAG가 있으면 conduit는 언제나 LAG 자체여야 합니다.
트래픽 변화에 따라 동적으로 재분배할 수 있도록 사용자 포트의 DSA conduit, 즉 CPU 포트 affinity를 실행 중에 변경할 수 있습니다.
물리 DSA conduit는 conduit로 쓰이는 LAG에 언제든 가입하거나 탈퇴할 수 있습니다. 그러나 물리 DSA conduit slave가 하나도 없는 LAG는 DSA conduit 후보로 거부됩니다.
Notice that in the case of CPU ports under a LAG, the use of the
``IFLA_DSA_CONDUIT`` netlink attribute is not strictly needed, but rather, DSA
reacts to the ``IFLA_MASTER`` attribute change of its present conduit (``eth0``)
and migrates all user ports to the new upper of ``eth0``, ``bond0``. Similarly,
when ``bond0`` is destroyed using ``RTM_DELLINK``, DSA migrates the user ports
that were assigned to this interface to the first physical DSA conduit which is
eligible, based on the firmware description (it effectively reverts to the
startup configuration).
In a setup with more than 2 physical CPU ports, it is therefore possible to mix
static user to CPU port assignment with LAG between DSA conduits. It is not
possible to statically assign a user port towards a DSA conduit that has any
upper interfaces (this includes LAG devices - the conduit must always be the LAG
in this case).
Live changing of the DSA conduit (and thus CPU port) affinity of a user port is
permitted, in order to allow dynamic redistribution in response to traffic.
Physical DSA conduits are allowed to join and leave at any time a LAG interface
used as a DSA conduit; however, DSA will reject a LAG interface as a valid
candidate for being a DSA conduit unless it has at least one physical DSA conduit
as a slave device.
요약·해설
configuration.rst:1-458DSA 사용자 포트는 일반 이더넷 인터페이스처럼 보이지만 CPU 포트와 연결된 conduit에 의존합니다. 전용 태그를 지원하면 사용자 포트를 직접 구성하고, 지원하지 않으면 CPU 포트 VLAN 서브인터페이스와 VLAN 필터링 브리지가 필요합니다. FDB 스크립트는 커널 v5.14 이후의 `master static` 규약을 사용해야 합니다.
하드웨어 태그 지원 여부와 목적에 따라 필요한 구성이 달라집니다.
사용자 포트 트래픽을 물리 conduit에 직접 배정하거나 LAG에서 패킷별로 분산합니다.