三层环状网络PING测试的“诡异”现象
一、背景
现网有一对Juniper MX480路由器，刚投入使用不久，仅与现网一对华为NE40E以“口字型”互联，互联链路采用光口。现MX480需要与异地机房的一对华为NE20互联，中间经过传输网络，调测一直不成功，为了验证MX480的光口是否正常，关闭RT4和RT2的互联链路，把RT4上将与NE20互联的端口ge-2/3/0，临时布放一对尾纤与RT2互联，确认端口ge-2/3/0是否正常。
二、“诡异现象”
RT4 ge-2/3/0端口与RT2 ge-1/1/11互联后，测试过程中发现以下现象，调测人员突然懵了，束手无策。
Ø情况一：当RT2-RT4之间收发两条尾纤都连接上时，RT4不能ping通RT2；
Ø情况二：当RT2-RT4之间只连接一条尾纤时，而且是RT4发RT2收方向的尾纤，RT4能ping通RT2；
三、分析处理过程
根据测试人员对现象的描述，对两种情况进行重现和分析。分析方法主要基于端口的收发包计数器。
情况一：要求现场人员连接上两条尾纤；发现RT2的ge-1/1/11端口down，RT4的ge-2/3/0端口up，RT4和RT2两个互联端口的收发包数量计数器如下所示：
RT4：
interface ge-2/3/0
Input packets: 25
Output packets: 8221
RT2：
disp int gi 1/1/11
Input: 0 bytes, 0 packets
Output: 1536 bytes, 24packets
RT4上进行ping包测试，ping RT2的ge-1/1/11端口IP188.1.25.102，总共ping了19个包，并停止，ping测试不通
RT4> ping 188.1.25.102
PING 188.1.25.102 (188.1.25.102): 56 data bytes
^C
--- 188.1.25.102 ping statistics ---
19 packets transmitted, 0 packets received, 100% packet loss
再次检查RT4和RT2的互联端口收发包计数器数值，如下所示，RT4的发包数量增加了25个，说明ping包从ge-2/3/0端口出去了；而RT2的ge-1/1/11端口收发包计数器不变，说明RT4的ping包并没有到达RT2。
RT4：
interface ge-2/3/0
Input packets: 25
Output packets: 8246
RT2：
disp int gi 1/1/11
Input: 0 bytes, 0 packets
Output: 1536 bytes, 24packets
情况二：要求现场人员仅连接一条尾纤，即RT4发RT2收方向的尾纤；发现RT2的ge-1/1/11端口up，RT4的ge-2/3/0端口down，RT4和RT2两个互联端口的收发包数量计数器如下所示：
RT4：
interface ge-2/3/0
Input packets: 25
Output packets: 8246
RT2：
disp int gi 1/1/11
Input: 0 bytes, 0 packets
Output: 1536 bytes, 24packets
RT4上进行ping包测试，ping RT2的ge-1/1/11端口IP188.1.25.102，总共ping了10个包，无丢包。
cch13922702080@MB-NMS-XDS-RT5B-MX480> ping 188.1.25.102
PING 188.1.25.102 (188.1.25.102): 56 data bytes
64 bytes from 188.1.25.102: icmp_seq=0 ttl=254 time=1.087 ms
64 bytes from 188.1.25.102: icmp_seq=1 ttl=254 time=1.102 ms
64 bytes from 188.1.25.102: icmp_seq=2 ttl=254 time=6.006 ms
64 bytes from 188.1.25.102: icmp_seq=3 ttl=254 time=1.213 ms
64 bytes from 188.1.25.102: icmp_seq=4 ttl=254 time=3.190 ms
64 bytes from 188.1.25.102: icmp_seq=5 ttl=254 time=1.123 ms
64 bytes from 188.1.25.102: icmp_seq=6 ttl=254 time=1.182 ms
64 bytes from 188.1.25.102: icmp_seq=7 ttl=254 time=1.141 ms
64 bytes from 188.1.25.102: icmp_seq=8 ttl=254 time=1.177 ms
64 bytes from 188.1.25.102: icmp_seq=9 ttl=254 time=10.118 ms
^C
--- 188.1.25.102 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.087/2.734/10.118/2.883 ms
再次检查RT4和RT2的互联端口收发包计数器数值，如下所示，RT4的ge-2/3/0端口收发包计数器不变，说明RT4的ping包并不是通过ge-2/3/0端口发出。
RT4：
interface ge-2/3/0
Input packets: 25
Output packets: 8246
检查RT4上188.1.25.102的路由，指向另一个端口ge-2/1/0，对188.1.25.102进行traceroute测试，其路径为RT4-RT3-RT1-RT2。
RT2> show route 188.1.25.102
inet.0: 1312 destinations, 1312 routes (1312 active, 0 holddown, 0hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/150]3w0d 07:31:12, metric 2, tag 1
> to188.1.87.70 via ge-2/1/0.0
{master}
RT2> traceroute 188.1.25.102
traceroute to 188.1.25.102 (188.1.25.102), 30 hops max, 40 bytepackets
1 188.1.87.70 (188.1.87.70) 0.993 ms 0.724 ms 0.712 ms
2 10.201.71.206 (10.201.71.206) 1.569 ms 1.466 ms 1.466 ms
3 10.201.5.1 (10.201.5.1) 1.569 ms 4.854 ms 1.589 ms
4 10.201.71.201 (10.201.71.201) 2.106 ms 1.685 ms 2.783 ms
为了进一步分析情况一ping不通的原因，将光纤连接方式恢复到情况一，RT2和RT4两端都进行ping包测试，现象与情况一一致，ping的时候本端发包计数器有增加，但对端收包计数器无增加；将两根光纤的收发对调，情况不变。
最后，尝试修改RT2和RT4端口的双工模式，当把端口双工模式更改为自协商的时候，RT2和RT4两端端口均up了，互ping正常。
RT4> show configuration interfaces ge-2/3/0
speed 1g;
link-mode full-duplex;
unit 0 {
family inet {
address188.1.25.101/30;
}
}
[RT2 -GigabitEthernet1/1/11]disp th
#
interface GigabitEthernet1/1/11
negotiation auto
undo shutdown
ip address 188.1.25.102255.255.255.252
四、原因分析
1、情况一由于RT2和RT4互联端口双工机制协商不成功，RT2端口down，而RT4端口up，RT4上有188.1.25.102的直连路由，指向ge-2/3/0；RT4 ping RT2的时候，数据包通过ge-2/3/0发出，所以ge-2/3/0发包计数器增加；由于双工协商不成功，RT2端口ge-1/1/11处于关闭状态，无法收到ping包，收包计数器也不增加。
2、情况二RT4发RT2收方向尾纤连通，RT2的ge-1/1/11端口能够收到光，所以端口up，RT2认为188.1.25.102可达；RT4的ge-2/3/0端口由于未收到光，所以端口down，所以RT4上没有指向188.1.25.102的直连路由，但有默认路由；而且RT4上ping 188.1.25.102没有指定188.1.25.101作为源地址，默认使用出接口IP地址作为源IP地址，所以通过路径RT4-RT3-RT1-RT2，RT4能够ping通188.1.25.102。
五、经验总结
1、遇到“诡异”现象要保持淡定，细致分析。
2、利用好端口收发包计数器这个利器，进行微观分析
3、双工速率协商机制很多时候是直连链路故障的根源
4、胸怀大局，对全局拓扑要有清晰了解