HBN 服务部署
请参阅“HBN 服务发行说明”页面,了解有关 HBN 的特定硬件和软件要求的信息。
以下小节介绍了在部署 DOCA HBN 服务之前 BlueField 的特定先决条件。
启用 BlueField DPU 模式
HBN 要求 BlueField 在 DPU 模式或零信任操作模式下工作。有关配置 BlueField 操作模式的信息,请参见“BlueField 操作模式”。
启用 SFC
HBN 要求在运行 HBN 服务容器之前,在 BlueField 上激活 SFC 配置。SFC 允许将其他服务/容器链接到 HBN,并提供额外的数据操作功能。SFC 可以配置为 3 种模式
仅 HBN 模式 – 在此模式下,将创建一个 OVS 网桥,
br-hbn
。所有 HBN 特定的端口都将添加到此网桥。这是默认的操作模式。此模式通过在bf.cfg
中设置ENABLE_BR_HBN=yes
并将ENABLE_BR_SFC
保留为默认值来配置。双桥模式 – 在此模式下,将创建 2 个 OVS 网桥,
br-hbn
和bf-sfc
。所有 HBN 特定的端口都将添加到bf-sfc
网桥,并且所有这些端口都将修补到br-hbn
网桥。bf-sfc
可用于添加各种自定义转向流,以将流量定向到网桥中的不同端口。在此模式下,ENABLE_BR_SFC
和ENABLE_BR_HBN
都设置为yes
。BR_HBN_XXX
参数未设置,所有端口都在BR_SFC_XXX
变量下。混合模式 – 这类似于双桥模型,不同之处在于端口可以分配给任一网桥(即,
br-hbn
中的一些端口和bf-sfc
网桥中的一些端口)。在此模式下,端口位于BR_SFC_XXX
和BR_HBN_XXX
下。使用网桥
br-sfc
允许在 HBN 管道之前或之后定义特定于部署的规则。用户可以直接向bf-sfc
网桥添加 OpenFlow 规则。如果ENABLE_BR_SFC_DEFAULT_FLOWS
设置为yes
,请确保用户规则以更高的优先级插入,使其生效。
下表描述了用于配置这些模式的各种 bf.cfg
参数,以及将端口分配给各种网桥的其他参数
参数 | 描述 | 强制性 | 默认值 | 示例 |
| 将此参数设置为 注意
此设置对于使用 HBN 是必要的。 | 是 |
|
|
| 将此参数设置为 信息
仅当第二个 OVS 网桥需要用于自定义转向流时才需要此项。 | 否 |
|
|
| 直接添加到 | 否 |
|
|
| 直接添加到 | 否 |
|
|
| 直接添加到 | 否 |
|
|
| 直接添加到 | 否 |
|
|
| 直接添加到 | 否 |
|
|
| 直接添加到 | 否 |
|
|
| 添加到 | 否 |
| |
| 链接传播应如何工作的映射。如果未提供任何内容,则每个上行链路/PF/VF 端口都会在其相应的 HBN 端口中反映其状态。例如,p0 的状态反映在 | 否 | 上行链路/PF/VF 到相应的 HBN 端口 |
|
| 在 | 否 |
|
|
| 设置 DOCA-OVS 要使用的大页大小。仅针对 HBN 测试了 2048,这也是默认值。 | 否 |
|
|
| 设置 HBN 应用程序所需的大页数量。当前的默认限制为 3072。当 HBN 与其他服务一起运行时,必须相应地修改此值。 | 否 |
|
|
有关每种模式下端口连接的更多信息,请参阅“HBN 部署配置”部分。
以下小节提供了有关 SFC 的其他信息以及有关在 BlueField DOCA 镜像安装期间启用 SFC 的说明。
从主机部署带有 SFC 的 BlueField DOCA 镜像
对于 BlueField 上的 DOCA 镜像安装,用户应按照 的说明进行操作Linux 版 DOCA 安装指南,并附带以下额外说明以启用 BlueField 以进行 HBN 设置
确保在“在主机上安装软件”部分下,链接类型设置为 ETH。
将以下参数添加到
bf.cfg
配置文件:此配置示例与“仅 HBN 模式”相关。根据您的部署模型设置适当的变量和值。
通过设置 ENABLE_BR_HBN=yes,在 BlueField Arm 上启用 HBN 特定的 OVS 网桥。
定义 HBN 要使用的上行链路端口
BR_HBN_UPLINKS='<port>'
。注意对于双端口 BlueField 设备,必须同时包含两个端口(即
p0,p1
),对于单端口 BlueField 设备,仅包含p0
。包含 HBN 要使用的 PF 和 VF 端口。以下示例在每个上行链路上设置 PF 和 8 个 VF:
BR_HBN_REPS='pf0hpf,pf1hpf,pf0vf0-pf0vf7,pf1vf0-pf1vf7'
。(可选)包含要创建并连接到 BlueField Arm 侧的 HBN 网桥的 SF 设备,方法是设置
BR_HBN_SFS='pf0dpu1,pf0dpu3'
。信息如果未提供任何内容,则默认情况下会创建
pf0dpu1
和pf0dpu3
。警告虽然旧格式的
bf.cfg
在此版本中仍然有效,但它们将在接下来的 2 个版本中弃用。因此,建议迁移到新格式,以避免未来版本中的任何升级问题。以下是旧bf.cfg
格式的示例ENABLE_SFC_HBN=
yes
NUM_VFs_PHYS_PORT0=12# <num VFs supported by HBN on Physical Port 0> (valid range: 0-127) Default 14
NUM_VFs_PHYS_PORT1=2# <num VFs supported by HBN on Physical Port 1> (valid range: 0-127) Default 0
然后运行
bfb-
install
-c bf.cfg -r rshim0 -b <BFB-image>SFC 部署完成后,它会创建 3 组文件
/etc/mellanox/hbn.conf
– 此文件可用于重新部署 SFC,而无需再次通过bf.cfg
来修改接口映射/etc/mellanox/sfc.conf
– 此文件提供了有关各种端口如何在不同网桥中连接的视图/etc/mellanox/mlnx-sf.conf
– 此文件包含要创建的所有 HBN 端口以及用于创建端口的相应命令
使用 PXE 启动部署带有 SFC 的 BlueField DOCA 镜像
要使用带有 BFB 内容的 PXE 安装环境启用 HBN SFC,请使用以下 PXE 配置
bfnet=<IFNAME>:<IPADDR>:<NETMASK> or <IFNAME>:dhcp
bfks=<URL of the kickstart script>
kickstart 脚本 (bash) 应包含以下行
cat
>> /etc/bf.cfg << EOF
ENABLE_BR_HBN=yes
BR_HBN_UPLINKS='p0,p1'
BR_HBN_REPS='pf0hpf,pf1hpf,pf0vf0-pf0vf7,pf1vf0-pf1vf7'
BR_HBN_SFS='pf0dpu1,pf0dpu3'
EOF
上面生成的 /etc/bf.cfg
由 BFB install.sh
脚本源化。
从 BlueField 重新部署 SFC
在 DPU 已经使用 bf.cfg
部署之后,并且需要更改端口映射或网桥配置时,可以从 BlueField 重新部署 SFC。
要从 BlueField 重新部署 SFC
根据需要在每个段中添加或删除条目,编辑
/etc/mellanox/hbn.conf
。重新运行 SFC 安装脚本
/opt/mellanox/sfc-hbn/install.sh -c -r
这将生成一组新的
sfc.conf
和mlnx-sf.conf
并重新加载 DPU。通过删除
-r
选项并在配置后重新启动 BlueField,可以将配置和重新加载分为 2 个步骤。
BlueField 重新加载后,命令 ovs-vsctl show
应显示在 OVS 中配置的所有新端口和网桥。
部署带有其他服务的 HBN
当 HBN 容器单独部署时,BlueField Arm 配置有 3k 个大页。如果与其他服务一起部署,则必须根据这些服务的需求调整大页的实际数量。例如,SNAP 或 NVMesh 可能需要大约 1k 到 5k 个大页。因此,如果 HBN 与这些服务中的任何一个在同一 BlueField 上运行,则大页的总数必须设置为所有服务的大页需求的总和。
例如,如果 NVMesh 需要 3k 个大页,则在与 HBN 一起运行时必须设置 6k 个大页。为此,请将以下参数与其他所需参数一起添加到 bf.cfg
配置文件中。
HUGEPAGE_COUNT=6144
这应仅在运行 32G 内存的 BlueField-3 上执行。在 16G 系统上执行此操作可能会导致 BlueField Arm 上的各种应用程序出现内存问题。
此外,带有其他服务的 HBN 仅适用于 16 个 VF。
HBN 服务容器部署
HBN 服务在 NVIDIA 容器目录 NGC 上可用。有关在 BlueField 之上部署 DOCA 容器的信息,请参阅 NVIDIA DOCA 容器部署指南。
下载 DOCA 容器资源文件
从 NGC 拉取最新的 DOCA 容器资源作为 *.zip
文件,并将其解压缩到 <resource>
文件夹。NGC 中的 DOCA 资源可在此处获取:此处。
运行 HBN 准备脚本
HBN 脚本 (hbn-dpu-setup.sh
) 在 BlueField Arm 上执行以下步骤,这些步骤是 HBN 服务运行所必需的
如果需要,设置接口 MTU。
为日志和配置持久性设置 BlueField Arm 和 HBN 容器之间的挂载点。
设置 supervisord 和容器内部的其他服务所需的各种路径。
如果需要,启用 REST API 访问。
创建或更新凭据
该脚本位于 <resource>/scripts/doca_hbn/<hbn_version>/
文件夹中,该文件夹作为 DOCA 容器资源的一部分下载。
为了在 HBN 的首次启动时实现所需的配置,在运行准备脚本之前,用户可以更新默认的 NVUE 或平面(网络接口和 FRR)配置文件,这些文件位于 <resource>/scripts/doca_hbn/<hbn_version>/
中。
对于基于 NVUE 的配置
etc/nvue.d/startup.yaml
对于基于平面文件的配置
etc/network/interfaces
etc/frr/frr.conf
etc/frr/daemons
运行以下命令以执行 hbn-dpu-setup.sh
脚本
cd
<resource>/scripts/doca_hbn/2.4.0/
chmod
+x hbn-dpu-setup.sh
sudo
./hbn-dpu-setup.sh
以下是 hbn-dpu-setup.sh
脚本的帮助菜单
./hbn-dpu-setup.sh -h
usage: hbn-dpu-setup.sh
hbn-dpu-setup.sh -m|--mtu <MTU> Use <MTU> bytes for
all HBN interfaces (default 9216)
hbn-dpu-setup.sh -u|--username <username> User creation
hbn-dpu-setup.sh -p|--password <password> Password for
--username <username>
hbn-dpu-setup.sh -e|--enable
-rest-api-access Enable REST API from external IPs
hbn-dpu-setup.sh -h|--help
启用 REST API 访问
要启用 REST API 访问
更改
nvidia
用户名的默认密码./hbn-dpu-setup.sh -u nvidia -p <new-password>
启用 REST API
./hbn-dpu-setup.sh --
enable
-rest-api-access执行 BlueField 系统级重置。
生成 HBN 容器
HBN 容器 .yaml
配置称为 doca_hbn.yaml
,它位于 <resource>/configs/<doca_version>/
目录中。要生成 HBN 容器,只需将 doca_hbn.yaml
文件复制到 /etc/kubelet.d
目录
cd
<resource>/configs/2.9.0/
sudo
cp
doca_hbn.yaml /etc/kubelet.d/
Kubelet 会自动从 NGC 拉取容器镜像并生成执行该容器的 pod。DOCA HBN 服务立即开始执行。
验证 HBN 容器正在运行
要检查 HBN 容器并验证其是否正确运行
检查 HBN pod 和容器状态以及日志
检查当前活动的 pod 及其 ID(pod 可能需要长达 20 秒才能启动)
sudo
crictl pods查看当前活动的容器及其 ID
sudo
crictlps
检查给定容器的日志
sudo
crictl logs如果某些内容未按预期工作,请检查 kubelet 日志
sudo
journalctl -u kubelet@mgmt
登录到 HBN 容器
sudo
crictlexec
-it $(crictlps
|grep
hbn |awk
'{print $1;}'
)bash
登录到 HBN 容器后,验证
frr
、nl2doca
和neighmgr
服务是否正在运行(hbn-container)$ supervisorctl status frr (hbn-container)$ supervisorctl status nl2doca (hbn-container)$ supervisorctl status neighmgr
用户还可以检查 HBN 容器内
/var/log
下的各种日志。
HBN 部署配置
HBN 服务带有四种可配置的接口
两个上行链路 (
p0_if
,p1_if
)两个 PF 端口表示器 (
pf0hpf_if
,pf1hpf_if
)用户定义的 VF 数量(即,
pf0vf0_if
,pf0vf1_if
, …,pf1vf0_if
,pf1vf1_if
, …)DPU 接口,用于连接到在 HBN 容器外部的 BlueField 上运行的服务 (
pf0dpu1_if
和pf0dpu3_if
)
*_if
后缀表示这些是子功能,并且与物理上行链路(即 PF、VF)不同。它们可以被视为虚拟化 BlueField 的虚拟接口。
这些接口中的每一个都在 HBN 容器外部连接到相应的物理接口,请参阅“服务功能链”(SFC) 部分,了解更多详细信息。
HBN 容器作为隔离的命名空间运行,并且看不到容器外部的任何接口(oob_net0
、真实上行链路和 PF、*_if_r
表示器)。
仅 HBN 部署配置
这是 HBN 的默认部署模型。在此模型中,仅创建一个 OVS 网桥。
以下是示例 bf.cfg
以及生成的 OVS 和端口配置
示例
bf.cfg
bf.cfg
BR_HBN_UPLINKS=
"p0,p1"
BR_HBN_REPS="pf0hpf,pf1hpf,pf0vf0-pf0vf12,pf1vf0-pf1vf1"
BR_HBN_SFS="svc1,svc2"
生成的
hbn.conf
生成的 hbn.conf
[BR_HBN_UPLINKS] p0 p1 [BR_HBN_REPS] pf0hpf pf0vf0 pf0vf1 pf0vf2 pf0vf3 pf0vf4 pf0vf5 pf0vf6 pf0vf7 pf0vf8 pf0vf9 pf0vf10 pf0vf11 pf0vf12 pf1hpf pf1vf0 pf1vf1 [BR_HBN_SFS] svc1 svc2 [BR_SFC_UPLINKS] [BR_SFC_REPS] [BR_SFC_SFS] [BR_HBN_SFC_PATCH_PORTS] [LINK_PROPAGATION] p0:p0_if_r p1:p1_if_r pf0hpf:pf0hpf_if_r pf0vf0:pf0vf0_if_r pf0vf1:pf0vf1_if_r pf0vf2:pf0vf2_if_r pf0vf3:pf0vf3_if_r pf0vf4:pf0vf4_if_r pf0vf5:pf0vf5_if_r pf0vf6:pf0vf6_if_r pf0vf7:pf0vf7_if_r pf0vf8:pf0vf8_if_r pf0vf9:pf0vf9_if_r pf0vf10:pf0vf10_if_r pf0vf11:pf0vf11_if_r pf0vf12:pf0vf12_if_r pf1hpf:pf1hpf_if_r pf1vf0:pf1vf0_if_r pf1vf1:pf1vf1_if_r svc1_r:svc1_if_r svc2_r:svc2_if_r [ENABLE_BR_SFC] [ENABLE_BR_SFC_DEFAULT_FLOWS]

