Re: status of bridge code
Hi, Is there any documentation (or better, a HOWTO) on how to get firewall functionality with netgraph bridging? I have DSL and 8 addresses and I like the front machine to act as the firewall. I have this with the old bridge and ipfw but as has been said before, it has problems. Thanks, Boyd On Wed, Jan 24, 2001 at 02:03:40PM -0800, Julian Elischer wrote: > "Thomas T. Veldhouse" wrote: > > > > > Have a look at what you can do with netgraph first. > > > > > > Most people don't know what it is but it allows almost arbitrarily > > > complicated network topologies to be set up from the command line. > > > > > > > > > > Is there any reasonable documentation or a HOWTO on the usage of netgraph? > > I am currently using the standard bridging code and IPFIREWALL (ipfw) with > > my dc cards. No problems so far - as long as I don't use DUMMYNET with it. > > I really wish I could use DUMMYNET as I need to put bandwidth limits on a > > few of the computers on my network. > > /usr/share/examples/netgraph > man 4 netgraph > man 4 ng_bridge > (etc.) > also a daemon-news article on how it works. > > > Rate limitting is one thing that isn't there yet. If we pulled our fingers out, > I guess we would have ripped the dummynet rate limmiter out of where it is > and placed it into a netgraph node where it would be generally useful > instead of being hardcoded into one (sometimes useful) localtion in the > netoworking stacks. > > there is a rate limitter based on netgraph available from: > http://www.riss-telecom.ru/~vitaly/ > > but I have not tried it. > > I need to look at it again as I believe it has improved and > may be generally useful. > When I looked at it last it was a bit alpha. > It probably needs rewriting for the new netgraph API in -current. > > > > > > > > Tom Veldhouse > > [EMAIL PROTECTED] > > -- > __--_|\ Julian Elischer > / \ [EMAIL PROTECTED] > ( OZ) World tour 2000 > ---> X_.---._/ from Perth, presently in: Budapest > v > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- Boyd Faulkner"The Gods don't drag people, The Gods [EMAIL PROTECTED]sucker punch them until the poor fools http://asgard.hos.net/~faulkner pay attention and do it for themselves." 1011101- Soror Sia To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
> I'd be happy to (I like a challenge) but I still require access to the > standards for that. So my question still stands, does BSDi have IEEE > subscriptions for FreeBSD developers to use, or are there any other ways > for me to aquire (legally of course) the standards I need without having to > shell out the 1K US$ myself. You can probably find good sources of informations around on the net. Cisco comes immediately to my mind, 3Com and redbooks.com are also very likely to have. I'd also check ethereal sources, where packet-bpdu.c includes most of what you need to start interpreting packets you receive, and send new ones (well, you also need llcsaps.h and oui.h). Speaking of 802.1G (BCP) you should look at RFC2878... wait, checking on that again, I just found out that this is THE document for bridging, so start from that ;-) Also, RFC 1638 documents the old STP protocol. Even though I could find nothing more in RFCs, a quick tcpdump confirmed that most STP involves broadcasts to 01-80-c2-00-00-00. > I'd probably go for the Cisco defaults. And there are lots of netgraph > nodes with settings you can change. So I'd consider being able to change > the values pretty much a given. =) Ok. As I said, I know quite well bridging from my Cisco certifications days, but no experience with netgraph ;-) > > Duly noted. I recall reading that 802.1Q extends the 802.1D standardble to > understand VLANs, but that most implementations still use a single STP > instance. Cisco of course uses multiple instances (did I read this on a > Cisco related site? n =) ). Yes, implementation dependant. > > >Having said that, while I am not able to help in writing code (no time to > >learn netgraph, sorry), I will be more than happy to test it, having a > >home network comprising a -current box with 4 ethernet ports and 3 or 4 > >differents brands / models of hubs/switches. > > I'll drop you a line when the time comes. Ok. Please keep me updated. Bye, Andrea -- 0 and 1. Now what could be so hard about that? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
> > > 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? > >Please also consider implementing 802.1G, which is for bridging over PPP >(BCP I think?). I think a lot of us remember the times when remote bridging >was more common than routing ;-) I'd be happy to (I like a challenge) but I still require access to the standards for that. So my question still stands, does BSDi have IEEE subscriptions for FreeBSD developers to use, or are there any other ways for me to aquire (legally of course) the standards I need without having to shell out the 1K US$ myself. > > 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. > >Any Cisco documentation will go into depth explaining the tradeoffs in >deciding the timing for the various state (STP is, in the end, a state >automaton) depending on the exact topology. You should be careful when >deciding defaults, and you should implement a way to adjust them. I'd probably go for the Cisco defaults. And there are lots of netgraph nodes with settings you can change. So I'd consider being able to change the values pretty much a given. =) >Also, FreeBSD has support for 802.1q VLAN tagging. Having 802.1q trunks in >your network means you (usually) have more than 1 instance of STP. >Furthermore, >this means that even if you don't care about 802.1q, you should be prepared to >receive BPDU-like backets which are NOT part of the 802.1d exchange (unless my >mind is playing tricks on me, that is). Of course you can choose not to handle >all of this but then the implementation would be less useful in the real >world. Duly noted. I recall reading that 802.1Q extends the 802.1D standardble to understand VLANs, but that most implementations still use a single STP instance. Cisco of course uses multiple instances (did I read this on a Cisco related site? n =) ). >Having said that, while I am not able to help in writing code (no time to >learn netgraph, sorry), I will be more than happy to test it, having a >home network comprising a -current box with 4 ethernet ports and 3 or 4 >differents brands / models of hubs/switches. I'll drop you a line when the time comes. DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
On Thu, Jan 25, 2001 at 12:19:16PM +0100, 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? Please also consider implementing 802.1G, which is for bridging over PPP (BCP I think?). I think a lot of us remember the times when remote bridging was more common than routing ;-) > 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. Any Cisco documentation will go into depth explaining the tradeoffs in deciding the timing for the various state (STP is, in the end, a state automaton) depending on the exact topology. You should be careful when deciding defaults, and you should implement a way to adjust them. Also, FreeBSD has support for 802.1q VLAN tagging. Having 802.1q trunks in your network means you (usually) have more than 1 instance of STP. Furthermore, this means that even if you don't care about 802.1q, you should be prepared to receive BPDU-like backets which are NOT part of the 802.1d exchange (unless my mind is playing tricks on me, that is). Of course you can choose not to handle all of this but then the implementation would be less useful in the real world. Having said that, while I am not able to help in writing code (no time to learn netgraph, sorry), I will be more than happy to test it, having a home network comprising a -current box with 4 ethernet ports and 3 or 4 differents brands / models of hubs/switches. Bye, Andrea -- There's no place like ~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
"Rogier R. Mulhuijzen" wrote:
>
> > > 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 )
>
> Don't worry =)
>
> I do want to bridge to the tunnel that goes over my cable modem though.
> Make a real VPN there. (And yeah encrypted links)
>
> > > 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.
> >(e. At least it did when I wrote it.. if not let me know )
>
> From ng_tee(4)
>
> Packets may also be received on right2left and left2right; if so, they
> are forwarded unchanged out hooks left and right, respectively.
>
> packets on left2right are delivered on right
>
> And to be sure I checked ng_tee.c:
>
> } else if (hinfo == &sc->left2right) {
> dup = NULL;
> dest = &sc->right;
> }
>
> I'll just add the algorithm to ng_tee...
then I screwed it..
packets from left should go to left2right and packates from left2right should
go
backk to left..
But we haven't ever used that so it may be in error.
>
> DocWilco
--
__--_|\ Julian Elischer
/ \ [EMAIL PROTECTED]
( OZ) World tour 2000
---> X_.---._/ from Perth, presently in: Budapest
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
> > 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 )
Don't worry =)
I do want to bridge to the tunnel that goes over my cable modem though.
Make a real VPN there. (And yeah encrypted links)
> > 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.
>(e. At least it did when I wrote it.. if not let me know )
From ng_tee(4)
Packets may also be received on right2left and left2right; if so, they
are forwarded unchanged out hooks left and right, respectively.
packets on left2right are delivered on right
And to be sure I checked ng_tee.c:
} else if (hinfo == &sc->left2right) {
dup = NULL;
dest = &sc->right;
}
I'll just add the algorithm to ng_tee...
DocWilco
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
"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. (e. At least it did when I wrote it.. if not let me know ) > > DocWilco -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
Rogier R. Mulhuijzen writes: > >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. Think of each tee node as a 2x packet doubler, then hook them up like this: --- o --- \ o-- \ o \ o-- \ o \ o-- \ o I.e., only use "left", "right", and "left2right". -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
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
Re: status of bridge code
>this would be a REALLY easy node to write...maybe your first? >(see how 'ng_tee' works and ng_one2many, and >write one that does something in between. I was thinking adding an algorithm to one2many. DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
Archie Cobbs wrote: > > Rogier R. Mulhuijzen writes: > > > 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. this would be a REALLY easy node to write...maybe your first? (see how 'ng_tee' works and ng_one2many, and write one that does something in between. -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
"Rogier R. Mulhuijzen" wrote: > > >personally I use the netgraph bridging code and I think (though I'm biased) > >that you should look at using htat rather than the hardwired bridging > >code that it was derived from. > > Now that I've read up on it I can tell you you and and Archie have every > right to be biased =) > > I've had a netgraph bridge in place for a while now and it works very well. > (On 4.X-STABLE, on 5.X-CURRENT it went kablooie. See panic trace) where is it? (have you tried it REALLY recently?) > > > > item on my list. Being an allround good networking OS this is unacceptable > > > IMHO. > > > >Have a look at what you can do with netgraph first. > > > >Most people don't know what it is but it allows almost arbitrarily > >complicated network topologies to be set up from the command line. > > What you might want to tell people is that it allows networking structures > to be setup in a simple manner, but is so powerful it can also be used for > immensely complex structures. A friend and fellow BSD user of mine's first > response was "I like to keep things simple". After I rephrased into the > above he was much more interested. > > 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. > > 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. > > DocWilco -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
Hi, > > 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.? After a quick search on google for "spanning tree" and "BPDU", here are some usefull links: http://www.ece.wpi.edu/courses/ee535/hwk96/hwk3cd96/sef/sef.html http://www.synapse.de/ban/HTML/P_LAYER2/Eng/P_lay119.html http://www.ethereal.com/lists/ethereal-dev/199910/msg00070.html http://www.support.baynetworks.com/library/tpubs/html/router/soft1000/bridge /2950A-16.html Apparently there is an implementation in linux (look for the file net/bridge/br_stp_bpdu.c) and the "BRIDGE-STP-HOWTO" (http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/BRIDG E-STP-HOWTO.html) http://www.linuxhq.com/kernel/v2.3/patch/patch-2.3.47/linux_net_bridge_br_st p.c.html Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bw limit in netgraph (Was: status of bridge code)
Rogier R. Mulhuijzen writes: > Quick question for the netgraph guru's. I haven't looked yet, but is there > an explanation of the NG_ macros I see used in the netgraph nodes' code? Yes, but it's not documented :) Actually the daemonnews article does document these somewhat. The main ones are NG_MKMESSAGE() for creating a new control message and NG_MKRESPONSE() for creating a response to a control message; and NG_SEND_DATA() to send a data/meta pair, NG_FREE_DATA() to free one. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
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.? > 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.. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bw limit in netgraph (Was: status of bridge code)
> > Since I currently have high workload, I dont have time to port it to 4.x or > 5-CURRENT... > Conclusion: volunteer required for this work... and I can consult him/her. Shouldn't be too hard. I'll gladly volunteer for this project. Quick question for the netgraph guru's. I haven't looked yet, but is there an explanation of the NG_ macros I see used in the netgraph nodes' code? DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
On Wed, 24 Jan 2001, Julian Elischer wrote: ... > > my dc cards. No problems so far - as long as I don't use DUMMYNET with it. > > I really wish I could use DUMMYNET as I need to put bandwidth limits on a > > few of the computers on my network. ... > Rate limitting is one thing that isn't there yet. If we pulled our fingers out, > I guess we would have ripped the dummynet rate limmiter out of where it is > and placed it into a netgraph node where it would be generally useful > instead of being hardcoded into one (sometimes useful) localtion in the > netoworking stacks. > > there is a rate limitter based on netgraph available from: > http://www.riss-telecom.ru/~vitaly/ > > but I have not tried it. > > I need to look at it again as I believe it has improved and > may be generally useful. > When I looked at it last it was a bit alpha. > It probably needs rewriting for the new netgraph API in -current. Current state of this project: Grade: production, working on more than 40 hosts from June 2000, city-wide ISP network OS version:3-STABLE from 8 January 2000 - this version currently used in our production routers/hosts Capabilities: guaranteed low bandwidth, maximum bandwidth, priority can be set for queue, traffic classification and bandwidth management realized by separate netgraph nodes. Since I currently have high workload, I dont have time to port it to 4.x or 5-CURRENT... Conclusion: volunteer required for this work... and I can consult him/her. -- Vitaly Belekhov System architect, AB-Telecom, Novosibirsk To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
>personally I use the netgraph bridging code and I think (though I'm biased) >that you should look at using htat rather than the hardwired bridging >code that it was derived from. Now that I've read up on it I can tell you you and and Archie have every right to be biased =) I've had a netgraph bridge in place for a while now and it works very well. (On 4.X-STABLE, on 5.X-CURRENT it went kablooie. See panic trace) > > item on my list. Being an allround good networking OS this is unacceptable > > IMHO. > >Have a look at what you can do with netgraph first. > >Most people don't know what it is but it allows almost arbitrarily >complicated network topologies to be set up from the command line. What you might want to tell people is that it allows networking structures to be setup in a simple manner, but is so powerful it can also be used for immensely complex structures. A friend and fellow BSD user of mine's first response was "I like to keep things simple". After I rephrased into the above he was much more interested. 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. 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. DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
On Wed, 24 Jan 2001, Archie Cobbs wrote: > Julian Elischer writes: > > > Is there any reasonable documentation or a HOWTO on the usage of netgraph? > > > I am currently using the standard bridging code and IPFIREWALL (ipfw) with > > > my dc cards. No problems so far - as long as I don't use DUMMYNET with it. > > > I really wish I could use DUMMYNET as I need to put bandwidth limits on a > > > few of the computers on my network. > > > > /usr/share/examples/netgraph > > man 4 netgraph > > man 4 ng_bridge > > (etc.) > > also a daemon-news article on how it works. > > http://www.daemonnews.org/23/netgraph.html A small addendum to the Netgraph canon: Netgraph starts with a _clean_slate_. If this is your first time, make sure you define some endpoint first, then build on that. You don't have interfaces, sockets, nothin' to start with. Like a box of Legos and an empty table. :-) Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
Julian Elischer writes: > > Is there any reasonable documentation or a HOWTO on the usage of netgraph? > > I am currently using the standard bridging code and IPFIREWALL (ipfw) with > > my dc cards. No problems so far - as long as I don't use DUMMYNET with it. > > I really wish I could use DUMMYNET as I need to put bandwidth limits on a > > few of the computers on my network. > > /usr/share/examples/netgraph > man 4 netgraph > man 4 ng_bridge > (etc.) > also a daemon-news article on how it works. http://www.daemonnews.org/23/netgraph.html -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
"Thomas T. Veldhouse" wrote: > > > Have a look at what you can do with netgraph first. > > > > Most people don't know what it is but it allows almost arbitrarily > > complicated network topologies to be set up from the command line. > > > > > > Is there any reasonable documentation or a HOWTO on the usage of netgraph? > I am currently using the standard bridging code and IPFIREWALL (ipfw) with > my dc cards. No problems so far - as long as I don't use DUMMYNET with it. > I really wish I could use DUMMYNET as I need to put bandwidth limits on a > few of the computers on my network. /usr/share/examples/netgraph man 4 netgraph man 4 ng_bridge (etc.) also a daemon-news article on how it works. Rate limitting is one thing that isn't there yet. If we pulled our fingers out, I guess we would have ripped the dummynet rate limmiter out of where it is and placed it into a netgraph node where it would be generally useful instead of being hardcoded into one (sometimes useful) localtion in the netoworking stacks. there is a rate limitter based on netgraph available from: http://www.riss-telecom.ru/~vitaly/ but I have not tried it. I need to look at it again as I believe it has improved and may be generally useful. When I looked at it last it was a bit alpha. It probably needs rewriting for the new netgraph API in -current. > > Tom Veldhouse > [EMAIL PROTECTED] -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
> Have a look at what you can do with netgraph first. > > Most people don't know what it is but it allows almost arbitrarily > complicated network topologies to be set up from the command line. > > Is there any reasonable documentation or a HOWTO on the usage of netgraph? I am currently using the standard bridging code and IPFIREWALL (ipfw) with my dc cards. No problems so far - as long as I don't use DUMMYNET with it. I really wish I could use DUMMYNET as I need to put bandwidth limits on a few of the computers on my network. Tom Veldhouse [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
"Rogier R. Mulhuijzen" wrote: > > Is anyone working on the bridge code? > > I've got a couple of things I'd like to fix in it, but I wouldn't want to > be doing anything someone else already did. > > My wishlist: > 1) Better interaction with various drivers (like if_tap). For some reason I > need to do a wack (undocumented) sysctl to make the bridge code refresh the > iface list > 2) Spontanious kablooies. After being in operation for a while it refuses > to send anything through and doesn't spew any messages > 3) Improve documentation. > 3) iface clustering/routing > 4) spanning tree implementation personally I use the netgraph bridging code and I think (though I'm biased) that you should look at using htat rather than the hardwired bridging code that it was derived from. > > There's talk of a userland daemon for the last item. Is there such a thing, > and if so, where. > > If there's no such daemon (not even halfway done), what would be the best > way for a daemon like that to interact with the kernel source? A device or > sysctl's? via netgraph. > item on my list. Being an allround good networking OS this is unacceptable > IMHO. Have a look at what you can do with netgraph first. Most people don't know what it is but it allows almost arbitrarily complicated network topologies to be set up from the command line. > > DocWilco > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
status of bridge code
Is anyone working on the bridge code? I've got a couple of things I'd like to fix in it, but I wouldn't want to be doing anything someone else already did. My wishlist: 1) Better interaction with various drivers (like if_tap). For some reason I need to do a wack (undocumented) sysctl to make the bridge code refresh the iface list 2) Spontanious kablooies. After being in operation for a while it refuses to send anything through and doesn't spew any messages 3) Improve documentation. 3) iface clustering/routing 4) spanning tree implementation There's talk of a userland daemon for the last item. Is there such a thing, and if so, where. If there's no such daemon (not even halfway done), what would be the best way for a daemon like that to interact with the kernel source? A device or sysctl's? Is there any bridging part of BSDi maybe that could be merged into our networking code. Being used a lot in key networking positions FreeBSD should really have good bridging. I've heard a few people who tried it complain about the 2nd item on my list. Being an allround good networking OS this is unacceptable IMHO. DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
