如何在Tungsten Fabric上整合裸金属服务器（附配置验证过程）

作者：Umberto Manferdini 译者：TF编译组

在数据中心内部，虚拟化正成为占据主导地位的技术。这带来了“虚拟网络”等一些新的管理要素。虚拟网络允许虚拟机在现有的underlay网络（IP Fabric）上，利用软件功能和overlay技术相互通信。

当然，即使在现代数据中心内部，虚拟化也不是唯一的信条。我们仍然有物理设备和裸金属服务器。而且，虚拟机和裸金属服务器通常不是孤立的世界，它们需要彼此集成。

这种集成可能意味着让虚拟机和BMS出现在同一子网中。此解决方案通常称为BMS集成。

原理

利用vRouter对EVPN原生的支持，同时与现有IP Fabric具备互操作性，就可以实现该目标。

与过去涉及附加元素（TSN节点）和协议（OVSDB）的解决方案不同，如今，我们仅依靠标准协议——EVPN。EVPN正在成为数据中心内部事实上的标准。由于SDN控制器可以轻松地与底层IP Fabric集成在一起，并且它们都使用BGP、EVPN和VXLAN，这带来了巨大的优势。

此外，使用标准的和众所周知的协议，可以避免供应商锁定，向多供应商的场景开放。

以终为始，这就是我们想要实现的目标：

一个经典的局域网！

实际上，在这种简单的网络模型背后，许多参与者都扮演着角色并发挥自己的作用。

这是真实的场景：

让我们一次解决一个问题。

首先，我们的DC具有标准IP Fabric。对于标准，我们是指使用VXLAN进行传输的基于BGP的结构。Overlay BGP用于交换EVPN路由。为了减少BGP会话的数量，将spine用作路由反射器，从而避免leaf-to-leaf的全连接。

Tungsten Fabric（注：原文为Contrail，本文以功能一致的Tungsten Fabric替换）部署在数据中心内。Tungsten Fabric overlay网络（通常称为Tungsten Fabric控制+数据网络）将映射到在Fabric上配置的VLAN（L2服务）。在RHOSP实现中，此网络通常映射到RHOSP租户网络。这意味着每个Tungsten Fabric节点将在此网络上有一个IP。具体来说，计算节点在该网络上将具有接口vhost0（VTEP接口）。

Tungsten Fabric控制+数据网络（在RHOSP环境中为Tenant网络）在Fabric上具有配置为IRB接口的网关。在这种情况下，IRB配置在spine上。这两个spine共享一个相同的IP地址，称为VGA，用作LAN网关。

在spine配置IRB的模型，称为中央路由桥接（CRB）。还有一种情况，我们可以将L3 GW功能（IRB接口）移到leaf上，这样该模型就称为边缘路由桥接（ERB）。CRB与ERB的比较不在本文讨论范围之内。

Tungsten Fabric控制节点与IP Fabric spine之间具有BGP会话，在此会话上交换EVPN路由。这使IP Fabric可以学习Tungsten Fabric EVPN路由，反之亦然。这是实现BMS集成的关键，因为我们需要BMS相关的EVPN路由才能到达Tungsten Fabric，同时需要Tungsten Fabric虚拟机EVPN路由才能到达与BMS连接的leaf。

裸金属服务器是多宿主到一对leaf，并映射到IP Fabric上的VLAN。

另一方面，虚拟机连接到由Tungsten Fabric管理的L2虚拟网络。

为了实现BMS集成，需要使用BMS所属的L2 VLAN来“缝合”L2虚拟网络。

这是通过利用Tungsten Fabric的EVPN原生支持以及其与IP Fabric的集成来实现的。稍后我们将进行详细介绍。

配置

IP Fabric必须正确配置。我们假设Tungsten Fabric集群已经启动并正在运行，那么Tungsten Fabric基础结构网络（RHOSP网络）已经就位。我们还假定Tungsten Fabric控制器已建立好启用了EVPN族的spine的BGP会话。

剩下的就是创建BMS VLAN和与EVPN相关的配置。

由于我们不希望在“扩展的2层网络”上使用网关，因此不需要设置IRB逻辑接口。其结果是，配置仅涉及BMS连接到的两个leaf。在这种情况下，spine将仅接收/通告EVPN路由并转发overlay流量（VXLAN数据包）。

两个leaf上的配置是相同的，因此我只演示一次。