双桥 HBN 部署配置
以下是示例 bf.cfg
以及生成的 OVS 和端口配置
示例
bf.cfg
bf.cfg
BR_HBN_UPLINKS=
""
BR_SFC_UPLINKS="p0,p1"
BR_HBN_REPS=""
BR_SFC_REPS="pf0hpf,pf1hpf,pf0vf0-pf0vf1,pf1vf0-pf1vf1"
BR_HBN_SFS=""
BR_SFC_SFS=""
BR_HBN_SFC_PATCH_PORTS="tss0"
LINK_PROPAGATION="pf0hpf:tss0"
ENABLE_BR_SFC=yes ENABLE_BR_SFC_DEFAULT_FLOWS=yes生成的
hbn.conf
生成的 hbn.conf
[BR_HBN_UPLINKS] [BR_HBN_REPS] [BR_HBN_SFS] [BR_SFC_UPLINKS] p0 p1 [BR_SFC_REPS] pf0hpf pf0vf0 pf0vf1 pf1hpf pf1vf0 pf1vf1 [BR_SFC_SFS] [BR_HBN_SFC_PATCH_PORTS] tss0 [LINK_PROPAGATION] pf0hpf:tss0 p0:p0_if_r p1:p1_if_r pf0vf0:pf0vf0_if_r pf0vf1:pf0vf1_if_r pf1hpf:pf1hpf_if_r pf1vf0:pf1vf0_if_r pf1vf1:pf1vf1_if_r [ENABLE_BR_SFC] yes [ENABLE_BR_SFC_DEFAULT_FLOWS] yes

