有的时候 TCP 能够连通，有的时候无法连通。那么正常的 TCP SYN 包和异常的 TCP 包之间肯定是有什么字段是不一样的。当然，也有可能 SYN 包一模一样，问题出在了其他的网络设备上或者 TCP 的另一端。但是既然题目出给读者了，那么问题的根源肯定是隐藏在抓包文件里面。
通过对比来寻找答案
正常的 TCP 连接可以完成 TCP 的握手和挥手。
异常的 TCP 连接，发出去的 SYN 直接收到了 RST。
通过对比可以发现，两个 SYN 包的 Dst MAC 是不一样的。
通过推理得出答案
如果不通过对比的方法，顺藤摸瓜，可以用下面的思路。
首先，Src IP 和 Dst IP 分别是 10.210.151.187 和 10.210.151.90，很大概率是属于同一个 /24 子网的 IP，不过要想确认的话需要看下服务器的 IP 地址是如何配置的，子网掩码是不是 /24，这点我们从给出的信息无从得知。
假设确实是属于同一个子网，那么 TCP SYN 包不经过网关，直接发给目的地址，二层的 Dst MAC 地址应该是目的 IP 的 MAC 地址。
假设不属于同一个子网，那么 TCP SYN 包经过网关，TCP SYN 包的目的地址应该是路由器的 MAC 地址。
无论是那种情况，正常情况下发送给同一个 Dst IP 的目的 MAC 应该是唯一且稳定的。通过 Conversation 统计可以看出，通讯的 IP 对只有一对，但是 MAC 的确有 2 对，这是不对的。
Statistics > conversation
原因分析
造成这种现象的原因是，IP 分配重复了，在同一个子网内，同一个 IP 地址 10.210.151.90 被分配给了多个机器。
发送 TCP 包之前，需要知道对应的 Dst IP 地址的 Dst MAC 地址，怎么知道呢？Src 机器会在整个子网内广播 ARP 询问，持有这个 IP 的机器会回复 ARP。现在子网内有两个相同的机器是相同的 IP 地址。这两台机器的 IP 地址一样，MAC 地址不一样。如果我们现在 arping 10.210.151.90 ，会得到如下的回复：
可以把 Src MAC 地址添加到 Column 显示，就可以发现其实 ping 的回复来自不同的设备。
最后一个问题，为什么会有 IP 重复的问题呢？
DHCP 可以用来动态分配 IP 地址给设备，但是一般只用于客户端，比如办公网、家用网络中的终端设备，这些设备一般作为连接的发起方，不需要 listen 一个固定的 IP 地址，IP 地址的动态变化对它们影响不大。但是在 IDC 的网络中，每一个服务器的软件都需要固定的 IP 地址，一般不用 DHCP 来动态分配，而是用中心化的 IPAM 系统1追踪 IP 地址的分配情况。如果里面记录的地址不正确，比如，一个地址已经在使用中了，但是并没有在 IPAM 记录，就造成 IP 地址重复的问题。
检查 bond 状态 (/proc/net/bonding/bond0 文件), bond 配置，都没发现问题。可能是 eht0 这个接口有问题？
在重新看 interface 的时候（即上面的 ip link 命令和输出），我发现了可疑的一条 interface：
4: eth0.1000@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether b6:db:e6:76:dd:8a brd ff:ff:ff:ff:ff:ff
使用 ip link set dev eth0 arp off 可以禁用 interface 的 ARP 恢复，这样，在 LAN 上就相当于把这个 interface 隐藏了，因为没有人可以发现它的 MAC 地址了。在四层负载均衡中，如果使用 DSR 的模式并且不加隧道的话，就需要对 RS 的 VIP 禁用 ARP 回复1。
另一个方法是使用 arp_filter 参数，这个参数是一个 bool，默认是 0 ，如果开启为 1，就意味着，如果收到 ARP request，ARP 请求的 IP 为 A，收到 ARP 的 interface 为 X 和 Y，那么 kernel 就测试路由，假设要发出去 source IP 为 A 的包，从 X 发出去还是从 Y 发出去。如果从 X 发出去，那么只有 X 会回复。（source based rotuing).
root@ubuntu-1:/$ ip route get 192.168.1.10 from 192.168.1.2
192.168.1.10 from 192.168.1.2 dev eth0 uid 0
cache
root@ubuntu-1:/$ ip route get 192.168.1.10 from 192.168.1.3
192.168.1.10 from 192.168.1.3 dev eth0 uid 0
cache
可以看到无论 source IP 是哪一个，都会从 eth0 口出。
这是因为我们的 ip route 配置：
root@ubuntu-1:/$ ip route show table all
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.3
root@ubuntu-1:/$ ip route del 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2
root@ubuntu-1:/$ ip route get 192.168.1.10 from 192.168.1.3
192.168.1.10 from 192.168.1.3 dev eth1 uid 0
cache
root@ubuntu-1:/$ ip route get 192.168.1.10 from 192.168.1.2
192.168.1.10 from 192.168.1.2 dev eth1 uid 0
cache
Lookback 接口是否会回复 ARP？
答案是是的（虽然听起来很没道理）。这个主要是跟路由有关。
当我们在给 lo 绑定一个地址的时候，kernel 会默认添加 2 条路由，lo 所在网段和 lo 的地址会被标记成 dev lo 的本地路由。
root@ubuntu-1:/$ ip route show table local
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
local 192.168.1.0/24 dev lo proto kernel scope host src 192.168.1.2
local 192.168.1.2 dev lo proto kernel scope host src 192.168.1.2
broadcast 192.168.1.255 dev lo proto kernel scope link src 192.168.1.2
这个是默认的行为。但是如果我们改一下，删除这两条路由，添加另一条从 eth0 口出的路由的话，就会发现，arping lo 接口的 IP，也会收到 ARP response 了。
root@ubuntu-1:/$ ip route del local 192.168.1.0/24 dev lo proto kernel scope host src 192.168.1.2
root@ubuntu-1:/$ route del local 192.168.1.2 dev lo table local proto kernel scope host src 192.168.1.2
root@ubuntu-1:/$ ip route add local 192.168.1.2 dev eth0 proto kernel scope host src 192.168.1.2
root@ubuntu-1:/$ ip address show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet 192.168.1.2/24 scope global lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
我们在编程的时候经常指定 IP 和 Port，但是几乎从没有指定过 MAC 地址，那么 Frame 是怎么发出去的呢？这是操作系统帮我做了这件事。如果系统不知道一个 IP 对应的 MAC 地址是什么，系统会发送一个广播的 ARP 请求，（由于这个请求也是要通过 Ethernet 发送出去的，所以也要填充 Dst MAC，Dst MAC 就是 ff:ff:ff:ff:ff:ff。）询问谁有目的 IP，如果有，请回复给 MAC-B。广播域中所有的 Host 都会收到这个请求，只有拥有这个 IP 的 Host 才会回复给 MAC-B 自己的 MAC 地址，这样，B 就知道了这个 IP 对应的 MAC 地址。
ARP Probe 的作用是，在分配到一个 IP 之后，但是在 IP 使用之前，可以先用 ARP 协议来检查一下当前的 LAN 内有没有人在使用这个 IP。
检查的方式就是用 ARP 询问这个 IP 的 MAC 地址，如果有主机正在使用，那么就会收到 ARP reply。
但是这里有一个问题。一个主机如果收到了 ARP request，询问谁有 IP X？请发送回复给 IP 地址 Y at MAC 地址 Z。即使这个主机没有 IP X，也不会单纯丢弃这个 ARP request，而是会从这个 ARP request 中学习到，IP Y 对应 MAC Z，会将它放到自己的 ARP cache 中。
这里我们只是想检查一个 IP 是否正在被使用，我们还没有真正地开始使用这个 IP。如果用普通的 ARP 请求来询问，假设这个 IP 已经被使用，那么发出去的 ARP request 就会传达错误的信息，其他主机就会根据这个 ARP request 来更新自己的 ARP cache。
︎
︎
