Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
On Tuesday 01 August 2006 19:21, you wrote: John W. Linville wrote: I'm just not sure that cleverness is worth the headache, especially since the most clever things usually only work by accident... Or, work by solid, modular design and small tweaks! Point taken. But stashing little hacks in the networking core for specific virtual drivers isn't totally modular either. And even if it were, modular design probably belongs on the list of things that can be taken too far, like everything in userland, never use ioctl, and microkernels are superior. :-) To be honest, I'm not over-joyed to see bridging hooks included in the VLAN code..but if that is what it takes to get bridging and VLANs to play well and be flexible, I think it is a fair price. It certainly wouldn't hurt to have someone take a holistic view of the various L2 device interactions. Just documenting current functionality on, say, the netdev wiki would be a good first step. Ultimate flexibility could be provided by making the netif_rx routine (and the others, including vlan etc), a virtual routine. That way a list of filters could be defined that allow any processing to be done on the packet before it is handed of to the linux kernel's higher layers, including not delivering it on that interface, or delivering it on another interface. This would allow very complex implementations including stuff like a high-level l2 bridge, with vlan support, and a number of protocols like rstp, pvst+, ... with relatively simple code, that could be isolated from the main kernel. Would anyone be interested in signing off on such a patch ? (which basically creates netif_rx and vlan_acc_netif_rx lists in the net_device structure, and then modify bridging and bonding drivers to just use this) Regards, Christophe - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
On Mon, Jul 31, 2006 at 09:39:08PM -0400, Jamal Hadi Salim wrote: On Mon, 2006-31-07 at 08:30 -0400, John W. Linville wrote: Do we hold the view that our L2 code is on par with the rest of our code? Is there an appetite for a clean-up? Or is it just me? /rant If you made it this far, thanks for listening...I feel better now. :-) Yes, I made it this far and you do make good arguement (or i may be over-dosed ;-). I have seen the following setups that are useful: 1) Vlans with bridges; in which one or more vlans exist per ethernet port. Broadcast packets within such vlans are restricted to just those vlans by the bridge. 2) complicate the above a little by having multiple spanning trees. 3) Add to the above link layer HA (802.1ad or otherwise as presented today by Bonding). To answer your question; i think yes we need all 3. Oh, don't get me wrong -- I definitely think we need all three. I'm just not sure we need every conceivable combination of a) bonds of vlan interfaces; b) vlan interfaces on top of bonds; c) bridged vlan interfaces w/ disparate vlan IDs; d) bonded vlan interfaces w/ disparate vlan IDs; e) bonded bridge interfaces (does this work?) f) bonded bonds (seen customers trying to do it); g) bridged vlan interfaces; h) bridged bonds; i) bridged bridges (probably doesn't work, but someone probably wants it); j) vlan interfaces on top of bridges; k) vlan interfaces on top of vlans (double vlan tagging); and, l) what am I leaving out? Most (actually all afaik) L2 networking equipment enforces some hierarchy on the relationship between these L2 entities. I am more and more convinced we should do the same, although I do acknowledge that the current situation does allow for some cleverness. I'm just not sure that cleverness is worth the headache, especially since the most clever things usually only work by accident... Unfortunately the 3 above are all done by different people with different intentions altogether. I think BGrears end goal was VLANs for an end host. I think Lennert wrote the original Bridge code and for a while had some VLAN code that worked well with bridging (that code died as far as i know). Then bonding - theres some pre-historic relation to it since D Becker days and then the good folks from Intel adding about 1M features to it. Yes, the fact all 3 need to work together is a mess ;- (but there are good pragmatic reasons for them to work together)... I'm sure you are correct -- each entity was developed to serve its purpose, and each does so admirably on its own. The fact that they work together is a desirable miracle. There is no doubt that we need to be able to do all three (vlan, bridge, bond) at once. I'm just not convinced we need to support stacking them in every conceivable order. And, I think that a reconsideration of all three functions as a group could lead to better/cleaner functionality with easier support for extension (e.g. 802.1s). Well, I'll guit now before I get sent-off to the visionaries list. I am putting some thought to this, but I'm not yet far enough along to sound coherent... :-) John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
On Tue, 2006-01-08 at 08:08 -0400, John W. Linville wrote: [..] There is no doubt that we need to be able to do all three (vlan, bridge, bond) at once. I'm just not convinced we need to support stacking them in every conceivable order. In theory there should be no issues stacking netdevices in any order you want. In other words the hooks for doing so exist (albeit in some limited way[1]). Practically, some of the topologies of interconnected netdevices dont make a lot of sense. The danger is in restricting how the stacking happens and overlooking some future creative use. Safer to let the user own the policy and configure any way they want aka shoot themselves in the foot. And, I think that a reconsideration of all three functions as a group could lead to better/cleaner functionality with easier support for extension (e.g. 802.1s). Agreed. I have some very strong opinions on this subject that i could share with you if you want. For example, IMO, I think it would be a lot reasonable to assume that a VLAN or VLANS are attributes of a netdevice (just like IP addresses or MAC addresses are). cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
Jamal Hadi Salim wrote: On Tue, 2006-01-08 at 08:08 -0400, John W. Linville wrote: [..] There is no doubt that we need to be able to do all three (vlan, bridge, bond) at once. I'm just not convinced we need to support stacking them in every conceivable order. In theory there should be no issues stacking netdevices in any order you want. In other words the hooks for doing so exist (albeit in some limited way[1]). Practically, some of the topologies of interconnected netdevices dont make a lot of sense. The danger is in restricting how the stacking happens and overlooking some future creative use. Safer to let the user own the policy and configure any way they want aka shoot themselves in the foot. And, I think that a reconsideration of all three functions as a group could lead to better/cleaner functionality with easier support for extension (e.g. 802.1s). Agreed. I have some very strong opinions on this subject that i could share with you if you want. For example, IMO, I think it would be a lot reasonable to assume that a VLAN or VLANS are attributes of a netdevice (just like IP addresses or MAC addresses are). As might be expected, I feel that VLANs are much more useful as full-featured net devices. I do not believe it is worth decreasing functionality to try to 'clean up' the code. There are people doing interesting things with the mentioned virtual devices that the original developers of the individual parts never envisioned, but I see that only as a resounding success and validation of the architecture. It is true that there are some interesting issues about where you add the hooks to slurp up vlan, bridged, bonded and other type of virtual device packets. At least for some of my out-of-the-tree virtual lan devices (mac-vlan, in particular), I thought it would be useful to allow dynamic registration of the layer-2 hooks such as bridging. This way, where there is no logical way to determine which virtual interface should get first chance at a packet, the user can provide the ordering by adjusting where the hooks sit in the chain. Last time I mentioned this feature, it was pointed out that the net-filter hooks provide, or come close to providing, this ability to stack. If someone wants to work on virtual device priority, it might be worth investigating this further and create an API that makes this usable from kernel and user-space. Thanks, Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
John W. Linville wrote: On Mon, Jul 31, 2006 at 09:39:08PM -0400, Jamal Hadi Salim wrote: On Mon, 2006-31-07 at 08:30 -0400, John W. Linville wrote: Do we hold the view that our L2 code is on par with the rest of our code? Is there an appetite for a clean-up? Or is it just me? /rant If you made it this far, thanks for listening...I feel better now. :-) Yes, I made it this far and you do make good arguement (or i may be over-dosed ;-). I have seen the following setups that are useful: 1) Vlans with bridges; in which one or more vlans exist per ethernet port. Broadcast packets within such vlans are restricted to just those vlans by the bridge. 2) complicate the above a little by having multiple spanning trees. 3) Add to the above link layer HA (802.1ad or otherwise as presented today by Bonding). To answer your question; i think yes we need all 3. Oh, don't get me wrong -- I definitely think we need all three. I'm just not sure we need every conceivable combination of a) bonds of vlan interfaces; b) vlan interfaces on top of bonds; c) bridged vlan interfaces w/ disparate vlan IDs; d) bonded vlan interfaces w/ disparate vlan IDs; e) bonded bridge interfaces (does this work?) f) bonded bonds (seen customers trying to do it); g) bridged vlan interfaces; h) bridged bonds; i) bridged bridges (probably doesn't work, but someone probably wants it); j) vlan interfaces on top of bridges; k) vlan interfaces on top of vlans (double vlan tagging); and, l) what am I leaving out? Well, if it makes you feel better, I can't see a good way to do vlans-over-vlans cleanly, backwards compatibly, and functional with bridging, etc. I would not plan to add such a feature to the kernel unless from it's moment of inclusion it could handle at least bridging, either. So that feature will probably not see the light of day any time soon :) Most (actually all afaik) L2 networking equipment enforces some hierarchy on the relationship between these L2 entities. I am more and more convinced we should do the same, although I do acknowledge that the current situation does allow for some cleverness. Very often, the answer to difficult networking issues is to 'get a linux box', since that very flexibility is often key to interesting problems. I'm just not sure that cleverness is worth the headache, especially since the most clever things usually only work by accident... Or, work by solid, modular design and small tweaks! Thanks, Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
On Tue, Aug 01, 2006 at 08:33:34AM -0400, Jamal Hadi Salim wrote: On Tue, 2006-01-08 at 08:08 -0400, John W. Linville wrote: And, I think that a reconsideration of all three functions as a group could lead to better/cleaner functionality with easier support for extension (e.g. 802.1s). Agreed. I have some very strong opinions on this subject that i could share with you if you want. For example, IMO, I think it would be a lot reasonable to assume that a VLAN or VLANS are attributes of a netdevice (just like IP addresses or MAC addresses are). I'd love to hear them. Feel free to send them off list, since I know how shy you can be... :-) John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
On Tue, Aug 01, 2006 at 09:10:06AM -0700, Ben Greear wrote: Jamal Hadi Salim wrote: Agreed. I have some very strong opinions on this subject that i could share with you if you want. For example, IMO, I think it would be a lot reasonable to assume that a VLAN or VLANS are attributes of a netdevice (just like IP addresses or MAC addresses are). As might be expected, I feel that VLANs are much more useful as full-featured net devices. I do not believe it is worth decreasing functionality to try to 'clean up' the code. In general, I agree that we shouldn't lose functionality. I'm curious as to what particularly functionality you fear would be lost if VLANs were not implemented the way they are now? Thanks, John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
John W. Linville wrote: On Tue, Aug 01, 2006 at 09:10:06AM -0700, Ben Greear wrote: Jamal Hadi Salim wrote: Agreed. I have some very strong opinions on this subject that i could share with you if you want. For example, IMO, I think it would be a lot reasonable to assume that a VLAN or VLANS are attributes of a netdevice (just like IP addresses or MAC addresses are). As might be expected, I feel that VLANs are much more useful as full-featured net devices. I do not believe it is worth decreasing functionality to try to 'clean up' the code. In general, I agree that we shouldn't lose functionality. I'm curious as to what particularly functionality you fear would be lost if VLANs were not implemented the way they are now? Well, Jamal and I and others discussed this in depth in the 2.4.12 time frame when VLANs where about to go into the kernel. Basically, my point is that if VLANs are true devices, they will just work with all of the user-space protocols and they will easily handle abstractions such as bridges, (multiple) IP addresses, MAC addresses, net-filter, and all the rest. Sounds like Jamal still remembers his reasons for wanting it otherwise...so will let him describe his reasons. Nothing is set in stone in Linux, and I am certainly not the final arbiter of what gets into the linux kernel, but in my opinion, the current VLAN architecture is supperior to the ip-alias model, and I see no reason to make any significant changes. Ben Thanks, John -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
John W. Linville wrote: I'm just not sure that cleverness is worth the headache, especially since the most clever things usually only work by accident... Or, work by solid, modular design and small tweaks! Point taken. But stashing little hacks in the networking core for specific virtual drivers isn't totally modular either. And even if it were, modular design probably belongs on the list of things that can be taken too far, like everything in userland, never use ioctl, and microkernels are superior. :-) To be honest, I'm not over-joyed to see bridging hooks included in the VLAN code..but if that is what it takes to get bridging and VLANs to play well and be flexible, I think it is a fair price. It certainly wouldn't hurt to have someone take a holistic view of the various L2 device interactions. Just documenting current functionality on, say, the netdev wiki would be a good first step. Thanks, Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
Ben Greear [EMAIL PROTECTED] writes: Basically, my point is that if VLANs are true devices, they will just work with all of the user-space protocols and they will easily handle abstractions such as bridges, (multiple) IP addresses, MAC addresses, net-filter, and all the rest. AOL mode I think the same. -- Krzysztof Halasa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
On Mon, Jul 31, 2006 at 10:15:40AM +0200, Christophe Devriese wrote: If you bond 2 vlan subinterfaces, the patch is not necessary at all. In that case also the source device will be changed from eth0.vlan to bondx. So that's correct behavior no ? In the second case, you create vlan subifs on a bonding device, vlan subinterfaces will be created on the slave interfaces. In that case the vlan (This is not directed at Christophe, or anyone in particular...) rant Am I the only one that thinks that our handling of LAN L2 stuff is at best a little too flexible (and at worst a collection of nasty hacks)? I mean, do we really need both the ability to bond multiple vlan interfaces AND the ability to have vlan interfaces on top of a bond? How many people really appreciate the subtle(?) differences? Then throw bridging into the mix! If I'm using VLANs and bonds in a bridged environment, do I bridge the bonds, or bond the bridges? Do the VLANs come before the bonds? after the bridges? or somewhere in-between? Do all these combinations even work together? Who has the definitive answer (besides the code itself)? I have no doubt that there are plenty of opportunities for cleverness here (and no doubt dragons too). I just doubt that most of them are worth the complexities introduced by our current collection of transparently stackable pseudo-drivers and strategically placed hacks (e.g. skb_bond). All that, and it still isn't clear to me how we can cleanly accomodate 802.1s (which adds VLAN awareness to bridging). Do we hold the view that our L2 code is on par with the rest of our code? Is there an appetite for a clean-up? Or is it just me? /rant If you made it this far, thanks for listening...I feel better now. :-) John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
On Monday 31 July 2006 14:30, you wrote: (This is not directed at Christophe, or anyone in particular...) rant Am I the only one that thinks that our handling of LAN L2 stuff is at best a little too flexible (and at worst a collection of nasty hacks)? I mean, do we really need both the ability to bond multiple vlan interfaces AND the ability to have vlan interfaces on top of a bond? How many people really appreciate the subtle(?) differences? Then throw bridging into the mix! If I'm using VLANs and bonds in a bridged environment, do I bridge the bonds, or bond the bridges? In all honesty, you cannot bond bridges :-p Do the VLANs come before the bonds? after the bridges? or somewhere in-between? Do all these combinations even work together? Who has the definitive answer (besides the code itself)? I have no doubt that there are plenty of opportunities for cleverness here (and no doubt dragons too). I just doubt that most of them are worth the complexities introduced by our current collection of transparently stackable pseudo-drivers and strategically placed hacks (e.g. skb_bond). All that, and it still isn't clear to me how we can cleanly accomodate 802.1s (which adds VLAN awareness to bridging). Do we hold the view that our L2 code is on par with the rest of our code? Is there an appetite for a clean-up? Or is it just me? A vlan capable bridge with trunk ports and access ports would be nice :-p I think the current code is nice. You need it to properly support virtualization and I find it very useful where I work to have this option. Regards, Christophe - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
On Mon, 2006-31-07 at 08:30 -0400, John W. Linville wrote: On Mon, Jul 31, 2006 at 10:15:40AM +0200, Christophe Devriese wrote: If you bond 2 vlan subinterfaces, the patch is not necessary at all. In that case also the source device will be changed from eth0.vlan to bondx. So that's correct behavior no ? In the second case, you create vlan subifs on a bonding device, vlan subinterfaces will be created on the slave interfaces. In that case the vlan (This is not directed at Christophe, or anyone in particular...) rant Am I the only one that thinks that our handling of LAN L2 stuff is at best a little too flexible (and at worst a collection of nasty hacks)? I mean, do we really need both the ability to bond multiple vlan interfaces AND the ability to have vlan interfaces on top of a bond? How many people really appreciate the subtle(?) differences? Then throw bridging into the mix! If I'm using VLANs and bonds in a bridged environment, do I bridge the bonds, or bond the bridges? Do the VLANs come before the bonds? after the bridges? or somewhere in-between? Do all these combinations even work together? Who has the definitive answer (besides the code itself)? I have no doubt that there are plenty of opportunities for cleverness here (and no doubt dragons too). I just doubt that most of them are worth the complexities introduced by our current collection of transparently stackable pseudo-drivers and strategically placed hacks (e.g. skb_bond). All that, and it still isn't clear to me how we can cleanly accomodate 802.1s (which adds VLAN awareness to bridging). Do we hold the view that our L2 code is on par with the rest of our code? Is there an appetite for a clean-up? Or is it just me? /rant If you made it this far, thanks for listening...I feel better now. :-) Yes, I made it this far and you do make good arguement (or i may be over-dosed ;-). I have seen the following setups that are useful: 1) Vlans with bridges; in which one or more vlans exist per ethernet port. Broadcast packets within such vlans are restricted to just those vlans by the bridge. 2) complicate the above a little by having multiple spanning trees. 3) Add to the above link layer HA (802.1ad or otherwise as presented today by Bonding). To answer your question; i think yes we need all 3. Unfortunately the 3 above are all done by different people with different intentions altogether. I think BGrears end goal was VLANs for an end host. I think Lennert wrote the original Bridge code and for a while had some VLAN code that worked well with bridging (that code died as far as i know). Then bonding - theres some pre-historic relation to it since D Becker days and then the good folks from Intel adding about 1M features to it. Yes, the fact all 3 need to work together is a mess ;- (but there are good pragmatic reasons for them to work together)... Hope that helps ;- cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