首先，我们配置针对BMS的聚合接口：

这是带有一些额外“调整（tweaks）”的标准AE接口。我们定义了两个leaf上都必须匹配的ESI，为了使用EVPN管理多宿主这是必须的。然后，我们还需要两个leaf上的LACP系统ID匹配。这是“欺骗”BMS所必需的；如果在两个链接上的系统ID相同，即使实际上在另一侧有两个不同的设备（leaf），BMS也将假定它已连接到单个系统。同样，这是在启用EVPN的DC中配置多宿主的标准最佳实践。

接下来，我们转到EVPN部分。

我们需要一个新的VNI：

VNI被分配了route target（实现BMS集成的关键参数）。Leaf EVPN策略必须进行更新以反映新服务（service）。

最后，添加一个新的VLAN：

作为可选项，可以通过在overlay BGP会话上向spine添加route target，来优化EVPN路由交换：

这对于leaf（和IP Fabric）的配置来说，已经足够了。

如果需要用作LAN网关的IRB接口，则在spine设备上还需要一些其它配置。

BMS配置非常简单。

BMS可以是我们想要的任何设备；例如，支持绑定的Centos服务器。

不过，这里我用了Juniper MX。以下代码行已加载到设备上：

接口被分配给虚拟路由器，以便在路由方面将其与设备的其余部分隔离。

Tungsten Fabric配置涉及多个方面。

如前所述，我们假设Tungsten Fabric控制器和IP Fabric spine之间的BGP会话已经存在。

可以通过在Tungsten Fabric GUI中检查BGP路由器来验证这一点：

重要的是EVPN族被启用。

接下来，我来创建一个虚拟网络：

虚拟网络是2层的，因为其转发模式仅设置为L2。

提供了一个VNI，5123不是一个随机值。如果您还记得，那是我之前在leaf上配置的值。为了从overlay数据平面的角度缝合Tungsten Fabric和IP Fabric，这是必不可少的。

如先前所预期的，另一个关键值是route target。这与在fabric上设置的相同。这样，我们可以确保将fabric中的EVPN BGP路由，按预期导入到Tungsten Fabric虚拟网络中，反之亦然。

虚拟网络也被分配了CIDR。由于“历史原因”，该网络地址的存在是因为Openstack/Neutron需要在每个网络上配置CIDR。实际上，作为仅为L2的VN，Tungsten Fabric没有针对该对象的L3（inet）路由表，只有MAC表。这意味着我们可以在虚拟机内部配置所需的任何IP地址。在vRouter级别仅检查MAC地址一致性就可以（也就是说，不要更改虚拟机上的MAC地址）。

在此虚拟网络上，我们连接两个虚拟机，因此该网络上有两个端口：

每个端口都有自己的MAC地址。这些MAC地址很重要，因为它们将被通告到EVPN中。

MAC地址应该在虚拟网络EVPN表中可见：

BGP和XMPP路由都存在（每个MAC地址2个路由，每个协议1个路由）。

请注意，VNI等于5123。

现在，一切准备就绪，BMS集成应该已经完成。

验证

下面该进行验证了！

在BMS上，我记下了集成接口的MAC：

在这里，我假设到处都配置了route target。

我检查在leaf（连接到BMS）和spine之间是否相互交换route target：

1{master:0}[edit]
2netconfadmin@nfv-vb-leaf-08# run show route receive-protocol bgp 172.16.118.162 table bgp.rtarget.0 | match 2222
3  64520:64520:2222/96
4
5{master:0}[edit]
6netconfadmin@nfv-vb-leaf-08# run show route advertising-protocol bgp 172.16.118.162 table bgp.rtarget.0 | match 2222
7  64520:64520:2222/96

可以在另一个leaf上进行相同的检查。

然后，我将验证在spine和Tungsten Fabric控制器之间交换了相同的路由目标：

1{master:0}[edit]
2netconfadmin@nfv-vb-spine-01# run show route advertising-protocol bgp 163.162.83.205 table bgp.rtarget.0 | match 2222
3  64520:64520:2222/96
4
5{master:0}[edit]
6netconfadmin@nfv-vb-spine-01# run show route receive-protocol bgp 163.162.83.205 table bgp.rtarget.0 | match 2222
7  64520:64520:2222/96

可以在第二个spine上进行相同的操作。

一旦知道route target交换正常，就可以转到实际的MAC路由。

