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 
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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to