This was a unique case, in that the Metro Ethernet terminated in the same remote Internet service provider router as the DS3. Since both links were operational concurrently before the cutover, I was able to perform a test from the client site, out the DS3 and in the Metro Ethernet.

An NDT test described above showed a throughput of about 5Mbit/sec. and correctly identified the slowest link as a DS3. I expected a greater throughput because the DS3 was carrying very little production traffic at this time. Pings across the links showed no loss.

Since all I had was an uneasy feeling about the NDT throughput results being lower than I expected, I reluctantly agreed to a service cut. I assumed the lower throughput value reported by NDT was an anomaly not related to the circuits, but I prepared for a rapid return to the DS3 just in case.

After the cut, with the Metro Ethernet now under a nearly negligible traffic load of approximately 4 percent inbound, I ran a ping test that revealed a packet loss of about 3 percent. While the Internet service provider pronounced the circuit healthy, my ping results coupled with the low throughput as determined by NDT were enough for me to make the call to reverse the cut.

As it turned out, there was a negotiation settings mismatch between two Internet service provider devices providing the Metro Ethernet link. Gigabit Ethernet works very well with autonegotiation turned on; when one side is set for such and the other is not, odd errors can occur.