Date: Mon, 13 Jan 2020 20:31:52 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 243319] Panicked laptop & local network ARP flood Message-ID: <bug-243319-7501-3Q0UhgEWpD@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-243319-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-243319-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D243319 --- Comment #7 from Kyle Evans <kevans@freebsd.org> --- (In reply to Conrad Meyer from comment #6) Hmm... yeah, good point- I misread '18' as '16', and those are actually the= two Windows boxen on the local segment; 10.6.112.1 being the gateway for this v= lan. I'll work on another repro and see if I can't get more context. The flood s= eems to just be a side-effect of whatever's cutting off the local network, rather than the cause. This still has to be the result of something this NIC is do= ing periodically -- disconnecting it immediately remedies the situation and loc= al connectivity is restored, and the behavior is consistent but not immediately triggered upon panic. Nagios lets us know quickly when this laptop's taken = down the Windows machines. This is the context leading up to that particular flood: 07:55:35.211083 STP 802.1d, Config, Flags [none], bridge-id 8070.04:c5:a4:5e:0d:80.8098, length 43 07:55:35.650045 68:1c:a2:10:41:10 (oui Unknown) > Broadcast, RRCP-0x23 query 07:55:36.650033 68:1c:a2:10:41:10 (oui Unknown) > Broadcast, RRCP-0x23 reply 07:55:37.211468 STP 802.1d, Config, Flags [none], bridge-id 8070.04:c5:a4:5e:0d:80.8098, length 43 07:55:37.650026 68:1c:a2:10:41:10 (oui Unknown) > Broadcast, RRCP-0x23 reply 07:55:38.650003 68:1c:a2:10:41:10 (oui Unknown) > Broadcast, RRCP-0x23 reply 07:55:39.186264 IP 10.6.112.1 > ospf-all.mcast.net: OSPFv2, Hello, length 56 07:55:39.209654 STP 802.1d, Config, Flags [none], bridge-id 8070.04:c5:a4:5e:0d:80.8098, length 43 07:55:39.649990 68:1c:a2:10:41:10 (oui Unknown) > Broadcast, RRCP-0x23 reply 07:55:40.649980 68:1c:a2:10:41:10 (oui Unknown) > Broadcast, RRCP-0x23 query 07:55:41.211537 STP 802.1d, Config, Flags [none], bridge-id 8070.04:c5:a4:5e:0d:80.8098, length 43 07:55:41.649960 68:1c:a2:10:41:10 (oui Unknown) > Broadcast, RRCP-0x23 query 07:55:42.649947 68:1c:a2:10:41:10 (oui Unknown) > Broadcast, RRCP-0x23 query 07:55:43.210181 STP 802.1d, Config, Flags [none], bridge-id 8070.04:c5:a4:5e:0d:80.8098, length 43 07:55:43.649929 68:1c:a2:10:41:10 (oui Unknown) > Broadcast, RRCP-0x23 query 07:55:44.649936 68:1c:a2:10:41:10 (oui Unknown) > Broadcast, RRCP-0x23 query 07:55:45.208168 STP 802.1d, Config, Flags [none], bridge-id 8070.04:c5:a4:5e:0d:80.8098, length 43 07:55:45.649903 68:1c:a2:10:41:10 (oui Unknown) > Broadcast, RRCP-0x23 query 07:55:46.649907 68:1c:a2:10:41:10 (oui Unknown) > Broadcast, RRCP-0x23 query 07:55:47.229691 STP 802.1d, Config, Flags [none], bridge-id 8070.04:c5:a4:5e:0d:80.8098, length 43 07:55:47.649898 68:1c:a2:10:41:10 (oui Unknown) > Broadcast, RRCP-0x23 query 07:55:48.216500 IP 10.6.112.1 > ospf-all.mcast.net: OSPFv2, Hello, length 56 07:55:48.649860 68:1c:a2:10:41:10 (oui Unknown) > Broadcast, RRCP-0x23 reply 07:55:49.255548 STP 802.1d, Config, Flags [none], bridge-id 8070.04:c5:a4:5e:0d:80.8098, length 43 07:55:49.649850 68:1c:a2:10:41:10 (oui Unknown) > Broadcast, RRCP-0x23 reply 07:55:50.649836 68:1c:a2:10:41:10 (oui Unknown) > Broadcast, RRCP-0x23 reply 07:55:51.227859 STP 802.1d, Config, Flags [none], bridge-id 8070.04:c5:a4:5e:0d:80.8098, length 43 07:55:51.649821 68:1c:a2:10:41:10 (oui Unknown) > Broadcast, RRCP-0x23 reply 07:55:52.649815 68:1c:a2:10:41:10 (oui Unknown) > Broadcast, RRCP-0x23 reply 68:1c:a2:10:41:10 is the unmanaged switch immediately upstream from the lap= top. That unmanaged switch currently has yet another unmanaged switch of the same model upstream from it that I had setup ~5 months ago to try and isolate the problem, as this has been ongoing and consistent over the last 6+ months at least (I don't panic it that frequently). Immediately upstream from that on= e is a managed switch. The Windows boxen lay on the most-upstream switch, while = this laptop and another FreeBSD laptop are on the lowest switch. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-243319-7501-3Q0UhgEWpD>