On Mon, 4 Sep 2000, Andi Kleen wrote:
> > /proc/sys/net/ipv4/\"correct\"_arp_reply_interface_selection
> It is called arpfilter. Here is the old 2.2.16 version (applies to 2.4
> with minor changes)
>
> It is useful for various things, one of them being automatic load
> balancing for incoming con
On Tue, 5 Sep 2000, David Luyer wrote:
> So if I want it to work I most likely need to make the ARP request ignore
> the higher level bindings of the socket.
>
or just set a route pointing net d.e.f to ethX.
> David.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Hello,
On Tue, 5 Sep 2000, David Luyer wrote:
>
> > just try "traceroute -s 111.111.111.111 d.e.f.2"
>
> > What shows this simple test?
> >
> > arp who-has d.e.f.2 tell a.b.c.1
> >
> > or
> >
> > arp who-has d.e.f.2 tell d.e.f.1
>
> When I tried traceroute -s d.e.f.1 d.e.f.2, it
(OK, I've read enough of this crap.)
On Sat, 2 Sep 2000, David Luyer wrote:
>I'm seeing a problem between Linux 2.2 and BSD/OS 4.1 in the situation on one
>of our backbones.
Why is it the people placed in charge of networks usually have no clue
how they work? (don't answer that.)
[broken netwo
> just try "traceroute -s 111.111.111.111 d.e.f.2"
> What shows this simple test?
>
> arp who-has d.e.f.2 tell a.b.c.1
>
> or
>
> arp who-has d.e.f.2 tell d.e.f.1
When I tried traceroute -s d.e.f.1 d.e.f.2, it worked, the first time the
Linux box in question talked to the BSD/OS
Hello,
Looking in inet_select_addr() it seems that ifa->ifa_local
is selected according to the target. So, may be the problem is not
that the announced address in the ARP request is the primary address.
Someone already selected the primary address before arp_solicit.
Because arp_
(Alan Cox)
(Matt Kirkwood)
> > Please forgive my obtuseness, but I am unable to conceive of
> > one (beyond checking that your routing is symmetrical :-)
>
> Multiple virtual hosts, routing for tunnels
And how is this in any way broken by arp-ing from the first interface
address (in terms of w
> Please forgive my obtuseness, but I am unable to conceive of
> one (beyond checking that your routing is symmetrical :-)
Multiple virtual hosts, routing for tunnels
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Pleas
On Mon, Sep 04, 2000 at 10:57:44AM +0100, Matthew Kirkwood wrote:
> > > With both interfaces up, it's impossible to apply anti-martian
> > > rules to the interfaces, since it's hard to predict which card
> > > will answer an ARP request.
> >
> > /proc/sys/net/ipv4/.../hidden
>
> So when lightning
On Sat, 2 Sep 2000, Alan Cox wrote:
> > I see the point, but it bites sufficiently often that I don't
> > understand why there is no interesting in improving this
> > behaviour.
>
> For a large number of scenarios it makes vastly more sense.
Please forgive my obtuseness, but I am unable to conce
On Mon, Sep 04, 2000 at 05:47:00PM +0800, Andrey Savochkin wrote:
> On Mon, Sep 04, 2000 at 11:22:31AM +0200, Andi Kleen wrote:
> > On Mon, Sep 04, 2000 at 05:06:15PM +0800, Andrey Savochkin wrote:
> > > So, I think that we have to be sure that we use the "best" address for this
> > > destination.
On Mon, Sep 04, 2000 at 11:22:31AM +0200, Andi Kleen wrote:
> On Mon, Sep 04, 2000 at 05:06:15PM +0800, Andrey Savochkin wrote:
> > So, I think that we have to be sure that we use the "best" address for this
> > destination.
> > What about an unconditional use of inet_select_addr() or fib_select_a
On Mon, Sep 04, 2000 at 05:06:15PM +0800, Andrey Savochkin wrote:
> So, I think that we have to be sure that we use the "best" address for this
> destination.
> What about an unconditional use of inet_select_addr() or fib_select_addr()
> based on prefsrc with inet_select_addr() fallback?
It looks
Andi,
On Mon, Sep 04, 2000 at 10:45:06AM +0200, Andi Kleen wrote:
> On Mon, Sep 04, 2000 at 10:22:42AM +0800, Andrey Savochkin wrote:
> > Andi, there may be two reasons of this behavior:
> > 1. skb that triggered ARP request had a.b.c.1 source, either because
> >a) the socket had been bound t
On Mon, Sep 04, 2000 at 10:22:42AM +0800, Andrey Savochkin wrote:
> Andi, there may be two reasons of this behavior:
> 1. skb that triggered ARP request had a.b.c.1 source, either because
>a) the socket had been bound to that address, or
>b) preferred source in the routing table is wrong;
Rogier Wolff wrote:
> Hmm. Doesn't the spec say something about that you should preferrably
> use the "closest" IP number that you can find to communicate with a
> host?
>
> Yes, adding a route to "a.b.c.1 gw d.e.f.1" on the BSD box should
> work.
>
> But having a multi-homed host with a.b.c.1 on
Alan Cox wrote:
> > Now when the Linux box a.b.c.1 (with secondary address d.e.f.1) wants to
> > talk to the BSD/OS system d.e.f.2 it does
> >
> > a.b.c.1 arp who-has d.e.f.2
>
> That is presumably what your routing table says, that both are reachable via
> the ethernet
>
> > Which d.e.f.2
Hi,
On Sat, Sep 02, 2000 at 01:05:02PM +0200, Andi Kleen wrote:
> On Sat, Sep 02, 2000 at 12:28:00PM +1100, David Luyer wrote:
[snip]
> > Now when the Linux box a.b.c.1 (with secondary address d.e.f.1) wants to
> > talk to the BSD/OS system d.e.f.2 it does
> >
> > a.b.c.1 arp who-has d.e.f.2
On Sat, Sep 02, 2000 at 05:10:19PM +0100, Alan Cox wrote:
> > With both interfaces up, it's impossible to apply anti-martian
> > rules to the interfaces, since it's hard to predict which card
> > will answer an ARP request.
>
> /proc/sys/net/ipv4/.../hidden
Where is this file? A cursory glance
> I see the point, but it bites sufficiently often that I don't
> understand why there is no interesting in improving this
> behaviour.
For a large number of scenarios it makes vastly more sense.
> With both interfaces up, it's impossible to apply anti-martian
> rules to the interfaces, since it
On Sat, 2 Sep 2000, Alan Cox wrote:
> Fix your routing tables ?
and several other people have said similar things in the past.
I see the point, but it bites sufficiently often that I don't
understand why there is no interesting in improving this
behaviour.
I have several hosts with multiple or
Andi Kleen wrote:
> > According to the standards, who is in the wrong? To me it looks like Linux
> > is the misbehaved OS in this case.
>
> Strictly it is your routing which is wrong, because you're giving different
> routing information to BSDI and Linux.
Thanks for the workaround. Unfortuna
On Sat, Sep 02, 2000 at 12:28:00PM +1100, David Luyer wrote:
>
> I'm seeing a problem between Linux 2.2 and BSD/OS 4.1 in the situation on one
> of our backbones.
>
> We have a number of Linux hosts on this backbone with a primary address in
> the network a.b.c.0/24 and a secondary address in t
> Now when the Linux box a.b.c.1 (with secondary address d.e.f.1) wants to
> talk to the BSD/OS system d.e.f.2 it does
>
> a.b.c.1 arp who-has d.e.f.2
That is presumably what your routing table says, that both are reachable via
the ethernet
> Which d.e.f.2 promptly ignores, presumably becau
Hello,
On Sat, Sep 02, 2000 at 12:28:00PM +1100, David Luyer wrote:
[snip]
> We have a number of Linux hosts on this backbone with a primary address in
> the network a.b.c.0/24 and a secondary address in the network d.e.f.0/24.
[snip]
> a.b.c.1 arp who-has d.e.f.2
>
[snip]
> Is this already
I'm seeing a problem between Linux 2.2 and BSD/OS 4.1 in the situation on one
of our backbones.
We have a number of Linux hosts on this backbone with a primary address in
the network a.b.c.0/24 and a secondary address in the network d.e.f.0/24.
We also have some BSD/OS 4.1 machines in this net
26 matches
Mail list logo
