Date: Wed, 05 Dec 2001 13:52:48 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Ruslan Ermilov <ru@FreeBSD.ORG> Cc: Eugene Grosbein <eugen@grosbein.pp.ru>, "Crist J . Clark" <cjc@FreeBSD.ORG>, net@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: NOARP - gateway must answer and have frozen ARP table Message-ID: <200112051852.fB5IqmH95809@whizzo.transsys.com> In-Reply-To: Your message of "Wed, 05 Dec 2001 20:45:26 %2B0200." <20011205204526.B89520@sunbay.com> References: <20011205124430.A83642@svzserv.kemerovo.su> <20011205040316.H40864@blossom.cjclark.org> <20011205231735.A1361@grosbein.pp.ru> <20011205193859.B79705@sunbay.com> <200112051835.fB5IZqH95521@whizzo.transsys.com> <20011205204526.B89520@sunbay.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Wed, Dec 05, 2001 at 01:35:52PM -0500, Louis A. Mamakos wrote: > > Doesn't this behavior need to be on a per-interface basis? I'm wondering > > if a single sysctl is sufficient to get the desired effect. > > > No, we want ARP table to stay intact no matter which interface > sends us an update. I thought the original desire was to have a network interface which would respond to ARP requests, but only use static IP->MAC address mappings installed in the ARP table. I would imagine there are circumstances where you'd like other network interfaces on a multi-homed host to continue to operate in the "normal" fashion. While the sysctl proposed would appear to enforce that on all interfaces or none, I don't think that's nearly as useful as per-interface behavior of how IP->MAC mappings get maintained. For example, a router between some upstream transport via an ethernet and some subscriber network where this restricted ARP function is enabled. Multiple instances of the sysctl variable, per interface would be another way to go, but not easily implemented. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200112051852.fB5IqmH95809>