混合模式 HBN 部署配置
以下是示例 bf.cfg
以及生成的 OVS 和端口配置
示例
bf.cfg
bf.cfg
BR_HBN_UPLINKS=
"p1"
BR_SFC_UPLINKS="p0"
BR_HBN_REPS="pf1hpf,pf0vf0"
BR_SFC_REPS="pf0hpf,pf0vf1"
BR_HBN_SFS="svc1,svc2"
BR_SFC_SFS="ovn"
BR_HBN_SFC_PATCH_PORTS="tss0"
LINK_PROPAGATION="pf0hpf:tss0"
ENABLE_BR_SFC=yes ENABLE_BR_SFC_DEFAULT_FLOWS=yes生成的
hbn.conf
生成的 hbn.conf
[BR_HBN_UPLINKS] p1 [BR_HBN_REPS] pf0vf0 pf1hpf [BR_HBN_SFS] svc1 svc2 [BR_SFC_UPLINKS] p0 [BR_SFC_REPS] pf0hpf pf0vf1 [BR_SFC_SFS] ovn [BR_HBN_SFC_PATCH_PORTS] tss0 [LINK_PROPAGATION] pf0hpf:tss0 p1:p1_if_r p0:p0_if_r pf0vf0:pf0vf0_if_r pf0hpf:pf0hpf_if_r pf0vf1:pf0vf1_if_r pf1hpf:pf1hpf_if_r svc1_r:svc1_if_r svc2_r:svc2_if_r ovn_r:ovn_if_r [ENABLE_BR_SFC] yes [ENABLE_BR_SFC_DEFAULT_FLOWS] yes

