Well, the first underwater telegraph cable that was laid was caught within a month by a fisherman who thought exactly that - that it was some heretofore undiscovered sea creature.
More recently, while laying a cable off the coast of Taiwan, the Chinese went out and helped themselves to a repeater section.
Neal Stephenson wrote a kick-ass article for Wired a few years ago about the laying of the FLAG cable from Japan to England. Give yourself a few hours and read.
Reread the article...the Cisco 6506 (unruly beasts they are, I deal with 'em every day) has redundant "supervisor modules", which house the main CPU, main memory, etc...and the switch's configuration. If one fails, the other detects the failure and takes over.
The problem, as far as I can tell, is that for some reason the configuration on the redundant supervisor module was not in sync with the config on the primary module (a failed/interrupted copy run start, maybe? copy run start is supposed to write the config to nvram on/both/ modules.) So when the primary failed, the secondary took over, but the config on the secondary was fscked, and the switch stopped working.
Slashdot Mirror
Well, the first underwater telegraph cable that was laid was caught within a month by a fisherman who thought exactly that - that it was some heretofore undiscovered sea creature. More recently, while laying a cable off the coast of Taiwan, the Chinese went out and helped themselves to a repeater section. Neal Stephenson wrote a kick-ass article for Wired a few years ago about the laying of the FLAG cable from Japan to England. Give yourself a few hours and read.
Reread the article...the Cisco 6506 (unruly beasts they are, I deal with 'em every day) has redundant "supervisor modules", which house the main CPU, main memory, etc...and the switch's configuration. If one fails, the other detects the failure and takes over. The problem, as far as I can tell, is that for some reason the configuration on the redundant supervisor module was not in sync with the config on the primary module (a failed/interrupted copy run start, maybe? copy run start is supposed to write the config to nvram on /both/ modules.) So when the primary failed, the secondary took over, but the config on the secondary was fscked, and the switch stopped working.
Didn't read closely enough. Never mind. :P
The dispute was over peta.org, not peta.com.