Date: Fri, 11 Apr 2008 13:59:38 -0700 From: Jeremy Chadwick <koitsu@freebsd.org> To: Mike Andrews <mandrews@fark.com> Cc: Damian Weber <dweber@htw-saarland.de>, freebsd-stable@freebsd.org Subject: Re: RELENG_6_3 ping and DUP packets Message-ID: <20080411205938.GA25002@eos.sc1.parodius.com> In-Reply-To: <20080411153109.I22573@beast.int.bit0.com> References: <396418019.20080409104542@serebryakov.spb.ru> <5f67a8c40804100944k3984ab8fp95b5d4b22f92dd30@mail.gmail.com> <Pine.BSO.4.64.0804102140550.30252@isl-s-02.htw-saarland.de> <C73D9407-5492-43F4-9BE6-E05C98661107@mac.com> <Pine.BSO.4.64.0804110842280.21736@isl-s-02.htw-saarland.de> <20080411065256.GA95213@eos.sc1.parodius.com> <20080411153109.I22573@beast.int.bit0.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 11, 2008 at 03:40:48PM -0400, Mike Andrews wrote: > While rebooting to try disabling MSI, I noticed that the machine was still > pingable during the reboot (and returning just one response each), while > the thing was still doing its POST routines -- which of course made me do a > few double-takes, given that the FreeBSD kernel wasn't even running :) > Weirder is that the responses all had the bogus 255 TTL that the dupes had > when the system was up. Once the system did finish booting, the dupes > returned. Braindump time! FreeBSD, back in the 3.x or 4.x days, used to have a problem where during a reboot, after bringing down the network interfaces, the box would still respond to certain packets (ICMP being one of them). That got fixed. This is different than your problem, but I thought I'd point it out as a reminder for those who are newer to FreeBSD, or have forgotten it. A box pinging during or very shortly after POST would indicate a piggy-backed management interface on one of the NICs. I **hate** these things. Supermicro has this capability as well (via some IPMI add-on modules, while others (the more expensive ones) have a dedicated NIC, which is how it should be). Said management interfaces have a full layer 2 through layer 7 stacks on them. In bge(4) land, the feature is called ASF, and you can toggle FreeBSD's knowledge/respect of said feature via hw.bge.allow_asf in loader.conf. The problem with ASF is that if it's enabled in the BIOS/on the system somehow, and FreeBSD isn't aware of it, what happens is that systems on the network see two MAC addresses (sometimes for the same IP address) that are associated with one physical PHY/NIC. People end up seeing broken IP traffic, or duplicate packets in this case. > Turns out this Intel S3000AHV motherboard has a built-in management thingie > that's kind of IPMI-ish but apparently not quite actually IPMI (at least > ipmitool and freeipmi want nothing to do with it). Somehow it had gotten > itself enabled and was pulling an IP from the DHCP server, and bridging > itself through the onboard LAN. So ping replies were coming from both the > management CPU and the main CPU when the system was up, and just the > management CPU when the system was down. The reason the other Intel > S3000AH* system I have didn't do this is because that other system just > happens to be the DHCP server for its subnet -- and the reason the other > systems w/ the same chipset didn't do it is because they're all Supermicro > boxes with different management CPU's. Bingo. :-) None of our Supermicro boxes have piggybacked management capabilities, and they all use Intel PHY/NICs. It's likely a feature Intel has on their boards -- a cool feature, but piggybacking it on an existing NIC is such a bad idea, case in point. Glad to know you figured out the cause of your pain! -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080411205938.GA25002>