混合云模式下网络问题排查思路（MTU、IDC安全设备及安全策略）
MTU相关概念及原理说明：
首先说明MTU相关的概念及数据处理逻辑：
以太网的帧格式分为以下几部分：
- 目的地址：6字节
- 源地址：6字节
- 类型：协议类型：IP，ARP，RARP
- 数据：46-1500字节
- CRC：循环冗余验证
MTU：Maximum Transmission Unit 最大传输单元，是网络传输中数据包的最大传输长度，一般使用字节为单位，以太网常用MTU=1500
MTU对于IP协议的影响：
由于数据链路层MTU的限制，对于超过1500的IP数据包的进行分片（分包），将较大的IP包拆分为多个小包，并给每个小包打上标签，数据接收端需要对这些分片拆分的小包进行重新重组才能进行正常的数据处理，如果传输或者接收端出现仁医一个小包丢失，接收端就无法对数据重组，会出现传输超时的问题。（核心关注加粗部分内容，后续几个case均与此有关）
真实案例及排查过程：
案例1：客户IDC与腾讯云接通专线后，在测试专线联通性的过程中通过wget文件的方式进行测试，发现只要超过1228字节的文件就不能下载成功。从IDC wget腾讯云上CVM的文件
排查思路及过程：
1、由于客户已经定位到跟传输的文件大小有关，初步怀疑是整个传输链路中客户端及设备的MTU协商有问题
2、在两端客户端侧抓包分析，发现分片数据无法合为大包
3、腾讯云侧MTU改为1400，发现传输ok，怀疑中间链路设备可能存在MTU设置问题；建议客户修改客户端MTU值，由于客户端设备数量过多且可能存在未知风险，客户不接受此类方案
4、发现链路层移动某设备MTU设置为16xx，将其修改为1500，未恢复
5、怀疑防火墙安全设备存在分片缓存或者相应的安全策略过滤分片，vpn和专线都经过防火墙，vpn无问题
6、在专线网关出口抓包，发现所有分片都已经传输至客户侧
7、在客户侧设备逐层抓包，最终聚焦至核心交换机
8、邀请华三厂商进行定位，最终定位属于华三核心交换机RFC1858相关安全策略问题：
A、首片报文中TCP报文长度小于20字节
B、后续分片报文中分片偏移量等于8字节（FO小于等于8）的报文为TCP分片攻击报文
华三该型号的核心交换机某条安全策略会将以上两种分片作为攻击进行过滤
9、将此策略关闭，问题解决
案例1总结：涉及IDC及专线网关等各类网关设备，排查路径太长，一般通过抓包进行逐层分析，逐台设备进行排除，在排查过程中其实已经初步怀疑是客户侧设备安全策略问题，但由于idc-idc场景下无问题复现，客户侧不认同，只能通过抓包进行分析定位实际证据。
案例2：客户突发腾讯云某几个CVM通过专线查询IDC数据库相比走VPN延时明显增加的问题，执行相同sql，通过VPN查询仅需10ms，通过专线查询却需200ms
排查思路及过程：
1、对自建mysql和cvm进行抓包分析，后端同步分析抓包数据，未定位具体原因，由于数据库相同，且无特殊安全组策略配置，怀疑问题出现在网络层
2、收集访问正常的CVM与非正常CVM的正反向tracert，发现路径确实均通过专线访问，正常与非正常CVM路径一致
3、通过TCPPING和长ping分析，同时关注mysql日志情况及CVM侧异常情况，发现正常CVM tcpping状态显示close，非正常tcpping显示open，怀疑数据库服务主动拒绝
4、针对3获得的信息进行客户侧设备层逐层抓包
5、经分析得知，数据丢失在客户防火墙设备侧
6、与防火墙厂商确认，是由于设备升级开启了7层防护策略导致
7、关闭7层防护策略，问题解决
案例2总结：看似是数据库问题，且为突发，首先考虑相关变更操作导致；后续排除mysql相关问题，定位至网络问题，逐层抓包分析定位问题点。
案例3：客户IDC侧无VPN设备，通过自建gre隧道进行数据双向传输，从tke中拉取IDC git中镜像下载过程中会卡住，在CVM上拉取正常
由于gre为临时替代方案，后续专线拉通后可解决，未做深入查因
后续怀疑是由于GRE封装后导致总体报文长度变长，同时连路上未做MTU值更改导致分片被抛弃导致
案例3总结：网络协议导致报文变长，MTU值未做变更，导致出现异常
整体总结：混合云场景下的网络问题情况相对复杂，在排除异常变更及规模化故障的前提下，可优先考虑排查IDC侧网络设备安全策略及协议层变化，具体根因最终实际解决或者实锤路径只能通过抓包进行具体分析，但整体链路设备会很多，建议从最大路径抓包后进行逐层拆解，将抓包路径不断缩小。
