[lkml]   [2004]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] net/ipv4 for Source VIPA support, kernel BK Head
    On Thu, Sep 02, 2004 at 02:01:42PM +0200, Einar Lueck wrote:
    > The complexity of the relevant setups necessitates an easy and
    > requirements-driven configuration and solution approach. The overall
    > concept of setting up a virtual device with a virtual IP adress and
    > assigning this virtual IP adress as a Source VIPA to the devices which should
    > allow for a failover is well known from other operating system and expected
    > by relevant enterprise customers. IP routes and NAT allow to achieve the
    > same effect with the exception mentioned above, but the corresponding
    > configuration overhead is in the opinion of customers having enterprise
    > setups too complex and complicated. Our overall approach introduces
    > this concept as a facility to address these requirements very clearly.

    The problem here is not the kernel, it's the awful state of network
    management in the common initscripts and routing daemons, which have not
    evolved far beyond the traditional (static) BSD model of interfaces,
    despite the qualitative leap in functionality brought on by Alexey's
    contributions to Linux 2.2, netfilter and vlans in 2.4, and now IPsec in 2.6.

    While policy routing, traffic control, netfilter, etc., are extremely
    powerful separately and in combination, there is no unified mechanism
    for managing different aspects of network configuration (addressing,
    redundancy, security, QoS, etc.) that cut across each of these kernel

    Several of the routing daemons (Quagga, Bird, etc.) have gotten partway
    there, but none is (AFAIK, correct me if I'm wrong) in a state where
    one can eliminate all of the other networking-related scripts from
    initscripts and just expect the daemon(s) to manage networking.

    It seems that effort would be better spent cleaning up userspace, by
    looking at use cases, identifying the right abstractions, and reifying
    them. Choose a routing daemon, and turn it into a "Network Mgmt daemon".

    Should this be built on top of HAL/D-BUS? I don't know, will HAL/D-BUS
    remain lightweight enough to be used in an embedded router? I sure
    hope so.


    Bill Rugolsky
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:05    [W:0.020 / U:56.020 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site