From owner-freebsd-current Thu Jan 25 14: 9:34 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 0C36937B400 for ; Thu, 25 Jan 2001 14:09:09 -0800 (PST) Received: from timbuktu-01.budapest.interware.hu ([195.70.51.193] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 14LuZh-00037P-00; Thu, 25 Jan 2001 23:09:02 +0100 Message-ID: <3A70A3F0.A23A2707@elischer.org> Date: Thu, 25 Jan 2001 14:08:48 -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: Archie Cobbs , freebsd-current@FreeBSD.ORG Subject: Re: status of bridge code References: <4.3.2.7.0.20010125000221.00b07d60@mail.bsdchicks.com> <4.3.2.7.0.20010125101911.00c84220@mail.bsdchicks.com> 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: > > At 09:37 25-1-01 -0800, Archie Cobbs wrote: > >Rogier R. Mulhuijzen writes: > > > But from my list of wishes I'd say the first 3 are gone. All that's > > left is > > > spanning tree. I'm probably going to need this pretty soon, so once more > > > I'm asking if anyone is working on it. If not I'll start on it. > > > >Do you have references for how to do this? As I understand it, there > >are special Ethernet addresses that are "for bridges only -- do not > >forward" that are used to construct the spanning tree, etc. What is > >the "standard" algorithm used by bridges, etc.? > > There's a Spanning Tree Protocol (STP) defined by IEEE 802.1D. I'd prefer > to have that, but I don't have the 1K US$ to shell out for that. > Does BSDi have IEEE subscriptions for FreeBSD developers to use? > > Anyway, even without the IEEE standard I have been able to piece together > how the protocol works. > > First of all bridges might have their own MACs that fall into a certain > range, but STP does not depend on that. The "do not forward" is deducted > from the protocol type. There is an ethernet protocol called BPDU (Bridge > Protocol Data Unit) that each bridge sends and receives, but is not > forwarded by any of them. These BDPUs are used to elect root bridge and > determine root ports and designated ports. > > This results in the blocking of redundant ports so that loops are > eliminated. See http://www.knowcisco.com/content/1578700949/pt02ch06.shtml > for a good overview that's pretty in depth. > > About those blocked ports though I have a question. I've been reading > ng_bridge.c and blocking a link in there (a tad more finegrained than right > now) should not be a problem. But it seems to me that with the bridge.ether > example there might be a problem. I'm using my own situation at home as an > example to sketch this out. Please correct me if I'm wrong. > > 1 real NIC connected to LAN with ed0 as interface > 1 tap device ran by vtun with tap0 as interface > 1 tun device connected to cablemodem with tun0 as interface > > I have a netgraph bridge node that has ed0 and tap0 as interfaces, and ed0 > as local interface (as per the example script) > > This means that packets from kernel to LAN go through the bridge node > (thanks to the link from ed0.upper to the bridge) but packets from the > kernel to the tap0 interface don't go through it (no link from tap0.upper > to bridge). This means the bridge node has no idea where the MAC of the > tap0 device is located (not stored in the MAC table of the bridge). So when > packets directed at my tap0 interface enter the bridge (through the link > from tap0.lower to the bridge) the bridge doesn't have a clue where to send > it, and will thus forward to all links. Thus it will go through ed0.upper > and end up in the kernel, no harm done. BUT it will also go out ed0.lower > and end up in my LAN where it doesn't belong. > > Right now I don't mind because the traffic my cablemodem can handle is > 8KB/s max. But it is not desired behaviour of a bridge. > > What I want to know is can I just link tap0.upper to a new bridge hook? It > seems to me that is the case. yes I believe so.. you can hook as many interfaces as you want to the bridge node. (but you probably don't want to BRIDGE to your cable modem, but to ROUTE to it.... ) > > If that's true the example script should be altered because right now it > doesn't support more than one interface. Just say the word and I'll take > care of it. =) > > > > Also, a quick question for you netgraph guys. Why is it that ng_one2many > > > send a packet only out of one hook? I can see use for an algorithm that > > > sends packets from the 'one' hook to all the 'many' hooks (that are up) > > and > > > keep the normal behaviour for many to one. > > > >Hmm.. you could also get that affect using log2(n) ng_tee(4) nodes.. > > I don't see how though. Lets say I link only to left, right and left2right. > Now when data enters left it will go to both right and left2right. When > data enters right it goes to left. But when data enters left2right it goes > to right, not left, where I want it. no, data entering left2right goes to left. (errrr. At least it did when I wrote it.. if not let me know ) > > DocWilco -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message