From owner-freebsd-current Sat Feb 3 9: 7:15 2001 Delivered-To: freebsd-current@freebsd.org Received: from syncopation-03.iinet.net.au (syncopation-03.iinet.net.au [203.59.24.49]) by hub.freebsd.org (Postfix) with SMTP id 97C7337B4EC for ; Sat, 3 Feb 2001 09:06:49 -0800 (PST) Received: (qmail 27044 invoked by uid 666); 3 Feb 2001 17:14:41 -0000 Received: from reggae-22-22.nv.iinet.net.au (HELO elischer.org) (203.59.87.22) by mail.m.iinet.net.au with SMTP; 3 Feb 2001 17:14:41 -0000 Message-ID: <3A7C3A89.AC30DFDA@elischer.org> Date: Sat, 03 Feb 2001 09:06:17 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: "Rogier R. Mulhuijzen" Cc: freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: Patch for non-netgraph bridge code worthy of attentionforpeople experimenting with bridging setups (including ng_bridge) References: <4.3.2.7.0.20010202205233.00d51c30@mail.drwilco.net> <4.3.2.7.0.20010203122412.00cd4b30@mail.drwilco.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Rogier R. Mulhuijzen" wrote: > [explanation] ok I understand now... I thought you were saying that the netgraph code was acting differently to how I belive it should act. > > > > > Exactly if there's just one interface when netgraph bridging is on. Why? > Why just one interface? Now that my kernel is patched to behave like BRIDGE > wasn't compiled in when I switch it off I can include the upper's of > multiple interfaces in a single netgraph bridge. sure you can. that isn't a problem. It would be a 'brouter' bridging non IP protocols and routing IP. > > If you think about it, this should not even be a problem. > > Look at this diagram http://www.bsdchicks.com/bridge-examples.gif (my > apologies to everyone who can't look at graphical stuff) ok I understan.. my question is: Do you know the girl on http://www.bsdchicks.com/ and is she single? :-) It should be valid.. and I start to see your point. by adding the checks back in (or compiling without BRIDGE) you can have both interfaces.... > > What is the difference between figures 1 and 2? Except that one uses a > switch, and the other uses just a FreeBSD box. yep > > The way packets travel is almost identical. Why wouldn't it be a valid setup? Another possibility would be to make a change to the netgraph bridge code so that it only delivers a broadcast packet to ONE local 'upper' hook. > > You say that interfaces included in the ng_bridge should not have their > upper's included as well, except for one. I didn't mean that they COULDN'T but only that they didn't NEED it > That's all fine for a static > setup, but I'm dealing with a setup where I have a box that's a router > between 2 networks, but sometimes needs to be a bridge as well. If I don't > include the upper for one of the interfaces, outgoing packets on that > interface will not pass my netgraph bridge, resulting in returning packets > to be sent to all hooks on the bridge. I could of course hook my upper to a > hole node, but then I'd have to move it's IP to the other interface. When I > nuke the bridge I'd have to move it back. Why do that if including the > upper in the bridge does the trick. > > Right now my FreeBSD box is routing between 3 networks and sometimes even > bridging between all 3 and it works perfectly. > Using netgraph or the other bridging? I presume Netgraph. > I don't see any reason why multiple uppers can't be included. neither do I, In fact I recommented it to someone yesterday. > > But like I said, my patch has nothing to do with netgraph. When > net.link.ether.bridge == 0 the kernel should behave like a kernel that > doesn't have BRIDGE compiled in it. That's currently not the case and my > patch fixes that. OK I will commit it. > > DocWilco -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message