Date: Tue, 2 Jan 2001 00:19:29 -0500 (EST) From: Alex Pilosov <alex@pilosoft.com> To: "C. Stephen Gunn" <csg@waterspout.com> Cc: "freebsd-net@FreeBSD.ORG" <freebsd-net@FreeBSD.ORG> Subject: Re: Problems with VLAN and natd. Message-ID: <Pine.BSO.4.10.10101020006440.16350-100000@spider.pilosoft.com> In-Reply-To: <200101020501.AAA58976@tsunami.waterspout.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2 Jan 2001, C. Stephen Gunn wrote: > For example, you would no longer simply ``ifconfig xl'', but > associate a netgraph link-layer node on top of the xl interface, > and a netgraph interface node on top of the link-layer node, which > would function (mostly) like xl does now. Interesting. Possibly that would make freebsd move away from hardware-specific interface names (such as xl0, rl0 ) and make them eth0, eth1, with a generic eth link-layer code to take care of things like ARP and bridging? Would that make sense? Essentially, what an ethernet driver will do is just capturing and sending packets. Then, netgraph "ethllcmac" node attached to it would perform all VLAN tagging/decapsulation and expose a [set of] eth interfaces back to the kernel? I'm thinking of something like this: ngctl mkpeer xl0: ethmacllc raw raw ngctl mkpeer xl0:raw:untagged iface ifconfig ng0 .... ngctl mkpeer xl0:raw:vlan3 iface ifconfig ng1 (the first might have to be set up to be executed on-interface-load) I'm still a bit inebriated...Let me know if I'm completely off-base) > Netgraph is an excellent technology. While your comment makes > sense, there are several issues that will need to be addressed. > For instance, the current ARP implementation in FreeBSD is > entangled with the generic ethernet code. > I'm afraid to even contemplate the POLA and backward compatability > issues involved. I'm afraid to ask, what's POLA? :) 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?Pine.BSO.4.10.10101020006440.16350-100000>