产品
产品中心
< 返回主菜单
产品

交换机

交换机所有产品
< 返回产品
交换机
查看交换机首页 >

无线

无线所有产品
< 返回产品
无线
查看无线首页 >

云桌面

云桌面产品方案中心
< 返回产品
云桌面
查看云桌面首页 >

安全

安全所有产品
< 返回产品
安全
查看安全首页 >
产品中心首页 >
行业
行业中心
< 返回主菜单
行业
行业中心首页 >

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

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

返回顶部

请选择服务项目
关闭咨询页
售前咨询 售前咨询
售前咨询
售后服务 售后服务
售后服务
意见反馈 意见反馈
意见反馈
更多联系方式