多地数据中心，不同数据中心之间通过 ISP MPLS 连接，数据中心之间有数据备份的需求，客户最初发现从 site A 到 site B 的数据备份慢，于是做了一些交叉测试：
1. Windows 和 Linux/Unix 终端， Windows 性能稍差
2. 如果两个终端都在 site A，数据备份很快
1. 接入相同 Leaf，不经过 spine
2. 接入不同 Leaf，流量经过 spine
3. 如果两个终端都在 site B，数据备份很快
1. 接入相同 Leaf，不经过 spine
2. 接入不同 Leaf，流量经过 spine
4. 如果从 site A 到 site B，数据备份慢；保持 client/server 不变，交换角色：
5. 如果从 site B 到 site A，数据备份很快，amazing
也就是单向流量慢，在所有条件不变的情况下，只是交换 client/server 角色，反向的流量居然是快车道。
网络拓扑大致上是 ACI pod1 -- IPN -- ISP MPLS -- IPN --- pod2。拉长版：
无法插入图片，查看附件吧
一些排查方向
首先检查 ACI 是不是有 Faults，或者可疑地 events（比如某个设备 TCAM 占满），没有可疑日志。
然后顺带检查了 IPN 的配置，log，也没有可疑日志。
之后，客户自查了 clients/server 的服务日志，CPU/RAM 占用，没有到达瓶颈。
客户的动手能力比较强，做了很多的测试，从汇总的信息来看，TCP 传输慢的问题不局限在特定的 OS(Windows, Linux, Unix)，甚至看起来和 OS 无关。
从 ACI pod 内部来说，流量在 Leaf 直接中转，或者经过 spine，对性能都没有影响。说明 ACI 内部的 hash，硬件转发没有出现问题。
从跨 ACI pods 的角度来说，中间经过的网络设备虽然很多，但可以先基本归类为 IPN，ISP 两类。正向和反向测试，一慢一快，设备相同，暂时没有头绪。
开始抓包吧
交叉测试和日志分析都没有得到比较可靠的结论，这时候就要引入抓包和数据包分析了。抓包虽好，但是应该当作最后的排查手段。
在哪个设备，哪个接口抓包呢？
在单一设备，接口抓包，意义不大，没办法做对比。打个比方，在 pod2 server 抓入向/ingress 报文发现有 TCP 乱序或者重传，那么这个问题从哪个设备开始引入的？
在所有设备，接口抓包，困难较大，没有这么多的资源，也没有必要。
结合测试结果，暂定的抓包位置：
- client tcpdump，用来做基准线，发出的数据包的基本信息，数据包之间的延迟等
- 这是 OS 层面。因为是 Virtual Machine 虚拟机，按需决定是否要在 kernel 做抓包
- pod1 IPN ingress，用来确认 ACI pod1 有没有出现转发问题
- pod1 IPN egress，用来确认 IPN 有没有引入问题，比如转发延迟
- ISP 暂时不受控制，bypass
- pod2 IPN ingress，用来确认进入 site B 之前，流量有没有问题
- pod2 IPN egress，用来确认 IPN 有没有引入问题，比如转发延迟
- server tcpdump
在抓包的时候，要先打开抓包，再传输流量，保证抓包内容有 TCP 三次握手的过程，这样 Wireshark 才能辅助分析 TCP window 和 sequence number 增长。
数据包分析
话题比较大，以后可以单独说一些 Wireshark 技巧。
这里只说结果：
- 各个位置的抓包，都出现了重传。有些还有乱序，零窗口
- 在 pod2 ingress，数据包有乱序 TCP Out-of-Order，那么流量进入 site B 之前，就已经有问题了
- 在 pod1 ingress & egress，流量没有乱序，说明流量在 site A 的转发没问题
接下来就是联系 ISP 这个黑盒子了。
最终结果
---
山重水复，这个问题来来回回做了太多次的测试，分析了数十次数据包。
柳暗花明，每一次分析之后，都能够把故障范围缩小，排除一些怀疑方向。
