Layer-3 ring network PING test is a strange phenomenon

I. background

The current network has a pair of Juniper mxbench routers that have just been put into use. They are only interconnected with the current network's one-to-one Huawei NE40E, and the interconnection link uses optical ports. Currently, mxbench needs to connect to a Huawei NE20 instance in a remote data center through a transmission network. The commissioning has not been successful. To verify that mxbench's optical port is normal, disable the connection between RT4 and RT2, temporarily deploy a pair of pigtails and RT2 on port ge-2/3/0 interconnected with NE20 on RT4 to check whether port ge-2/3/0 is normal.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131227/00511614G-0.jpg "title =" three-layer Ring Network pingtest of the abnormal image-figure 2.jpg "/>

Ii. "weird phenomenon"

RT4 ge-2/3/0 port and RT2 ge-1/1/11 interconnected, the test process found the following phenomenon, the commissioning staff suddenly quit, helpless.

Case 1: When two pigtails are connected between RT2-RT4, RT4 cannot ping RT2;

Ø Case 2: When only one Pigtails are connected between the RT2-RT4, and it is the pigtails of RT4 RT2 receiving direction, RT4 can ping RT2;

Iii. Analysis and Processing Process

Reproduce and analyze the two situations based on the tester's description of the phenomenon. The analysis method is mainly port-based receiving and receiving packet counters.

Case 1: requires on-site personnel to connect two pigtails; RT2 ge-1/1/11 port down, RT4 ge-2/3/0 port up, the number of packets sent and received by the RT4 and RT2 ports is as follows:

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, 24 packets

Ping packet test on RT4, ping RT2 ge-1/1/11 port IP188.1.25.102, a total of 19 packets, and stop, ping test failure

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 provisioned ed, 100% packet loss

Check again RT4 and RT2 the number of packets sent and received counter, as shown below, RT4 number of packets increased by 25, indicating that the ping packet from the ge-2/3/0 port; the RT2 ge-1/1/11 port transceiver counter unchanged, indicating that the RT4 ping package does not reach 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, 24 packets

Case 2: Only one Pigtails are required to be connected, that is, RT4 sends the pigtails in the RT2 receiving direction; RT2 ge-1/1/11 port up, RT4 ge-2/3/0 port down, the number of packets sent and received by the RT4 and RT2 ports is as follows:

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, 24 packets

Ping packet test on RT4, ping RT2 ge-1/1/11 port IP188.1.25.102, a total of 10 packets ping, no packet loss.

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

Check again RT4 and RT2 interconnection port transceiver counter value, as shown below, RT4 ge-2/3/0 port transceiver counter unchanged, it indicates that the ping packet of RT4 is not sent through the ge-2/3/0 port.

RT4:

Interface ge-2/3/0

Input packets: 25

Output packets: 8246

Check the route for 188.1.25.102 on RT4, point to another port ge-2/1/0, and perform traceroute testing on 188.1.25.102 with the path being a RT4-RT3-RT1-RT2.

RT2> show route 188.1.25.102

Inet.0: 1312 destinations, 1312 routes (1312 active, 0 holddown, 0 hidden)

+ = 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...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...71.201 (10.201.71.201) 2.106 MS 1.685 MS 2.783 MS

In order to further analyze the cause of ping failure, the optical fiber connection method is restored to scenario 1. Both RT2 and RT4 are tested using ping packets, which is consistent with the situation, when the ping operation is performed, the number of packets sending and receiving counters at the local end is increased, but the number of packets receiving and receiving counters at the peer end is not increased.

Finally, try to modify the duplex mode of the RT2 and RT4 ports. When the port duplex mode is changed to self-negotiation, the ports at both ends of the RT2 and RT4 are up, and mutual ping is normal.

RT4> show configuration interfaces Co., 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

Iv. Cause Analysis

1. The situation 1 due to RT2 and RT4 interconnection port duplex mechanism negotiation fails, RT2 port down, And RT4 port up, RT4 has 188.1.25.102 direct connection routing, pointing to the ge-2/3/0; RT4 ping RT2, packets are sent through ge-2/3/0, so the ge-2/3/0 packet sending counter is increased; Because duplex negotiation is not successful, RT2 port ge-1/1/11 is off, the ping packet cannot be received, and the package receiving counter is not added.

2, the second RT4 RT2 receiving direction pigtails connected, RT2 ge-1/1/11 port can receive light, so the port up, RT2 that 188.1.25.102 can be reached; RT4 ge-2/3/0 port because not received light, so the port down, So RT4 does not direct to 188.1.25.102, but there is a default route; and RT4 ping 188.1.25.102 does not specify 188.1.25.101 as the source address, the default use of the interface IP address as the source IP address, so through the path RT4-RT3-RT1-RT2, RT4 can ping 188.1.25.102.

V. Experience Summary

1. Keep calm and analyze the symptoms in detail.

2. Make good use of the port receiving and receiving packet counter tool for micro-analysis

3. duplex rate negotiation mechanism is often the root cause of direct link failure

4. Have a clear understanding of the global topology.

This article is from the "QiRui" blog, please be sure to keep this source http://qirui.blog.51cto.com/845978/1286423