从学习了BMS MAC的leaf中，我将检查EVPN T2路由是否已发送到spine：

1{master:0}[edit]
2netconfadmin@nfv-vb-leaf-08# run show route advertising-protocol bgp 172.16.118.162 table bgp.evpn.0 evpn-ethernet-tag-id 5123 match-prefix 2*
3
4bgp.evpn.0: 1087 destinations, 1979 routes (1087 active, 0 holddown, 0 hidden)
5  Prefix                  Nexthop              MED     Lclpref    AS path
6  2:172.16.118.170:1::5123::88:e0:f3:b3:1f:c0/304 MAC/IP
7*                         Self                         100        I
8  2:172.16.118.170:1::5123::88:e0:f3:b3:1f:c0::100.64.1.100/304 MAC/IP
9*                         Self                         100        I

是的，它们在那里！MAC和MAC/IP路由。

该路由应从spine发送到Tungsten Fabric：

1{master:0}[edit]
2netconfadmin@nfv-vb-spine-01# run show route advertising-protocol bgp 163.162.83.205 table bgp.evpn.0 evpn-ethernet-tag-id 5123 match-prefix 2:172*
3
4bgp.evpn.0: 4242 destinations, 7157 routes (4242 active, 0 holddown, 0 hidden)
5  Prefix                  Nexthop              MED     Lclpref    AS path
6  2:172.16.118.170:1::5123::88:e0:f3:b3:1f:c0/304 MAC/IP
7*                         172.16.118.170               100        I
8  2:172.16.118.170:1::5123::88:e0:f3:b3:1f:c0::100.64.1.100/304 MAC/IP
9*                         172.16.118.170               100        I

路由就在那里！

结果就是，我们在Tungsten Fabric虚拟网络MAC表中找到了MAC信息：

下一跳是连接到BMS的leaf的VTEP地址（设计上是环回地址），该leaf学习了BMS MAC并通告了类型2。

此路由交换总结如下：

请注意，最后一步使用XMPP，因为它是Tungsten Fabric控制器和计算节点之间使用的协议。

当然，另一个leaf也可能会通告T2路由，这取决于它是否在本地学习MAC。

现在，我将检查从Tungsten Fabric到leaf的路由。

在Spine上，我将检查是否从Tungsten Fabric控制器收到了VM的MAC路由：

1{master:0}[edit]
2netconfadmin@nfv-vb-spine-01# run show route receive-protocol bgp 163.162.83.205 table bgp.evpn.0 evpn-ethernet-tag-id 5123
3
4bgp.evpn.0: 4232 destinations, 7137 routes (4232 active, 0 holddown, 0 hidden)
5  Prefix                  Nexthop              MED     Lclpref    AS path
6  2:163.162.83.222:7::5123::d0:f0:db:00:00:01/304 MAC/IP
7*                         163.162.83.222       200     100        ?
8  2:163.162.83.232:4::5123::d0:f0:db:00:00:02/304 MAC/IP
9                          163.162.83.232       200     100        ?
10  3:163.162.83.222:7::5123::163.162.83.222/248 IM
11*                         163.162.83.222       200     100        ?
12  3:163.162.83.232:4::5123::163.162.83.232/248 IM
13                          163.162.83.232       200     100        ?

有4个路由（2个MAC，2个MAC/IP）；这是因为有2个虚拟机。请注意虚拟机使用的IP。如果您还记得，我们确实在VN内配置了CIDR 99.99.99.0/24。无论如何，如前所述，作为L2 VN，我们可以在VM内配置所需的任何IP（但是我们需要保持MAC地址不变，这超过了本文的范围）。

从那里，路由一定会到达leaf：

1{master:0}[edit]
2netconfadmin@nfv-vb-leaf-07# run show route receive-protocol bgp 172.16.118.162 table bgp.evpn.0 evpn-ethernet-tag-id 5123
3
4bgp.evpn.0: 1088 destinations, 1713 routes (1088 active, 0 holddown, 0 hidden)
5  Prefix                  Nexthop              MED     Lclpref    AS path
6  2:172.16.118.170:1::5123::88:e0:f3:b3:1f:c0/304 MAC/IP
7                          172.16.118.170               100        I
8  2:172.16.118.170:1::5123::88:e0:f3:b3:1f:c0::100.64.1.100/304 MAC/IP
9                          172.16.118.170               100        I
10  3:172.16.118.170:1::5123::172.16.118.170/248 IM
11                          172.16.118.170               100        I

