F5内网大二层负载均衡业务访问故障解析（CISCO OTV+

一、问题现象

最近在某客户由于假期出现核心CISCO 6509硬件故障当机问题，进而发现F5发布的3个应用访问问题，出现一部分人访问应用出现不可用的问题，时好时坏，内网使用F5 GTM+LTM进行域名双活，内部同城双活DC通过三层路由使用CISCO的大二层技术OTV+LISP技术构建；

F5上面检查应用不管是VS还是pool member都是正常，health check or monitor算法采用TCP；通过将LTM双机上面对端DC业务member 进行offline，GSLB的跨DC member disable解析只导流到主DC，此时业务访问正常，形成单活进行排查

问题表象是跨DC访问后业务就访问异常，但是神奇的是只有部分vlan有问题，大部分跨DC的vlan没有问题！

通过初步排查，应用人员表示应用无问题，网络人员表示网络无问题（可以从主中心ping通备中心应用IP，可以跨DCtelnet通业务应用端口，而且其它vlan没有问题），F5人员也表示F5日志各方面正常，无异常日志！

二、问题原因

F5人员建议对跨DC访问的443端口进行直接访问（不经过F5负载）测试与抓包，检查数据包通信情况

通过抓包，发现TCP三次握手正常，但是SSL协议握手异常，客户端发送了client hello之后，服务器端回送了一个1050byte左右的ssl data（非server hello)包且提示前导段丢失！然后接着客户端FIN掉了连接！

再通过对本DC正常应用访问抓包，明确SSL协商正常，SSL握手包最多几百byte，所以这是应用层面的异常问题，并不是简单的网络层面的问题

但是否是应用的问题呢，让应用人员更换一个vlan后，访问正常！证明并不是应用层面的配置异常问题！很可能是网络影响应用的一个问题！

鉴于硬件故障当机，路径变化，应用ssl协议交互数据包大小异常，并提示previos fragment前导段丢失等网络问题，F5人员建议检查MTU设置，然后客户管理人员以及网络人员才说出之前也出现过MTU问题，让CISCO TAC进行检查，通过几个小时检查，终于确认是由于CISCO 6509当机导致部分VLAN OTV路径变换，MTU没有改为9216字节的MTU导致！

更改后业务访问正常！

三、解决方法

更换路径中的OTV MTU后解决，F5相关配置还原，应用测试正常！