Date: Mon, 05 Feb 2001 21:23:27 -0800 From: Julian Elischer <julian@elischer.org> To: Luigi Rizzo <rizzo@aciri.org> Cc: patrick@netzuno.com, freebsd-net@FreeBSD.ORG, richw@webcom.com, julian@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? (more info) Message-ID: <3A7F8A4F.94D6729F@elischer.org> References: <200102052153.f15LrCH25651@iguana.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote:
>
> > [Charset iso-8859-15 unsupported, skipping...]
> > Luigi.. does this fix it?
>
> it looks like it essentially reverts to the old (1.75) behaviour,
> which means it does not fix bugs, it is only a workaround to let
> people run kernels with bridging compiled-in as if it was not
> compiled-in.
that's what I wanted..
>
> I think the problem people were (and still will be)
> having is the following:
>
> when bridging is compiled in (and now, when bridging is enabled),
> arp requests do not consider the interface from which the request
> cam from.
>
> This is ok as long as you have bridging enabled on all of your
> interfaces, but there are some cases where you are doing bridging
> separately on clusters of interfaces, and/or no bridging at all on
> others, and then you need to look only at those interfaces which
> belong to the same "logical ethernet" as the IF from which you got
> the packet. This could be a single interface on which bridging is
> disabled, or interfaces with the same cluster-id in
> net.link.ether.bridge_cfg.
A much cleaner solution is netgraph bridging, which disconnects the top
end of all but one of the interfaces from the system, and diverts all
incoming data from the bridged network to come in through that single
interface..
In other words, the bridge machine is just as much fooled by the bridging
as all teh other machines, into thinking that both segments of the bridge
are really a single segment. This is a much better way of doing it
and I think that we should concentrate on adding
the features needed to that, rather than fixing the old
bridging, which was written when there was no alternative.
Now we have a better alternative and I think we should use it instead and
deprecate the old bridge code.
I can add code to the netgraph bridge to allow arbitrary filtering
modules to be added so that shouldn;t be a problem.
>
> If people wonders what is this "cluster-id" -- that code comes
> from some unreleased code that i wrote in 2.2.x times
> which makes FreeBSD work as a VLAN bridge.
> So the cluster-id is essentially the VLAN-ID, and the
> special ID 0 corresponds to a "trunk" (where essentially
> all traffic goes prefixed with the VLAN header).
the whole cluster idea is already present in netgraph, by simply
adding different interfaces on differnet bridge nodes. No extra work is
required. I think that if instead if continuing to add hack on top of
hack for a system that was designed to cope with a world where a hack was
the only possibility, the same effort was put into bringing the netgraph
family of nodes up to scratch, we'd have a much more flexible and
useful system.
I'm biased of course but I think legacy bridging should be
declared a dead-end and left.
>
> cheers
> luigi
>
> >
> >
> >
> > (void)memcpy(&itaddr, ea->arp_tpa, sizeof (itaddr));
> > TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) {
> > #ifdef BRIDGE
> > /*
> > * For a bridge, we want to check the address irrespective
> > * of the receive interface. (This will change slightly
> > * when we have clusters of interfaces).
> > */
> > #define BRIDGE_TEST (do_bridge)
> > #else
> > #define BRIDGE_TEST 0 /* cc will optiise the test away */
> > #endif
> > if ((BRIDGE_TEST) || (ia->ia_ifp == &ac->ac_if)) {
> > maybe_ia = ia;
> > if ((itaddr.s_addr == ia->ia_addr.sin_addr.s_addr) ||
> > (isaddr.s_addr == ia->ia_addr.sin_addr.s_addr)) {
> >
> >
--
__--_|\ Julian Elischer
/ \ julian@elischer.org
( OZ ) World tour 2000-2001
---> X_.---._/
v
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A7F8A4F.94D6729F>