是的，都在那里！

结果就是，在leaf上，以太网表应反映以下内容：

1netconfadmin@nfv-vb-leaf-07# run show ethernet-switching table vlan-name VLAN-BMSINT
2
3MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent static
4           SE - statistics enabled, NM - non configured MAC, R - remote PE MAC, O - ovsdb MAC)
5
6
7Ethernet switching table : 3 entries, 3 learned
8Routing instance : default-switch
9   Vlan                MAC                 MAC      Logical                Active
10   name                address             flags    interface              source
11   VLAN-BMSINT         88:e0:f3:b3:1f:c0   DR       ae90.123
12   VLAN-BMSINT         d0:f0:db:00:00:01   D        vtep.32778             163.162.83.222
13   VLAN-BMSINT         d0:f0:db:00:00:02   D        vtep.32779             163.162.83.232

BMS MAC只有一个条目。标志DR的意思是“远程（remote）”。这告诉我们MAC实际上是由另一个leaf学习的。

另外两个路由指向虚拟机。

转发接口是VTEP IFL。当数据包必须封装到VXLAN隧道中时，使用接口VTEP。最右边的值是VTEP目标地址：在这种情况下，是托管VM的计算节点的vhost0地址。

这里也可以看到：

1netconfadmin@nfv-vb-leaf-07# run show interfaces vtep.32778
2  Logical interface vtep.32778 (Index 947) (SNMP ifIndex 1085)
3    Flags: Up SNMP-Traps Encapsulation: ENET2
4    VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 163.162.83.222, L2 Routing Instance: default-switch, L3 Routing Instance: default
5    Input packets : 0
6    Output packets: 4
7    Protocol eth-switch, MTU: Unlimited
8      Flags: Trunk-Mode

虽然我们没有提到，但是与类型2路由类似，EVPN类型1路由也完成了交换。这意味着可以使用诸如aliasing之类的原生EVPN机制，并且Tungsten Fabric可以利用它。

就是这个！BMS集成已经实现了，VM可以与BMS通信，反之亦然。

分析

让我们看一下流量的路径。

我分析了VM到BMS的用例，但对BMS到VM的用例也进行了同样的考虑。

下图总结了所有阶段：

首先，VM发送目标为BMS IP的IP/Ethernet数据包。

数据包到达在其MAC表中执行查找的vRouter（请记住，虚拟网络仅是L2）。从那里，它匹配从spine接收到的BGP路由，将原始数据包封装到发往BMS多宿主的leaf的VXLAN标头中。

使用虚拟网络内部配置的VNI（5123）将数据包封装在VXLAN中。计算节点执行IP查找，以了解如何达到leaf环回。该查找在“常规”服务器路由表（在“ip route”中看到的表）中进行。当然，必须有一条通往leaf环回的路由。这些路由可以手动添加（从而可以永久生效），也可以在Tungsten Fabric安装过程中进行设置（使用RHOSP可以在NIC模板级别完成）。

查找应告知必须将数据包发送到Tungsten Fabric的控制+数据（RHOSP租户网络）网关。此地址是在spine上配置的IRB。

此时，VXLAN数据包作为目标MAC地址为IRB（租户网络网关）MAC的以太网帧离开计算节点。数据包到达与RHOSP租户网络关联的逻辑接口上的“本地”leaf上。MAC查找此时发生，并且leaf发现必须将数据包封装在发往spine的VXLAN隧道中。这时，VNI与Fabric中的RHOSP租户的VLAN（此处未显示）关联。是的，另一个VXLAN隧道。在leaf和spine之间，我们有一个由计算节点创建的VXLAN数据包，该数据包封装到由leaf创建的另一个VXLAN数据包中。

“双重封装”的VXLAN数据包到达了spine。Spine发现到目标MAC是其拥有的MAC（IRB MAC）；它解封装外部VXLAN标头并执行IP查找。查找针对内部VXLAN数据包目标地址，即leaf环回。该地址是可用的，这要归功于IP Fabric的underlay路由交换。Spine只是将数据包转发到连接BMS的leaf上。

VXLAN数据包到达leaf。Leaf基于VN（5123）对其进行解封装，并将数据包放入BMS vlan（123）。MAC查找在此时发生，并且找到了BMS si的匹配项。

