Date: Thu, 11 Jan 2007 08:37:51 +0000 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Eygene Ryabinkin <rea-fbsd@codelabs.ru> Cc: freebsd-net@freebsd.org, Tadaaki Nagao <nagao@iij.ad.jp>, andre@freebsd.org, LI Xin <delphij@delphij.net> Subject: Re: Different behavior of ping'ing INADDR_BROADCAST? Message-ID: <45A5F75F.8080404@FreeBSD.org> In-Reply-To: <20070111063715.GL14822@codelabs.ru> References: <459D4D88.2030708@delphij.net> <459FEDBC.4070008@FreeBSD.org> <20070107115158.GA63854@codelabs.ru> <45A54119.20809@FreeBSD.org> <20070111063715.GL14822@codelabs.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Eygene Ryabinkin wrote: > Do you (or anyone else reading this post) have access to the different > IP stack realisations at hosts with multiple broadcast-able interfaces? > If yes, wouldn't you all be so kind to try to ping the broadcast address > and report the behaviour? > Windows deals with this by assigning each interface an 'interface metric', which is a default metric that a route is tagged with if it traverses a particular interface, and adding a unicast route to its FIB to INADDR_BROADCAST via each IFF_BROADCAST interface configured and running in the system. You can see this in the output of 'route print'. Selection of the next-hop is then done as in the same way for any other unicast destination with an assigned metric. The Windows FIB supports equal cost multipath; ours doesn't at the present time. The Windows approach seems much cleaner, as it simply reuses the existing unicast FIB lookup, although it involves adding additional routes to the FIB; systems with hundreds of VPN interfaces would therefore spam the FIB with such routes if we used this approach, potentially causing problems similar to those which were part of the reason behind the removal of PRCLONING in the FreeBSD 5.x era. Given that these routes would normally never be exchanged with any peers (and the FIB is not the most appropriate place for route redistribution anyway), it may be preferable and acceptable to put the next-hop selection logic for INADDR_BROADCAST into the stack itself. I'm personally not in favour of sending a single broadcast packet to multiple interfaces as it has potential for denial of service, and doesn't seem to be consistent with the behaviour of other systems, or the most common use-case for undirected broadcast, which is early boot and/or DHCP. Applications such as ISC DHCP work around the traditional BSD behaviour by using BPF to inject and receive IP broadcasts. The MROUTING code can potentially copy mbuf chains for each interface, though it tries to avoid making such copies. Regards, BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45A5F75F.8080404>