Routing problem with udp, and a multihomed host in 2.4.20

From: Neil Brown (neilb@cse.unsw.edu.au)
Date: Wed Feb 12 2003 - 18:18:29 EST


I have three subnets. A, B and C.

I have a Linux 2.4.20 server, named bartok, with three interfaces, one
on each subnet (so it can listen to broadcast requests everywhere).

This server has a default route pointing at A.

I have a router that routes between all these subnets, and others.

I have a client that sits on subnet B.

When my client tries to talk to bartok, it might try any of 3 IP
addresses (Due to round-robining in the DNS).

All IP addresses work find when establishing a TCP connection
e.g. telnet or ssh.
They don't for UDP.
  e.g. rpcinfo -u bartok mountd

If I use the address on B, it works fine (as you would expect - same
subnet).
If I use the address on A it works fine (that is the default route
interface).

But if I use the address on C, it doesn't.

What happens is:

    - request goes from client to router
    - request goes from router to bartok interface on C
    - bartok issues an ARP for client on C interface which is WRONG
    - nobody replies to the ARP because client is on B, not C.

If I turn on proxy-arp on the router I can get the reply back, but I
would rather not do that.

So why does a reply to a UDP request arriving on subnet C from some
other subnet try to ARP out on subnet C instead of being routed
normally, while replies to TCP requests get routed properly and work
fine?

Is this a bug, or is there some configuration I can change?

I have double checked the subnet masks and broadcast addresses and
they work fine.
We have rp_filter set to 0 on all interfaces.
forwarding is set to 0, but setting it to 1 makes no difference.

Thanks,
NeilBrown
-
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/



This archive was generated by hypermail 2b29 : Sat Feb 15 2003 - 22:00:45 EST