最后，根据leaf和BMS之间的VLAN标记配置的原始IP数据包，将被发送到原始目的地！

我们终于到达了BMS。

这段漫长的旅程涉及到两个overlay：由VXLAN隧道compute-to-leaf表示的Tungsten Fabric overlay，以及由VXLAN隧道leaf-to-spine表示的fabric overlay。

这里比较复杂，但是从用户的角度来看，它看起来确实像是BMS和VM在同一子网中。

关于复杂性……真的有那么复杂吗？

某些配置可以看作是“day 0”，就是在设置DC时只需配置一次。这包括针对spine和IP Fabric EVPN overlay的Tungsten Fabric BGP会话。

随后，实现BMS集成就相当容易了。

在Tungsten Fabric上，我们只需要一个L2 VN。在fabric上，我们只需要标准的L2服务。

重要的是VNI和router target匹配，以便允许正确的路由导入。

以上，就是关于Tungsten Fabric虚拟网络的BMS部分的分享。

原文链接：
https://iosonounrouter.wordpress.com/2019/11/21/bare-metal-integration-in-a-contrail-world/

如何在Tungsten Fabric上整合裸金属服务器（附配置验证过程）相关推荐

服务器信息 sid,裸金属服务器SID配置
裸金属服务器SID配置内容精选换一换 Linux裸金属服务器的静态主机名来源于创建裸金属服务器时,通过控制台注入的用户自定义名称.可以使用控制台或hostname命令更改裸金属服务器的主机名,但如 ...
裸金属服务器（Bare Metal Server，BMS）
裸金属服务器(Bare Metal Server,BMS) 参考: https://support.huaweicloud.com/wtsnew-bms/index.html 裸金属服务器(Bare ...
【裸金属服务器学习笔记】
文章目录一.什么是裸金属服务器? 二.裸金属服务器和物理机.虚拟机等,有哪些区别和联系? 三.裸金属服务器的适用客户群体四.裸金属服务器的关键技术五.裸金属服务器有哪些限制? 参考文档一.什么 ...
文档服务器备份策略,裸金属服务器创建备份策略
裸金属服务器创建备份策略内容精选换一换为了保证数据安全,您可以对裸金属服务器中的所有云硬盘(系统盘和数据盘)进行备份,采用这种备份方式可以避免因备份创建时间差带来的数据不一致问题.云服务器备份支 ...
一起来看看华为云的裸金属服务器
裸金属服务器是什么? 裸金属服务器的英文名是Bare Metal Server,BMS.其实就是一台物理服务器,没错就是它: 什么叫裸金属服务器呢? 其实这个名称是在公有云服务中出现的,公有云中如果提 ...
华为服务器检索信息,裸金属服务器使用标签检索资源
裸金属服务器使用标签检索资源内容精选换一换为云资源添加标签后,您可以通过本文所述的两种方法使用标签检索资源.在裸金属服务器列表页,您可以按"标签键+标签值"搜索目标裸金属服务 ...
阿里云弹性裸金属服务器常见问题汇总
查看全文 http://www.taodudu.cc/news/show-2742736.html 相关文章: 华为v5服务器安装2012系统,裸金属服务器安装v5 裸金属服务器能虚拟化吗,市场需求多 ...
虚拟机vs裸金属服务器,裸金属虚拟机
裸金属虚拟机内容精选换一换您可以基于裸金属服务器实例创建私有镜像,将实例的系统盘数据完整地复制到私有镜像中.系统盘一般包含用户运行业务所需的操作系统.应用软件.只有系统盘为云硬盘时,才支持此操作 ...
IBM Cloud：裸金属服务器+多云策略助力音视频解决方案成功出海
点击上方"LiveVideoStack"关注我们到底什么是公有云.私有云和混合云?疫情给云服务厂商带来了哪些挑战?IBM是如何助力音视频解决方案成功出海的?"后疫情&q ...
【裸金属服务器】安装VMware ESXi
官方安装操作ESXi地址一.虚拟化服务器分类: 寄居架构(Hosted Architecture)和裸金属架构(Bare Metal Architecture). 1.寄居架构(Hosted Arc ...

如何在Tungsten Fabric上整合裸金属服务器（附配置验证过程）

原理

配置

验证

分析

如何在Tungsten Fabric上整合裸金属服务器（附配置验证过程）相关推荐

最新文章

热门文章