F5内网大二层负载均衡业务访问故障解析（CISCO OTV+LISP-MTU问题致使）

1、问题现象

    最近在某客户因为假期出现核心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日志各方面正常，无异常日志！

2、问题缘由

    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致使！

    更改后业务访问正常！

3、解决方法

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