＂鹅厂网事＂由深圳市腾讯计算机系统有限公司技术工程事业群网络平台部运营，我们希望与业界各位志同道合的伙伴交流切磋最新的网络、服务器行业动态信息，同时分享腾讯在网络与服务器领域，规划、运营、研发、服务等层面的实战干货，期待与您的共同成长。

网络平台部以构建敏捷、弹性、低成本的业界领先海量互联网云计算服务平台，为支撑腾讯公司业务持续发展，为业务建立竞争优势、构建行业健康生态而持续贡献价值！

背景介绍

随着腾讯业务的快速发展，腾讯网络所承载的流量也在成倍的增长，网络容量从早年的10G快速增长到100G，1T，10T甚至更大。受制于网络技术的发展和成本的考虑，当前网络端口容量主要还是以10G为主，近两年腾讯也逐步开始使用了100G端口，但是单端口容量的增长，仍远远无法满足腾讯对带宽的需求，所以多链路捆绑，路由ECMP等技术，在腾讯网络中大量使用。链路数量的的增加在提升网络容量的同时，也对网络运营带来了很多问题。记得早年刚开始接触网络的时候，曾经很简单的理解1条10G链路与10条1G链路捆绑在一起是等同的，但在工作中慢慢发现，流量并不会完全均匀的分布在10条链路上，这里涉及到多路径hash问题，接下来简单介绍下腾讯数据中心网络中多路径hash遇到的几种常见问题。

一hash极化问题

某日，腾讯网络监控发现，LC（IDC内网核心设备）到MAN（城域网设备）的一条链路带宽撑爆了，排查发现，LC-1到MAN-1的带宽已满，而LC-1到MAN-2的链路几乎没有流量，查看LC的路由表，转发表等都没有异常，最后定位是hash极化问题造成的。

什么是hash极化呢？

以下图为例，在这个故障案例中，腾讯IDC网络的L交换机（三层接入设备）和LC交换机使用的是同一个型号的设备，并使用了相同的hash算法，对于L交换机来说，有四个不同的流，其中流1,2选择了左边的链路，到达了LC-1设备。由于LC-1和L的hash算法完全相同，所以在做hash时，LC1将流1,2归为了同一类，都选择了左边的链路进行转发。

下图场景中也可能存在hash极化问题。当某一设备的ECMP条目数与lacp捆绑链路数一致的情况，如果hash算法一样，算出的结果一致，lacp上面的流量会由于hash极化而集中到其中的一条链路上。

为了避免hash极化问题，在网络设计时，需要注意以下几点：

1 多台同厂商设备级联情况

1. 避免在级联的设备中相邻的2台使用相同的负载均衡算法
2. 当前部分厂商设备在hash计算时候，除传统的五元组外，可以增添其他因子参与计算，避免hash计算结果相同的情况

2 一台设备同时进行ECMP和LACP负载情况

1. 注意ecmp总数量和每个lacp的链路数量是否存在比例对应关系，判断是否可能出现极化现象
2. 尽量保持ecmp和lacp的负载均衡算法不一致，避免出现极化现象

注:MAN（Metropolian Area Network）：城域网LC(LAN Core)：内网核心

二 hash算法选择问题

对于网络设备的hash算法，可以基于五元组+源目mac地址进行任意组合，通常我们都会选择基于源目IP加源目端口的方式进行hash，因为这样参与hash计算的因子较多，流量在多条链路上的均衡性较好。但是在有些场景下，需要设置特定的hash算法。

以腾讯LVS专区网络为例，LVS交换机从LD（负载均衡）学习到同一目标地址的等价的路由。LVS交换机收到数据后，会根据hash算法，将数据转发到负载均衡设备，再由LD将数据转发到后端具体负责业务处理的服务器上。对于部分业务，例如支付类的业务，同一个用户的一次支付过程会调用多个业务服务，业务侧要求一次支付的过程都落在同一个处理服务器上，也就是一个源目的ip的会话必须hash到同一台LD进行转发。

在早期的网络设计中，LVS交换机的hash算法是基于源目IP+协议端口进行计算的，由于目标协议端口在交互过程中可能发生变化，导致了部分业务的异常。在此场景中，LVS交换机的hash算法确定为基于源目IP，确保同一个源目IP数据流，只会被转发到同一台LD上。

三Overlay网络中的hash问题随着云网络的快速发展，网络虚拟化技术已经越来越多的在腾讯网络中应用，当前主流技术是基于overlay的网络。

如图所示，子机用户访问外部网络时，母机在子机发出的原始报文外层又添加了一层新的IP包头，在某些情况，由于子机发出的报文过大，再添加一个新的IP包头后，报文超过了母机网卡MTU的大小，这时母机会对该报文进行分片，分成了如图所示的两个报文。

对于第一个报文，由于报文包含了两层IP包头，部分网络设备在进行hash计算时，会基于内外层包头一起计算，于是分片报文被转发到了不同的LD设备，导致业务失败。

针对此类问题，当前主要有以下三种解决方案：1）调整子机网卡MTU大小，避免母机二次封装后报文过大而造成分片；

2）修改业务逻辑，母机收到较大的子机报文后，先对报文进行分片，再进行外层封装；

3）调整网络设备只基于外层包头进行hash，而不考虑内层IP包头。

对于方案三，当前并不是所有厂商设备都支持，考虑到后续类似场景会越来越多，目前腾讯对新引入的设备，要求能够支持此特性。

后续展望Hash结果可视化

当前网络运营的一大痛点在于，当业务反馈数据转发存在异常时，由于网络中存在海量节点，链路，导致无法快速定位到故障点，根本原因，就在于很难知道异常流量，承载在那条路径上。目前大多数网络设备对于流量hash的结果，都是不可视的，如果能够实现hash计算结果可视化，那么任何一条流量的转发路径，我们就可以非常清楚的知道，故障处理起来，将变得轻松容易很多。

Hash计算的动态均衡化

当前网络设备的hash算法主要还是基于数据流的五元组进行hash的，在很多场景下，数据流量还是没法在多条链路间做到较为均匀的转发。如果在hash计算时，能够将当前链路流量大小也做为hash计算的一个因素，将极大提升链路的利用率。

注1：凡注明来自“鹅厂网事”的文字和图片等作品，版权均属于“深圳市腾讯计算机系统有限公司”所有，未经官方授权，不得使用，如有违反，一经查实，将保留追究权利；

注2：本文图片部分来至互联网，如涉及相关版权问题，请联系judithliu@tencent.com。