真·这可能是独此一家的网络无法连接的古怪问题了！

有一台windows服务器，配置如下
Intel E3-1245 v2
A-DATA DDR3 1333 8G * 2
Gigabyte GA-H77M-D3H(集成Atheros 8161 GbE网卡)
Plextor M5P 128G (System)
WD RE4 1T HDD * 2 (RAID1)
OS: Windows Multipoint Server 2012(基于Windows Server 2012)

遇到的问题
联网调试该服务器时，局域网正常。关机时，局域网全掉线...
此时，局域网内2台Debian 6服务器(一台DNS+DHCP服务器，一台网关服务器)，全部显示
eth0 reset adapter
而DHCP服务器那台还会显示
=============================================
May 29 18:53:22 files kernel: [6222073.816020] ------------[ cut here ]------------
May 29 18:53:22 files kernel: [6222073.816026] WARNING: at /build/buildd-linux-2.6_2.6.32-46-amd64-_ApuPc/linux-2.6-2.6.32/debian/build/source_amd64_none/net/sched/sch_generic.c:261 dev_watchdog+0xe2/0x194()
May 29 18:53:22 files kernel: [6222073.816029] Hardware name: S3210SH
May 29 18:53:22 files kernel: [6222073.816030] NETDEV WATCHDOG: eth1 (e1000e): transmit queue 0 timed out
May 29 18:53:22 files kernel: [6222073.816031] Modules linked in: nls_utf8 cifs ext3 jbd raid10 loop md_mod snd_pcm snd_timer snd soundcore snd_page_alloc pcspkr evdev psmouse button serio_raw processor i2c_i801 i2c_core i3200_edac edac_core ext4 mbcache jbd2 crc16 sg sr_mod cdrom sd_mod crc_t10dif uhci_hcd ahci e1000 libata floppy scsi_mod thermal thermal_sys ehci_hcd usbcore nls_base e1000e [last unloaded: scsi_wait_scan]
May 29 18:53:22 files kernel: [6222073.816057] Pid: 0, comm: swapper Tainted: G M 2.6.32-5-amd64 #1
May 29 18:53:22 files kernel: [6222073.816058] Call Trace:
May 29 18:53:22 files kernel: [6222073.816060] <IRQ> [<ffffffff812632da>] ? dev_watchdog+0xe2/0x194
May 29 18:53:22 files kernel: [6222073.816064] [<ffffffff812632da>] ? dev_watchdog+0xe2/0x194
May 29 18:53:22 files kernel: [6222073.816067] [<ffffffff8104df38>] ? warn_slowpath_common+0x77/0xa3
May 29 18:53:22 files kernel: [6222073.816071] [<ffffffff8119c4d8>] ? swiotlb_map_page+0x0/0xc4
May 29 18:53:22 files kernel: [6222073.816073] [<ffffffff812631f8>] ? dev_watchdog+0x0/0x194
May 29 18:53:22 files kernel: [6222073.816076] [<ffffffff8104dfc0>] ? warn_slowpath_fmt+0x51/0x59
May 29 18:53:22 files kernel: [6222073.816082] [<ffffffffa000fe5c>] ? e1000_alloc_rx_buffers+0xce/0x16a [e1000e]
May 29 18:53:22 files kernel: [6222073.816087] [<ffffffffa00101d1>] ? e1000_clean_rx_irq+0x274/0x2b2 [e1000e]
May 29 18:53:22 files kernel: [6222073.816090] [<ffffffff81297429>] ? icmp_rcv+0x1f2/0x220
May 29 18:53:22 files kernel: [6222073.816092] [<ffffffff812631cc>] ? netif_tx_lock+0x3d/0x69
May 29 18:53:22 files kernel: [6222073.816095] [<ffffffff8124dff8>] ? netdev_drivername+0x3b/0x40
May 29 18:53:22 files kernel: [6222073.816097] [<ffffffff812632da>] ? dev_watchdog+0xe2/0x194
May 29 18:53:22 files kernel: [6222073.816100] [<ffffffff810168f3>] ? read_tsc+0xa/0x20
May 29 18:53:22 files kernel: [6222073.816103] [<ffffffff8106bb5e>] ? timekeeping_get_ns+0xe/0x2e
May 29 18:53:22 files kernel: [6222073.816107] [<ffffffff8105a6c7>] ? run_timer_softirq+0x1c9/0x268
May 29 18:53:22 files kernel: [6222073.816109] [<ffffffff81069397>] ? sched_clock_local+0x13/0x74
May 29 18:53:22 files kernel: [6222073.816113] [<ffffffff81053d73>] ? __do_softirq+0xdd/0x1a6
May 29 18:53:22 files kernel: [6222073.816115] [<ffffffff8102462a>] ? lapic_next_event+0x18/0x1d
May 29 18:53:22 files kernel: [6222073.816118] [<ffffffff81011cac>] ? call_softirq+0x1c/0x30
May 29 18:53:22 files kernel: [6222073.816120] [<ffffffff8101322b>] ? do_softirq+0x3f/0x7c
May 29 18:53:22 files kernel: [6222073.816122] [<ffffffff81053be3>] ? irq_exit+0x36/0x76
May 29 18:53:22 files kernel: [6222073.816125] [<ffffffff810250f8>] ? smp_apic_timer_interrupt+0x87/0x95
May 29 18:53:22 files kernel: [6222073.816127] [<ffffffff81011673>] ? apic_timer_interrupt+0x13/0x20
May 29 18:53:22 files kernel: [6222073.816128] <EOI> [<ffffffff810176a4>] ? mwait_idle+0x72/0x7d
May 29 18:53:22 files kernel: [6222073.816132] [<ffffffff81017654>] ? mwait_idle+0x22/0x7d
May 29 18:53:22 files kernel: [6222073.816135] [<ffffffff8100fe97>] ? cpu_idle+0xa2/0xda
May 29 18:53:22 files kernel: [6222073.816138] [<ffffffff8151c140>] ? early_idt_handler+0x0/0x71
May 29 18:53:22 files kernel: [6222073.816140] [<ffffffff8151ccdd>] ? start_kernel+0x3dc/0x3e8
May 29 18:53:22 files kernel: [6222073.816142] [<ffffffff8151c3b7>] ? x86_64_start_kernel+0xf9/0x106
May 29 18:53:22 files kernel: [6222073.816144] ---[ end trace e03e537b8e7b946b ]---
May 29 18:53:22 files kernel: [6222073.816149] e1000e 0000:00:19.0: eth1: Reset adapter
May 29 18:53:23 files kernel: [6222074.132891] e1000e 0000:00:19.0: eth1: Reset adapter
May 29 18:53:25 files kernel: [6222076.690348] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
May 29 18:53:53 files kernel: [6222104.780274] e1000e 0000:00:19.0: eth1: Detected Hardware Unit Hang:
May 29 18:53:53 files kernel: [6222104.780275] TDH <c5>
May 29 18:53:53 files kernel: [6222104.780276] TDT <cb>
May 29 18:53:53 files kernel: [6222104.780276] next_to_use <cb>
May 29 18:53:53 files kernel: [6222104.780277] next_to_clean <c5>
May 29 18:53:53 files kernel: [6222104.780277] buffer_info[next_to_clean]:
May 29 18:53:53 files kernel: [6222104.780278] time_stamp <15cb64b60>
May 29 18:53:53 files kernel: [6222104.780279] next_to_watch <c5>
May 29 18:53:53 files kernel: [6222104.780279] jiffies <15cb64d3b>
May 29 18:53:53 files kernel: [6222104.780280] next_to_watch.status <0>
May 29 18:53:53 files kernel: [6222104.780280] MAC Status <80283>
May 29 18:53:53 files kernel: [6222104.780281] PHY Status <792d>
May 29 18:53:53 files kernel: [6222104.780282] PHY 1000BASE-T Status <3800>
May 29 18:53:53 files kernel: [6222104.780282] PHY Extended Status <3000>
May 29 18:53:53 files kernel: [6222104.780283] PCI Status <10>
=============================================
起初看到这日志，想说是网卡坏了，反正有2个集成网卡，换个呗，换完后，也确实正常了...一天...第二天，在调试那台windows服务器差不多后，关机，没半分钟，同事打来电话说上不了网了。
看了下DHCP服务器，又开始提示eth0 reset adapter了...这...2个网卡同时坏掉的几率太低了吧...开始怀疑局域网有人中毒导致的。

经过排查，既然是这台已关机的windows服务器导致的...拔掉网线，局域网马上正常。插上网线，等个10+秒，全网断线。测试了几次，确定真的是该服务器导致的。

但是...关机情况下，插上网线，局域网全部掉线，然后启动该服务器，局域网正常了...这...病毒不可能那么厉害吧...

把网线接到其他电脑，关机测试、开机测试都没遇到这问题，另一台电脑，主板与该服务器同一型号，只是CPU不一样(i5 2100)，同样的测试也是正常的，并没遇到这问题...