Date: Thu, 25 Jan 2001 12:19:16 +0100 From: "Rogier R. Mulhuijzen" <drwilco@drwilco.nl> To: Archie Cobbs <archie@dellroad.org> Cc: Julian Elischer <julian@elischer.org>, freebsd-current@FreeBSD.ORG Subject: Re: status of bridge code Message-ID: <4.3.2.7.0.20010125101911.00c84220@mail.bsdchicks.com> In-Reply-To: <200101251737.JAA06204@curve.dellroad.org> References: <4.3.2.7.0.20010125000221.00b07d60@mail.bsdchicks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.3.2.7.0.20010125101911.00c84220>