Re: implementing an aggregating pseudo-device for virtual interfaces ?
Claudio Jeker wrote: On Fri, Sep 15, 2006 at 06:22:05PM +0200, Matthias Bertschy wrote: Would it be possible to implement such a tool that works for tun, gif, gre, pppoe, ... The features would be load balancing and fail over with virtual interfaces. I see no need for this. We have multipath support that already does load balancing. Well, I thought this feature was still unimplemented as of today... (like in 3.6 http://archives.neohapsis.com/archives/openbsd/2004-11/0282.html) Matthias
Re: implementing an aggregating pseudo-device for virtual interfaces ?
On 2006/09/19 14:04, Matthias Bertschy wrote: Claudio Jeker wrote: On Fri, Sep 15, 2006 at 06:22:05PM +0200, Matthias Bertschy wrote: Would it be possible to implement such a tool that works for tun, gif, gre, pppoe, ... The features would be load balancing and fail over with virtual interfaces. I see no need for this. We have multipath support that already does load balancing. Well, I thought this feature was still unimplemented as of today... http://archives.neohapsis.com/archives/openbsd/cvs/2006-06/0469.html
implementing an aggregating pseudo-device for virtual interfaces ?
Hello, From my previous post, it looks like trunk(4) cannot be used for software based pseudo-devices. Would it be possible to implement such a tool that works for tun, gif, gre, pppoe, ... The features would be load balancing and fail over with virtual interfaces. Thanks. Matthias Bertschy
Re: implementing an aggregating pseudo-device for virtual interfaces ?
On Fri, Sep 15, 2006 at 06:22:05PM +0200, Matthias Bertschy wrote: Hello, From my previous post, it looks like trunk(4) cannot be used for software based pseudo-devices. Would it be possible to implement such a tool that works for tun, gif, gre, pppoe, ... The features would be load balancing and fail over with virtual interfaces. I see no need for this. We have multipath support that already does load balancing. The fail over part is a bit more tricky since gif, gre and tun have no link-state. For sppp(4) based interfaces it would be possible to do fail-over via a ifstated triggered script. Later on the routing table will track link-state by itself but this code is not yet written. -- :wq Claudio
