Recently, I encountered such a situation when trying to connect a large LAN to a new Internet link. However, by employing patience with solid troubleshooting and carefully researching the pertinent standards, I was able to turn a classic finger-pointing situation into a functional network connection.
The task
On the surface, the task seemed to be quite basic. I was upgrading a customer's LAN Internet connection to a 1Gbit/sec. Metro Ethernet link. Now, having an Ethernet feed presented the opportunity of placing an intrusion-detection system (IDS) sensor prior to the border router by connecting the Metro Ethernet to a switch placed between the LAN border router and the Metro Ethernet drop, as shown in Figure 1.
The problem
When I connected the switch to the ISP's equipment via a multimode fiber patch cord, the ISP equipment had a link light but the LAN equipment did not. I tested the connection to verify that it was in fact inoperable.
I contacted the ISP to determine the proper settings. The LAN switch defaulted to auto-negotiation enabled for all Gigabit Ethernet ports. The ISP indicated that its equipment was configured for no auto-negotiation. The manual settings the ISP required were basic: speed set at 1Gbit/sec., duplex set to full and auto-negotiation disabled. And it requested the LAN switch be manually configured accordingly.
Although I was mildly bothered by the fact the ISP required manual settings, I fully expected to have the link come up when I configured the switch interface with these values. Unfortunately, the link light did not illuminate. No link light generally means no connectivity, and this was no exception. Saving the new configuration and rebooting the switch had no effect.
The pointing begins
My experiences with 100Mbit/sec. twisted pair connections have been that often auto-negotiation should be turned off and the settings forced, so the ISP's request seemed to make sense. However, with Gigabit Ethernet connections I have always had excellent success with having both ends set for auto-negotiation. A colleague had once expressed the Ethernet auto-negotiation practices as such: for 1Gbit/sec., enable; for 100Mbit/sec. disable; for 10Mbit/sec., upgrade.
I contacted the LAN switch manufacturer and opened a trouble ticket to determine if its equipment was at fault. I also asked the ISP if it could enable auto-negotiation for testing. When it did, the interface came up. Therefore, the simplest answer seemed to be to leave auto-negotiation enabled. However, the ISP said because of its network design that was not possible.
The ISP further questioned the validity of connecting a switch to its equipment. It had doubts as to whether the settings could be configured correctly on the LAN equipment. Since these options were available in the equipment's operating system, I assumed that the features worked per the standards.
It was about this time that I began to think about what the standards clearly said. The ISP was inferring that the problem was on the LAN side, and the LAN equipment manufacturer indicated the switch can in fact be set to operate with auto-negotiation disabled. It was time to hit the standards.
Clause 37
Everything Ethernet is covered under IEEE 802.3. Specifically, 802.3z covers Gigabit Ethernet auto-negotiation. Referenced as Clause 37 in 802.3, it states that auto-negotiation should be enabled on 1000BASE-X links.
"Should" does not mean "must," so at this point I turned to searching for interpretation of the standards. I didn't find much, but the few white papers I found suggested that auto-negotiation should not be enabled on any Gigabit Ethernet connection, regardless of media. In particular, I found an excellent paper by Sun Microsystems regarding best practices for Gigabit Ethernet auto-negotiation.
At this point I was convinced the implementation by the ISP was at the very least against best practices and quite possibly against the standards. I suspected the ISP was arriving at the same conclusion, as it installed an intermediate router between their equipment and the LAN switch to provide a possible quick fix, as shown in Figure 2.
The ISP router had two Gigabit interfaces: one with auto-negotiation enabled, the other disabled. The first connected to the LAN switch and the second to the ISP equipment. All links came up and the problem was resolved, yet the question of where the fault lay was still up in the air.
Epilogue
A short time later the LAN switch manufacturer presented its official stance. According to its interpretation of the standard, the option to operate with auto-negotiation disabled was included to ensure interoperability with Gigabit equipment produced prior to the adoption of Clause 37. This was to overcome the determination of the master/slave relationship. Equipment with auto-negotiation disabled would act as the master. Equipment with auto-negotiation enabled would start the negotiation process as master. Thus, two masters could not communicate.
The LAN switch manufacturer went on to say that while it could possibly write code to circumvent this, in its opinion that was against the standard. Further research found an instancewhereby the IEEE agreed that such interpretation constitutes a request to change the standards. The final decision by the manufacturer was to maintain strict adherence to the standards, a move I completely agreed with.
Without researching the standards, I may have given in to the ISP's position and purchased network equipment that was more flexible with implementing 802.3z at much additional cost to my customer.
In the broader sense, however, the standards exist for interoperability, and a vendor or ISP should not dictate otherwise.
Greg Schaffer is the director of network services at Middle Tennessee State University. He has over 15 years of experience in networking, primarily in higher education.