From owner-freebsd-net@FreeBSD.ORG Fri Nov 13 17:54:01 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DF861065670; Fri, 13 Nov 2009 17:54:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 535DD8FC13; Fri, 13 Nov 2009 17:54:01 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E67A346B45; Fri, 13 Nov 2009 12:54:00 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 06D458A01B; Fri, 13 Nov 2009 12:54:00 -0500 (EST) From: John Baldwin To: net@freebsd.org Date: Fri, 13 Nov 2009 12:44:58 -0500 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911131244.58819.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 13 Nov 2009 12:54:00 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Brooks Davis Subject: ifnet renaming interacts badly with vlans X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 17:54:01 -0000 So first the problem I am trying to solve. I would like to give meaningful aliases to interfaces and vlans on interfaces. For example, suppose I would I have em0 with a vlan of 112, but I would like to call em0, "foo" and em0.112, "foo.bar". One can do this if you do things in this order: ifconfig em0 name foo ifconfig foo.112 create ifconfig foo.112 name foo.bar However, our rc.d scripts want to create all cloned interfaces before applying renames, so to attempt to do this in /etc/rc.conf you would use something like: cloned_interfaces="em0.112" ifconfig_em0_name="foo" ifconfig_em0_112_name="foo.bar" However, this ends up doing a sequence more like: ifconfig em0.112 create ifconfig em0 name foo ifconfig em0.112 name foo.bar Unfortuantely, this sequence breaks em0.112 at the second step. The reason is that when em0 is renamed, the kernel actaully fires off event handlers claiming that the em0 ifnet has been detached and that a new foo ifnet has been attached. When this happens, the em0.112 vlan ifnet is orphaned. I think this is a bug in how renames are handled. Specifically, I don't think renaming an interface should always have the same semantics as if I had physically removed an interface and then later added it back. One alternative would be to instead broadcast a single "rename" event when an interface is renamed and things that cared about interface names (such as firewall rules) could still honor those events, but other subsystems might choose to ignore said events (e.g. vlan devices). Another alternative might be to use two different events ('ifnet_removed_name' and 'ifnet_added_name'). Subsystems that care about the name changing could reuse their existing detached/attached handlers for those two events without needing to change the event handlers themselves. A separate issue if the eventhandlers were changed is if we should use a different routing socket message when an interface is renamed or if it we should still claim that an interface has gone away and then come back. Given that we don't flush addresses from an interface when the name changes or even the ifindex it seems a bit disingenous to claim that the interface has detached and then reattached. -- John Baldwin