Date: Sat, 29 Apr 2000 19:52:15 +0200 (CEST) From: Luigi Rizzo <luigi@info.iet.unipi.it> To: Robert Watson <rwatson@FreeBSD.org> Cc: Archie Cobbs <archie@whistle.com>, committers@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <200004291752.TAA37925@info.iet.unipi.it> In-Reply-To: <Pine.NEB.3.96L.1000429095802.1309A-100000@fledge.watson.org> from Robert Watson at "Apr 29, 2000 10:24:52 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> > this is interesting. I wonder, though, if your 'bridge0' interface > > is one for the whole machine, or you have one for each cluster > > of interfaces as defined in net.link.ether.bridge_cfg > > You are correct -- I haven't had a chance to really understand the cluster > behavior, but really we should be allocating one bridge interface per > cluster. you are pointing out a lot of interesting things but i believe they require a lot of effort to implement, and the usefulness might not be that general. > > > o IPFW divert/fwd are not implemented ... > intended to pass to a node on the other side or not, and as such if divert > were used to perform a packet transformation (say, a proxy of some sort), > that would fairly seriously break the semantic that both sides of the > bridge see similar things, as well as making it unclear when the proxy but when you implement a filtering bridge you are already breaking the above semantics, and i think 90% of the people using the bridging code under freebsd do so just because it can do filtering. > > > o IPFW DUMMYNET still implicit ACCEPT ... > > you are a committer, arent you :) > > I'm more interested in the, ``fix'' solution, and haven't tried to tackle well the fix should be trivial, just act according to net.inet.ip.fw.one_pass. The reason i forced it to ACCEPT was that this is by far the most common usage, and i did not have the time to check how it would work with cascades of pipes. So, it is probably just "change the gotos and test", but it is very low low priority task in my list... > > > BTW, on the DUMMYNET front, my feeling is that rather than using mbuf ... > > this was done to avoid changing the interface of ip_input() and > > ip_output(), which i really don't think we want to change. ... > Yes -- it's not a big functional change, but I think it would sort out a > few of the layering problems I experienced when cleaning up the > bridge/ipfw code. I.e., when the packet pops out of a pipe, being able to > determine it's an IP packet based on the ethernet type and pass it back there is already a field (pkt->dn_dir) in the fake mbuf which tells you if it came from ip_input, ip_output or bdg_forward. Check usage in ip_dummynet.c:transmit_event(). Do you need something more/different ? > Any thoughts on filtering of outgoing packets to bridged ethernet > segments? It depends I suppose, conceptually, on whether you think of the depending on the output interface you mean ? Implementation would be relatively straightforward, i.e. move the ipfw calls in the loop where you scan interfaces to find the one(s) where the pkt should be retransmitted. However: 1) it really only makes sense for multicast/broadcast traffic, as usually there is only one interface matching a packet for normal traffic; 2) i wonder how useful this is... cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- 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?200004291752.TAA37925>