Dustin, I found this on google. It talks about a kernel patch that might be the right path for you to look down...
--snip (or the link -> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=179510+0+archive/2000/freebsd-questions/20001126.freebsd-questions I just spent the afternoon trying to work out if channel bonding / etherchannel / trunking is possible on FreeBSD. The answers from the mailing list archives say either: 1, Nope. 2, Yup, but it's messy and you have to use PPPoE. 3, Yup, use a kernel hack called mpath. Note that (possibly due to a bad ISP) flirble.org, where mpath should be, appears to be currently unavailable so I'm slightly clue disabled at the moment. None of this seems to answer what, for me, appears to be the basic question: When a client machine ARP's for the servers IP, it has to reply with a link layer (i.e. ethernet MAC) address. All packets from client to server (or nearest router to server) then travel between these two MAC addresses. How does this work with two network cards then? Either: a, Both network cards have the same MAC address, but then how does the switch know which card to send an incoming packet to? This appears to be the approach taken by mpath since "the ARP request is replied by the head of the cluster" (pseudo quote, sorry). Is this something the switch has to understand? b, The cards have different addresses and the ARP reply is cooked such that it comes from one or the other card - like round robin DNS, only for layer 2. This is all well and good, but the next hop router would have an ARP cache, so presumably all connections would go to one card or the next. c, None of the above. I also don't get the connection with 802.1q VLAN's. 802.1q appears to be about marking ethernet packets with a VLAN number such that your one LAN can be considered to be many LAN's electrically isolated. Great, I've even used it on a cisco switch and it worked a treat. I cannot find it's connection with the trunking/bonding problem though... Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the me On Thu, 2002-07-11 at 08:08, Dustin Puryear wrote: > Some corrections are in order. I am not trying to bond the two DSL lines. I > wrote that too late at night and too fast. > > My client has a website, and is hitting the limits of the current DSL line. > They need to handle more client connections. The client has made the > decision to purchase another DSL line so we can use both. They will not > colocate the servers. > > So, we need to be able to handle load-balancing/sharing the two DSL lines > for upstream (to the client) and downstream (to the web server) traffic. I > can handle downstream by using DNS round-robin (other suggestions are > welcome), as we are not worried so much about each client alternating > between links for each connection, but just basically assigning each client > to a particular link. Because of client-side DNS caching I don't see any > work-around for this. Now, with a web-server, it is the upstream (to the > client) traffic that is large. So, that is what we need to really focus on > balancing/sharing across the two links. > > I am pretty sure that FreeBSD can do this. However, I haven't actually seen > this done. Does anyone have experience doing this? I'd like to know what > troubles you had and any caveats. If you used a hardware solution, what did > you use, and what did you like/dislike about it? > > Regards, Dustin > > > At 12:39 AM 7/11/2002 -0500, Dustin Puryear wrote: > >Has any used FreeBSD to bond two DSL lines? We will have no support from > >the ISP, so the solution must work entirely on our end. If you have done > >this, what was your solution? We are investigating whether to use our > >existing FreeBSD router to accomplish this task, or to purchased dedicated > >hardware, such as a solution from Nexland. > > > >Speaking of dedicated hardware, what about your experience with that? I > >have a client that has a low budget, and needs to bond two ADSL lines > >together. The downstream is 600 Kbit/s and upstream is about double that > >on each line. > > > >Does anyone have any good experiences or recommendations to share on > >hardware solutions for bonding DSL lines? > > > >The goal is to increase the bandwidth to the client's in-house website. > >Because these are DSL lines from the Sprint running over BellSouth's last > >mile, we do not see any redundancy benefits. Some kind of intelligent > >fail-over would be nice, but in general, if one goes down, both will be > >down. We are definitely concentrating on increasing bandwidth. > > > >Please note that colocating is not an option for this client. > > > >Regards, Dustin > > > >--- > >Dustin Puryear <[EMAIL PROTECTED]> > >Puryear Information Technology > >UNIX, Windows, and IT Consulting > >http://www.puryear-it.com > > > > > > > >_______________________________________________ > >General mailing list > >[email protected] > >http://brlug.net/mailman/listinfo/general_brlug.net > > > --- > Dustin Puryear <[EMAIL PROTECTED]> > Puryear Information Technology > UNIX, Windows, and IT Consulting > http://www.puryear-it.com > > > > _______________________________________________ > General mailing list > [email protected] > http://brlug.net/mailman/listinfo/general_brlug.net -- Shannon Roddy __________________________________________________________________ Systems Administrator California Institute of Technology [EMAIL PROTECTED] LIGO Livingston Observatory ph: (225)686-3106 19100 LIGO Lane fx: (225)686-7189 Livingston, LA 70754 Web Page http://www.ligo-la.caltech.edu/~sroddy Calendar/Schedule See Home Page Wireless Email (255 Chars) [EMAIL PROTECTED]
