Re: [2.4 PATCH] bugfix: ARP respond on all devices
From: Bill Davidsen (davidsen_at_tmr.com)
Date: 08/20/03
- Previous message: Trond Myklebust: "Re: [NFS] [PATCH] Stop call_decode() from ignorning RPC header errrors"
- In reply to: David S. Miller: "Re: [2.4 PATCH] bugfix: ARP respond on all devices"
- Next in thread: Bas Bloemsaat: "Re: [2.4 PATCH] bugfix: ARP respond on all devices"
- Reply: Bas Bloemsaat: "Re: [2.4 PATCH] bugfix: ARP respond on all devices"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 20 Aug 2003 15:08:03 -0400 (EDT) To: "David S. Miller" <davem@redhat.com>
On Wed, 20 Aug 2003, David S. Miller wrote:
> On Wed, 20 Aug 2003 12:49:14 -0400 (EDT)
> Bill Davidsen <davidsen@tmr.com> wrote:
>
> > On 19 Aug 2003, Daniel Gryniewicz wrote:
> >
> > I have been asking for a similar thing as well, David mentioned some
> > things that would break, but I believe they break if you use source
> > routing, so that seems not to be a real objection.
>
> It's not about source routing. It's about failover and being
> able to use ARP on interfaces which don't have addresses assigned
> to them yet.
David mentioned that you could solve the problem by using *rp_filter and
source routing. I don't think that's entirely true, but doing so has the
same drawbacks and breaks the same things as a flag to make Linux behave
like Sun/BSD/Windows (and work with Cisco is the cases previously
mentioned).
>
> > I find it interesting that we can't change networking because a few
> > complex systems would have to be reconfigured, but we *can* change modules
> > which requires config changes on probably 90% of all systems (commercial
> > distributions).
>
> Decisions about Networking will always be in a different domain
> because the way one behaves has effects upon other systems not
> just the local one.
Yes, that's exactly the point, the way Linux works has bad effects on
certain other machines, as in leaves them disconnected to the Linux
system.
>
> BTW, another thing which makes the source address selection for
> outgoing ARPs a real touchy area is the following. Some weird
> configurations actually respond with different ARP answers based upon
> the source address in the ARP request. You can ask Julian Anastasov
> about such (arguably pathological) setups.
>
I don't think anyone is asking for a change in the default behaviour
(although my point about breaking modules does apply), people would be
satisfied, even ecstatic, if we had a simple way (flag) to set to make
Linux work without setting /proc filters, using arpfilter, applying source
routes (David's suggestion) and generally jumping through hoops.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - 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/
- Previous message: Trond Myklebust: "Re: [NFS] [PATCH] Stop call_decode() from ignorning RPC header errrors"
- In reply to: David S. Miller: "Re: [2.4 PATCH] bugfix: ARP respond on all devices"
- Next in thread: Bas Bloemsaat: "Re: [2.4 PATCH] bugfix: ARP respond on all devices"
- Reply: Bas Bloemsaat: "Re: [2.4 PATCH] bugfix: ARP respond on all devices"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
