Cable too long, LAN works, WAN doesn’t work

Network analysis

1. Symptoms

Today’s patient is an import and export company. After activating a DDN dedicated line, some users complained of slow data exchange and frequent connection interruptions. The network support staff couldn’t find the issue despite multiple investigations and sought assistance from the Network Hospital.

The company’s original network structure was a simple LAN distributed across three floors, with a total of 300 endpoints. Each floor had around 100 users. The network cabinets were located on the top floor, and the floors were divided into three segments using switches. Previously, employees used dial-up to access the Internet, and they felt that the network speed was fast, and work was normal. Recently, they added routing equipment and applied for a DDN dedicated line. Some employees on the lowest floor experienced slow speeds and frequent, unexplained interruptions. Since the company had no network monitoring tools and data exchange within the LAN was not affected, the trouble was only noticed two weeks after the project was completed when users experienced problems accessing the Internet. Therefore, they turned to the Network Hospital for help.

2. Diagnostic Process

The company’s network was originally a 10Base-T LAN. The recent changes involved adding DDN equipment and a router, while other configurations remained mostly the same. Therefore, I connected a network tester (F68X) to a user port on the lowest floor to observe the network. The average traffic was 1.2%, and no abnormalities were found. The network traffic was then increased step by step, and no issues were detected. Initially, it seemed like there were no problems in this network segment.

To quickly locate the network issue, I decided to send traffic to other network segments while observing the network’s status. As the traffic increased, I noticed a rise in error frames after one minute. These frames were FCS error frames originating from a user on the second floor. It was evident that the problem was not related to a specific workstation but rather the entire network segment. I checked the port record of the switch in the affected area, and it showed FCS error frames. However, other switch port records did not indicate FCS errors (the switch was non-cut-through type). This indicated that there was a cable link within this network segment that was too long. To verify this further, I sent traffic to a known Internet user and conducted ICMP Ping tests. The loss rate was around 90%. Since the physical tests performed in this network segment earlier did not show any abnormalities, it was clear that the cable between the hub and the switch was too long. The cable’s length measurement indicated 175 meters, which exceeded the recommended maximum.

3. Conclusion

According to network standards, Ethernet operates using a collision detection shared medium. The length of the network cable from each workstation to the hub should not exceed 100 meters to ensure minimal latency and FCS frame errors. Although the super-long 175-meter cable within this network segment did not cause issues in data exchange within the segment, it resulted in problems when connecting to other network segments. However, the low average network traffic within the LAN masked the issue’s impact on speed. When multiple users simultaneously exchanged WAN data via DDN, FCS frame errors led to significant delays. The 64Kbps export flow was much slower than the 10Mbps LAN speed, and the high error frame ratio caused multiple retransmissions, making it appear as if the network speed had decreased. Frequent FCS errors could also lead to WAN connection interruptions due to errors, resulting in all users in the affected floor complaining of slow speeds and frequent interruptions.

4. Diagnostic Recommendations

Network owners should conduct two acceptance checks for new network projects: on-site certification testing of the network cabling system and network acceptance testing (including physical testing and simulated Internet access testing of each workstation under load conditions).

5. Afterword

One week after the company reconfigured the network segments, users reported that everything was working correctly.

Share this