作者：大峰

运营商服务中心

自IP网络问世以来，私有协议、feature（如组播VXLAN等）便是武林各门派决战光明顶的至胜法宝，令各路门派望而却步，备感无力。

然而，狭路相逢，面对着客户现网布下的看似无坚不摧的“铁桶阵”（组播VXLAN），就真的一点“破绽”都没有么？真的无计可施了么？

对不起，我摊牌了。我们也可以做到通过组播方式实现VXLAN了！

下面就根据实际测试经验与大家进行分享。

一、 内功心法——VXLAN基础回顾

VXLAN采用MAC in UDP封装方式的一种隧道技术，通过对原始IP报文增加VXLAN报头，实现对虚拟机数据报文隔离、虚拟机动态迁移、大二层网络等需求。以下为VXLAN报文格式：

图一（以外层IP头为IPv4格式为例）

其数据封装及转发过程如下：

图二

虚拟机发出的原始IP报文，到达TOR设备后增加VXLAN报头，并在VXLAN隧道进行转发，到达目标TOR设备解除VXLAN封装后得到原始IP报文，最后到达目标虚拟机。

当然这是针对已知单播报文的数据转发流程。如果涉及BUM（Broadcast, Unknown-unicast, Multicast）报文处理，不同派系实现方式就有所不同了。在此演变成两大派系，第一个派系是几乎已失传的“组播路由”派系，第二大派系为武林公认的“头端复制”派系。而“组播路由”派系出现的场景无人能敌。

那么，两大派系招数有什么不同？我们又是如何完成两个派系秘籍的修炼，顺利破除客户现网“铁桶阵”的呢？别急，听我娓娓道来。

二、“头端复制”主流派系

 使用图二拓扑进行扩展对BUM报文“头端复制”过程进行讲解。

图三

如图三所示，假设VM1（所属VNI10099）需要与VM2(所属VNI10099)进行通信。在VM1上进行原始数据报文封装时缺少目标VM2的mac地址信息，于是VM1将向所属局域网发送ARP请求（目标MAC为全F）。TOR1在接收到VM1所发送的ARP请求后。TOR1根据头端复制列表将其转为单播方式，将ARP请求报文复制后并增加VXLAN报头向TOR3以单播方式进行发送，这就是对BUM帧简单的头端复制过程。

图四（依赖EVPN构建头端复制列表）

是不是觉得与传统局域网中ARP广播请求实现方式有所差异？在传统局域中ARP请求通过广播方式在局域网内泛洪，占用局域网内大量带宽资源。但在云数据中心里，大二层局域网是通过VXLAN隧道构建，存在海量虚拟机，大量ARP广播报文通过VXLAN隧道进行广播，将极大的增加云数据中心TOR设备压力，消耗TOR设备链路及自身资源。

三、几乎失传的“组播路由”派系

接下来讨论稍微复杂一点、几乎已失传的“组播路由”派系。再次对图二进行扩展，在组网中增加单独RP，使用S65系列（version S6500_RGOS 12.5(1)B0401S1）作为TOR设备。

图五

如图五所示，VM1与VM2均属于VNI 10099，且将VNI 10099加入组播组226.2.1.1后，设备将生成VNI与组播组绑定表项，如：

图六

假设VM1需要与VM2进行通信。VM1依旧向所在局域网发送ARP广播请求（目标MAC为全F）。TOR1在接收到VM1所发送的ARP请求后，在原始ARP请求报文增加VXLAN封装后，根据已形成的组播路由表项，将ARP请求报文以组播复制方式转发到TOR2。TOR2最终将VXLAN报头解封装后，将原始ARP报文送到VM2。

图七

与”头端复制“实现方式不同，组播方式实现需要依赖PIM协议构建的组播树，并将相应VXLAN与组播组进行绑定，形成VXLAN报文转发路径，大致配置如下 ：

!
ip multicast-routing  # 启用组播路由协议
!
interface TFGigabitEthernet 0/48
 port speed-mode 10G
 no switchport
 ip address x.x.x.x 255.255.255.0
 ip ospf network point-to-point   
 ip pim sparse-mode   # 在该端口启用组播协议，并配置为稀疏模式
!
...其他常规配置略
!
interface OverlayRouter 10099
 vrf forwarding xxx
 ip address 10.253.129.126 255.255.255.128
 anycast-gateway
!
vxlan 10099
 router-interface OverlayRouter 10099
 mcast-group 226.2.1.1  # 将二层vni与组播组进行绑定
 extend-vlan 1099
!
ip pim bidir-enable   # 配置双向组播功能
ip pim rp-address 192.169.122.34 bidir  # 指定组播RP
!
S6510_VSU#show vxlan 10099
VXLAN 10099
    Symmetric property  : FALSE
    Router Interface    : overlayrouter 10099 (anycast)
    Extend VLAN         : 1099
    VTEP Adjacency Count: 1
    VTEP Adjacency List :
    Interface              Source IP        Destination IP             Type
    --------------------- -------------- ---------------------- -------
    OverlayTunnel 12287    1.1.1.1          226.2.1.1               dynamic

虽然以组播方式进行BUM报文效率较高，但进行VXLAN扩展时会带来更大挑战。例如，数据中心中大量不同VXLAN配置在同一组播组，将导致部分TOR设备接收大量自身并不感兴趣的BUM流量。但假如所有不同的VXLAN配置不同的播组，那么每台TOR将需要维护大量组播树与组播路由表项，这也会让TOR设备感觉到压力山大。

明白了吧，两大门派招数各有见长，能够集百家之长并不断修炼，才是武功的最高境界！

VXLAN为当前云数据中心提供了强大的大二层网络技术支持，但由于其硬件方面限制，在实现方式上会存在较大差异。各位同仁在日常项目交付时，经常接触到“头端复制”方式的BUM报文处理机制，可以说是再熟悉不过了。但组播VXLAN实现方式也占据了数据中心大半江山，为了突破无坚不摧的“铁桶阵”，我们还需多多学习组播心法。