HBN 部署注意事项
SF 接口状态跟踪
当 HBN 与 SFC 一起部署时,以下网络设备的接口状态会传播到其相应的 SF
上行链路 –
p0
、p1
PF –
pf0hpf
、pf1hpf
VF –
pf0vfX
、pf1vfX
,其中X
是 VF 编号
例如,如果 p0 上行链路电缆断开
p0
转换为 DOWN 状态,并带有NO-CARRIER
(Linux 上的默认行为);并且p0
状态传播到p0_if
,其状态也变为 DOWN,并带有 NO-CARRIER
在重新建立 p0
连接后
p0
转换为 UP 状态;并且p0
状态传播到p0_if
,其状态变为 UP
接口状态传播仅发生在从上行链路/PF/VF 到 SF 的方向。
一个名为 sfc-state-propagation
的守护程序在 HBN 容器外部的 BlueField 上运行,以同步状态。该守护程序侦听接口的 netlink 通知并将状态传输到 SF。
SF 接口 MTU
在 HBN 容器中,所有接口的 MTU 默认设置为 9216。可以使用平面文件配置或 NVUE 覆盖特定接口的 MTU。
在 BlueField 侧(即,在 HBN 容器外部),上行链路、PF 和 VF 接口的 MTU 也设置为 9216。可以通过修改 /etc/systemd/network/30-hbn-mtu.network
或在 /etc/systemd/network
中为特定目录添加新的配置文件来更改此设置。
要重新加载此配置,请运行
systemctl restart systemd-networkd
连接到 BlueField Arm 上 HBN 的 DOCA 服务
BlueField Arm 上有各种 SF 端口(名为 pf0dpuX_if
,其中 X 为 [0..n]),可用于在 BlueField 上运行任何服务,并使用 HBN 提供网络连接。这些端口可以具有基于服务名称的灵活命名约定。例如,为了支持 OVN 服务,它可以创建一个名为 ovn
的接口,OVN 服务可以使用该接口在 BlueField Arm 上运行,并且它将获得一个名为 ovn_if
的相应 HBN 端口。这些接口是使用 BR_SFC_SFS
或 BR_HBN_SFS
创建的,具体取决于哪个网桥需要服务接口以及服务部署模式。
当 HBN 侧端口是使用交换机虚拟接口 (SVI) 的 L3 接口或接入端口时,BlueField 和外部世界之间的流量是硬件加速的。因此,从流量处理的角度来看,它的处理方式与 PF 或 VF 端口相同。
默认情况下,在 BlueField Arm 侧创建了 2 个 SF 端口对,因此可以同时运行 2 个单独的 DOCA 服务。
禁用 BlueField 上行链路
上行链路端口必须始终保持管理性启动状态,以确保 HBN 正常运行。否则,NVIDIA® ConnectX® 固件将关闭相应的表示器端口,这将导致数据转发停止。
上行链路的运行状态发生变化(例如,载波丢失)将导致流量切换到另一个上行链路。
当在两个上行链路 SF 上使用 ECMP 故障转移时,本地禁用一个上行链路不会导致流量切换到第二个上行链路。在这种情况下,禁用本地链路意味着直接在 BlueField 上将一个上行链路设置为管理性 DOWN。
要正确测试 ECMP 故障转移场景,必须从其远程对等方禁用上行链路(即,在其连接到上行链路的远程系统的链路上执行管理性 DOWN)。
HBN NVUE 用户凭据
预配置的默认用户凭据如下
用户名 |
|
密码 |
|
可以在安装后添加 NVUE 用户凭据
可以通过向 HBN 启动脚本指定额外的
––username
和––password
来完成此操作(请参阅“运行 HBN 准备脚本”)。例如sudo
./hbn-dpu-setup.sh -u newuser -p newpassword执行此脚本后,重新生成容器或在正在运行的 HBN 容器内启动
decrypt-user-add
脚本supervisorctl start decrypt-user-add decrypt-user-add: started
该脚本在 HBN 容器中创建一个新用户
cat
/etc/passwd |grep
newuser newuser:x:1001:1001::/home/newuser:/bin/bash
HBN NVUE 接口分类
接口 | 接口类型 | NVUE 类型 |
| 上行链路表示器 | swp |
| 上行链路表示器 | swp |
| 环回 | loopback |
| 主机表示器 | swp |
| 主机表示器 | swp |
| VF 表示器 | swp |
| VF 表示器 | swp |
HBN 文件持久性
以下目录从 BlueField Arm 挂载到 HBN 容器命名空间,并在 HBN 服务重启和 BlueField 重新启动之间保持持久性
BlueField Arm 挂载点 | HBN 容器挂载点 | |
配置文件挂载点 |
|
|
|
| |
|
| |
|
| |
|
| |
支持和日志文件挂载点 |
|
|
|
|
HBN 中的 SR-IOV 支持
在主机上创建 SR-IOV VF
使用 SR-IOV 的第一步是在主机服务器上创建虚拟功能 (VF)。
可以使用以下命令创建 VF
sudo
echo
N > /sys/class/net/<host-rep>/device/sriov_numvfs
其中
<host-rep>
是两个主机表示器之一(例如,ens1f0
或ens1f1
)0≤
N
≤16 是所需的 VF 总数设置
N
=0 以删除 0≤N≤16 上的所有 VFN
=16 是 HBN 上所有表示器支持的最大 VF 数
在 BlueField 上自动创建 VF 表示器和 SF 设备
在主机上创建的 VF 必须在 BlueField 侧具有相应的 VF 表示器设备和 SF 设备才能用于 HBN。例如
ens1f0vf0
是来自第一个主机表示器的第一个 SR-IOV VF 设备;此接口是在主机服务器上创建的pf0vf0
是ens1f0vf0
的相应 VF 表示器设备;此设备位于 BlueField Arm 侧,并在用户在主机侧创建ens1f0vf0
的同时自动创建pf0vf0_if
是pf0vf0
的相应 SF 设备,用于将 VF 连接到 HBN 管道
VF 的 SF 设备的创建是在配置 BlueField 并在其上安装 DOCA 镜像时提前完成的,请参阅“启用 SFC”部分,了解如何选择要提前创建多少 SF。
VF 的 SF 设备(即 pfXvfY
)在 VF 表示器与上一步的命令创建时,已预先映射为与相应的 VF 表示器一起工作。
管理 VRF
当 BlueField 与 SFC 一起部署时,会自动为 HBN 配置两个管理 VRF
第一个管理 VRF 在 BlueField 上的 HBN 容器外部。此 VRF 提供带外 (OOB) 流量(通过
oob_net0
或tmfifo_net0
)与通过上行链路和 PF 的数据平面流量之间的隔离。第二个管理 VRF 在 HBN 容器内部,并提供类似的隔离。
eth0
的 OOB 流量与通过*_if
接口的流量隔离。
BlueField Arm 上的 MGMT VRF
当 BlueField 与 SFC 一起部署时,默认情况下启用管理 (mgmt) VRF(请参阅“启用 SFC”部分)。mgmt VRF 提供 OOB 管理网络和带内数据平面网络之间的隔离。
上行链路和 PF/VF 使用默认路由表,而 oob_net0
(OOB 以太网端口)和 tmifo_net0
网络设备使用 mgmt VRF 路由其数据包。
通过 SSH 或控制台登录时,shell 默认处于 mgmt VRF 上下文中。这通过添加到 shell 提示符的 mgmt 来指示
root@bf2:mgmt:/home/ubuntu#
root@bf2:mgmt:/home/ubuntu# ip vrf identify
mgmt.
当使用 crictl
登录到 HBN 容器时,HBN shell 将位于默认 VRF 中。如果需要 OOB 访问,用户必须手动切换到 MGMT VRF。使用 ip vrf exec
执行此操作。
root@bf2:mgmt:/home/ubuntu# ip vrf exec mgmt bash
用户必须运行 ip vrf exec mgmt
才能执行需要 OOB 访问的操作(例如,apt-get update)。
属于 mgmt VRF 的网络设备可以使用 vrf
实用程序列出
root@bf2:mgmt:/home/ubuntu# vrf link list
VRF: mgmt
--------------------
tmfifo_net0 UP 00:1a:ca:ff:ff:03 <BROADCAST,MULTICAST,UP,LOWER_UP>
oob_net0 UP 08:c0:eb:c0:5a:32 <BROADCAST,MULTICAST,UP,LOWER_UP>
root@bf2:mgmt:/home/ubuntu# vrf help
vrf <OPTS>
VRF domains:
vrf list
Links associated with VRF domains:
vrf link list [<vrf-name>]
Tasks and VRF domain asociation:
vrf task exec
<vrf-name> <command
>
vrf task list [<vrf-name>]
vrf task identify <pid>
NOTE: This command
affects only AF_INET and AF_INET6 sockets opened by the
command
that gets exec
'ed. Specifically, it has *no* impact on netlink
sockets (e.g., ip command
).
要显示默认 VRF 的路由表,请运行
root@bf2:mgmt:/home/ubuntu# ip route show
要显示 mgmt VRF 的路由表,请运行
root@bf2:mgmt:/home/ubuntu# ip route show vrf mgmt
HBN 容器内的 MGMT VRF
在 HBN 容器内部,存在单独的 mgmt VRF。可以使用与“BlueField Arm 上的 MGMT VRF”部分下列出的命令类似的命令来查询管理路由。
*_if
接口使用默认路由表,而 eth0
(OOB) 使用 mgmt VRF 将带外数据包路由出容器。OOB 流量通过 BlueField Arm 上的 oob_net0
接口进行 NAT,最终使用 BlueField OOB 的 IP 地址。
当通过 crictl
登录到 HBN 容器时,shell 默认进入默认 VRF 上下文。可以使用命令 ip vrf exec mgmt <cmd>
切换到 mgmt VRF。
BlueField Arm 上 MGMT VRF 中的现有服务
在 BlueField Arm 上,在 HBN 容器外部,一组现有服务在 mgmt VRF 上下文中运行,因为它们需要 OOB 网络访问
containerd
kubelet
ssh
docker
可以使用命令 systemctl
重新启动和查询这些服务的状态,同时将 @mgmt
添加到原始服务名称。例如
要重新启动 containerd
root@bf2:mgmt:/home/ubuntu
# systemctl restart containerd@mgmt
要查询 containerd 状态
root@bf2:mgmt:/home/ubuntu
# systemctl status containerd@mgmt
这些服务的原始版本(不带 @mgmt
)未使用,不得启动。
在 BlueField Arm 上的 MGMT VRF 中运行新服务
如果服务需要 OOB 访问才能运行,则可以将其添加到在 mgmt VRF 上下文中运行的服务集中。添加此类服务只能在 BlueField Arm 上进行(即,在 HBN 容器外部)。
要将服务添加到 mgmt VRF 服务集中
将其添加到
/etc/vrf/systemd.conf
(如果尚未存在)。例如,NTP 已在此文件中列出。运行以下命令
root@bf2:mgmt:/home/ubuntu# systemctl daemon-reload
停止并禁用服务的非 VRF 版本,以便能够启动 mgmt VRF 版本
root@bf2:mgmt:/home/ubuntu# systemctl stop ntp root@bf2:mgmt:/home/ubuntu# systemctl disable ntp root@bf2:mgmt:/home/ubuntu# systemctl enable ntp@mgmt root@bf2:mgmt:/home/ubuntu# systemctl start ntp@mgmt