一、问题现象

    最近在某客户由于假期出现核心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相关配置还原,应用测试正常!