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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
