设备为两台AD集群部署，硬件设备指示灯正常，且查看版本没有必打的补丁包，巡检也没有出现问题，于是查看设备告警日志
1、查看设备告警日志，可以看到该节点池有部分节点离线。
2、查看节点池信息，该节点池有多个节点，且也确实有部分节点是处于服务不可用或者网络不可用状态，与客户沟通，确实有部分节点是处于离线状态的。
3、往前再翻看下，确认到整个虚拟服务并没有离线告警的日志，而只有部分节点池告警的日志，由此推测，如果仅仅只是某个节点异常，应该不会造成频繁的用户无法访问虚拟服务的现象。
4、正式上班后，用户同样反馈业务无法使用，再设备上查看该虚拟服务是正常的，可以正常提供业务的，于是将设备接到核心交换机上，跨网段访问AD发布的业务，发现确实无法访问，在本地抓包，发现有一堆的重传以及rst包。
5、在设备上抓包，没有看到任何有关于该发布业务的IP地址的任何包，曾经一度怀疑是自己的命令或者参数有误；确认了设备没有收到用户的数据后，与客户沟通，中间链路是否有安全设备，客户回答没有，那么应该还是网络上的问题。
6、有意思的现象来了，刚才在第4步的时候，进行了业务访问，同时也进行了ping包的测试，在第5步的时候抓包却看不到任何数据，而ping的时候又是正常的。
这时候大家注意一下，我刚刚说的是连接到核心交换机上，负载均衡的网关也是在核心交换机上，ping包的结果却显示该地址的时延有2ms，TTL居然为63，这个明显是不正常的。
7、于是尝试去ping同一个接口的另外一个地址，结果很显而易见了。
访问正常的地址的时候，时延<1ms（这才符合内网的时延情况），TTL为64，说明从我的电脑到负载均衡只过了交换机着一跳，而上述TTL为63，说明中间又多了一跳三层设备。
8、最后，问题很简单，就是客户内部有人把故障的IP地址配置到了其他地方，导致IP地址有冲突，当用户访问异常的时候，那时候用户的get请求会被丢给错误的主机上，无法响应，客户端也就提示404了。
发表于 2019-11-28 09:52