Re: [PATCH] net/ipv4 for Source VIPA support, kernel BK Head

From: Paul Jakma (paul_at_clubi.ie)
Date: 09/02/04

  • Next message: Per von Zweigbergk: "CONFIG_BSD_DISKLABEL not in 2.6.8.1?"
    Date:	Thu, 2 Sep 2004 21:59:17 +0100 (IST)
    To: lkml@einar-lueck.de
    
    

    On Thu, 2 Sep 2004, Einar Lueck wrote:

    > Please apologize: I fear I have not specified the setups we address
    > precisely enough: I think it helps to imagine the following scenario:
    > 1. SERVER1 mounts some NFS stuff exported by SERVER2.
    > 2. SERVER1 has two NICs.
    > 3. The souce IP address of the related packets is the IP address
    > of the NIC the kernel identifies for the outbound route, or the IP
    > address specified via a static route (ip route .... src SVIPA)
    > 4. In case no static routes are allowed and iptables NAT is no
    > option, the relevant packets thus have the IP of a NIC.
    > 5. In case the corresponding NIC dies, we have a serious problem.

    > This is works of course, too. But it does not solve the problem
    > described above. But, maybe I misunderstood you. Please correct me,
    > if I am wrong.

    I dont see why it wouldnt work, it almost undoubtedly will work for
    NFS over TCP. And any problems to cause it to not work would be best
    taking up on the linux-nfs list in order to have a "bind to address"
    option added to knfsd.

    Why would it not work?

    >> hey presto, "virtual IP" which you can redistribute connected in
    >> ospfd/ripd whatever and publish in DNS.
    >
    > I think this is the same as the first point.

    But you must describe why it would not work. *Why*?

    > NFS works in kernel. Therefore we could not intercept the
    > corresponding "connect" calls. As a result, the problem scenario
    > described above could not be solved.

    Why could it not be solved? And why is the answer not "ask the knfsd
    people to provide bind-to-ip option"?

    > You are right, but the packets do not come in, they go out, as I
    > tried to illustrate above. Anyway, in the other case you are
    > completely right.

    But on a server, the packets that go out tend to be replies to
    requests. Or at least, the only packets of interest are replies. It's
    a rare server that just off its own bat goes and talks to clients
    which have not communicated first with the server before.

    Anyway, even if the server for some reason initiated traffic, the
    correct answer surely is "modify the server to bind to a specific
    address", no?

    > Bonding offers a failover facility. For more details, please refer to:
    > Documentation/networking/bonding.txt in the kernel tree.

    Right, but what does bonding (layer 2) have to do with virtual IPs
    and IP source address?

    > Regards
    > Einar

    regards,

    -- 
    Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
    Fortune:
    People say I live in my own little fantasy world... well, at least they
    *know* me there!
     		-- D.L. Roth
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: Per von Zweigbergk: "CONFIG_BSD_DISKLABEL not in 2.6.8.1?"

    Relevant Pages

    • Re: Diagnose co-location networking problem
      ... it was from the client. ... Actually there's significant indication of lost packets and clues that ... 540 retransmit timeouts ... are you using any packetfiltering on the server? ...
      (freebsd-net)
    • Re: Improving FreeBSD NFS performance (esp. directory updates)
      ... >> I don't think the network is at fault, nor is the server really going ... 155645171 data packets ... discarded for bad header offset fields ... 790 connections established ...
      (freebsd-questions)
    • Re: IP Spoofing
      ... That would be enough if the purpose of the request was e.g. to delete a database by SQL injection. ... You would not need to keep it in 7 packets, merely to send in a TCP window - pretty large these days, BUT you would also need to cut in on an existing ESTABLISHED session. ... it is quite possible to send packets to the server without anything. ...
      (comp.lang.php)
    • Re: IP Spoofing
      ... That would be enough if the purpose of the request was e.g. to delete a database by SQL injection. ... You would not need to keep it in 7 packets, merely to send in a TCP window - pretty large these days, BUT you would also need to cut in on an existing ESTABLISHED session. ... it is quite possible to send packets to the server without anything. ...
      (comp.lang.php)
    • Re: CORE-2004-0705: Vulnerabilities in PuTTY and PSCP
      ... difficult to exploit w/o modifying source for an ssl server. ... packets, got hexdumps of the packets, wrote a prog to pretend to be an ssl ... or build packets with the ssl functions used in putty.. ... Vulnerabilities in PuTTY and PSCP ...
      (Vuln-Dev)