网安融合 专业防护更简单,RG-WALL1600-CF系列防火墙线上发布会
预约直播
产品
< 返回主菜单
产品中心
产品

交换机

交换机所有产品
< 返回产品
交换机主页
交换机

无线

无线所有产品
< 返回产品
无线主页
无线

云桌面

云桌面产品方案中心
< 返回产品
云桌面主页
云桌面

安全

安全所有产品
< 返回产品
安全主页
安全

带你了解几乎已失传的组播VXLAN派系|运维实战家

发布时间:2021-07-08

作者:大峰

运营商服务中心

自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实现方式也占据了数据中心大半江山,为了突破无坚不摧的“铁桶阵”,我们还需多多学习组播心法。

关注锐捷
关注锐捷官网微信
随时了解公司最新动态

返回顶部

收起
请选择服务项目
关闭咨询页
售前咨询 售前咨询
售前咨询
售后服务 售后服务
售后服务
意见反馈 意见反馈
意见反馈
更多联系方式
是否找到您想要的内容?
您遇到了什么问题?
找不到想要的信息
筛选功能不好用
加载速度太慢
页面体验差
提交
您是否找到了与产品相关的文档
筛选功能是否帮助您更快找到所需的文档?
有帮助
一般
没有帮助
没用过
请问您遇到了什么问题?
需要填写的内容太多
有些信息不懂怎么填
页面有问题/错误
其他
确定
这些客户案例是否对您有帮助?
非常有帮助
比较有帮助
没有帮助
请您对这个客户案例进行评价
兴趣度
相关性
可信度
确定
感谢您的反馈!
感谢您的反馈!