This is a MIME-formatted message. If you see this text it means that your
E-mail software does not support MIME-formatted messages.
--=_critter.penguinmonster.com-24472-1026425750-0001-2
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
As mentioned before, without ISP support channel bonding just isn't
going to happen. However, here's one approach that a friend of mine told
me about a while back. This method is actually in use in some large
background providers for multi-homed systems, and actually provides
suprisingly good results. I imagine it would especially if both links
are from the same ISP.
First, drop the default route. Then, add two new routes, one for
0.0.0.0, the other for 128.0.0.0, with a 1 (one) bit subnetmask.
Afterwards, I guess it would be possible to add a default route with a
higher metric number, giving it a lower priority in case a link goes
down. I'm not sure how well the backup default route will work, and if
not it might take a little scripting to manipulate the routes in case
one link goes down. Anyway, what this will accomplish is, for outgoing
connections, anything bound for ip addresses where the first number is
between 1 and 127, the data will go out the first interface. Numbers
128-254 will go out the second one. In the examples I heard about, usage
was actually pretty even between the interfaces, surprisingly enough.
I haven't tried this myself, and the cases I've heard of it were using
routers, but the principle _should_ work. It may be prudent to do this
on a separate 'router' machine, and I'd even consider having the router
(probably a *BSD machine in your case) do reverse proxying (using squid
or apache's mod_proxy) to the web server for a few reasons.
Does this seem like it would work to you guys?
-Tim
On Thu, 2002-07-11 at 16:32, Shannon Roddy wrote:
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]
_______________________________________________
General mailing list
[email protected]
http://brlug.net/mailman/listinfo/general_brlug.net
--=_critter.penguinmonster.com-24472-1026425750-0001-2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/1.0.2">
</HEAD>
<BODY>
As mentioned before, without ISP support channel bonding just isn't going to
happen. However, here's one approach that a friend of mine told me about a
while back. This method is actually in use in some large background providers
for multi-homed systems, and actually provides suprisingly good results. I
imagine it would especially if both links are from the same ISP.
<BR>
<BR>
First, drop the default route. Then, add two new routes, one for 0.0.0.0, the
other for 128.0.0.0, with a 1 (one) bit subnetmask. Afterwards, I guess it
would be possible to add a default route with a higher metric number, giving it
a lower priority in case a link goes down. I'm not sure how well the backup
default route will work, and if not it might take a little scripting to
manipulate the routes in case one link goes down. Anyway, what this will
accomplish is, for outgoing connections, anything bound for ip addresses where
the first number is between 1 and 127, the data will go out the first
interface. Numbers 128-254 will go out the second one. In the examples I heard
about, usage was actually pretty even between the interfaces, surprisingly
enough.
<BR>
<BR>
I haven't tried this myself, and the cases I've heard of it were using routers,
but the principle _should_ work. It may be prudent to do this on a separate
'router' machine, and I'd even consider having the router (probably a *BSD
machine in your case) do reverse proxying (using squid or apache's mod_proxy)
to the web server for a few reasons.
<BR>
<BR>
Does this seem like it would work to you guys?
<BR>
<BR>
-Tim
<BR>
<BR>
<BR>
<BR>
<BR>
On Thu, 2002-07-11 at 16:32, Shannon Roddy wrote:
<BLOCKQUOTE>
<PRE><FONT COLOR="#737373"><FONT SIZE="3"><I>Dustin, I found this on google.
It talks about a kernel patch that</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>might be the right path for you to look
down...</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>--snip (or the link
-></FONT></FONT></I>
<FONT COLOR="#737373"><FONT
SIZE="3"><I>http://docs.freebsd.org/cgi/getmsg.cgi?fetch=179510+0+archive/2000/freebsd-questions/20001126.freebsd-questions</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>I just spent the afternoon trying to
work out if channel bonding /</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>etherchannel / trunking is possible on
FreeBSD. The answers from the</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>mailing list archives say either:
</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>1, Nope.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>2, Yup, but it's messy and you have to
use PPPoE.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>3, Yup, use a kernel hack called mpath.
</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>Note that (possibly due to a bad ISP)
flirble.org, where mpath should</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>be,</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>appears to be currently unavailable so
I'm slightly clue disabled at the</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>moment. None of this seems to answer
what, for me, appears to be the</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>basic</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>question: When a client machine ARP's
for the servers IP, it has to</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>reply</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>with a link layer (i.e. ethernet MAC)
address. All packets from client</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>to</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>server (or nearest router to server)
then travel between these two MAC</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>addresses. How does this work with two
network cards then? Either: a,</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>Both network cards have the same MAC
address, but then how does the</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>switch know which card to send an
incoming packet to? This appears to be</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>the approach taken by mpath since
"the ARP request is replied by the</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>head</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>of the cluster" (pseudo quote,
sorry). Is this something the switch has</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>to</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>understand? b, The cards have different
addresses and the ARP reply is</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>cooked such that</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>it comes from one or the other card -
like round robin DNS, only for</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>layer</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>2. This is all well and good, but the
next hop router would have an ARP</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>cache, so presumably all connections
would go to one card or the next.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>c, None of the above. I also don't get
the connection with 802.1q</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>VLAN's. 802.1q appears to
be</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>about marking ethernet packets with a
VLAN number such that your one LAN</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>can be considered to be many LAN's
electrically isolated. Great, I've</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>even</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>used it on a cisco switch and it worked
a treat. I cannot find it's</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>connection with the trunking/bonding
problem though... Dave To</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>Unsubscribe: send mail to [EMAIL
PROTECTED]</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>with "unsubscribe
freebsd-questions" in the body of the me</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>On Thu, 2002-07-11 at 08:08, Dustin
Puryear wrote:</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> Some corrections are in order. I
am not trying to bond the two DSL lines. I </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> wrote that too late at night and
too fast.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> My client has a website, and is
hitting the limits of the current DSL line. </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> They need to handle more client
connections. The client has made the </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> decision to purchase another DSL
line so we can use both. They will not </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> colocate the
servers.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> So, we need to be able to handle
load-balancing/sharing the two DSL lines </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> for upstream (to the client) and
downstream (to the web server) traffic. I </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> can handle downstream by using DNS
round-robin (other suggestions are </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> welcome), as we are not worried so
much about each client alternating </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> between links for each connection,
but just basically assigning each client </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> to a particular link. Because of
client-side DNS caching I don't see any </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> work-around for this. Now, with a
web-server, it is the upstream (to the </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> client) traffic that is large. So,
that is what we need to really focus on </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> balancing/sharing across the two
links.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> I am pretty sure that FreeBSD can
do this. However, I haven't actually seen </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> this done. Does anyone have
experience doing this? I'd like to know what </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> troubles you had and any caveats.
If you used a hardware solution, what did </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> you use, and what did you
like/dislike about it?</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> Regards, Dustin</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> At 12:39 AM 7/11/2002 -0500,
Dustin Puryear wrote:</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >Has any used FreeBSD to bond
two DSL lines? We will have no support from </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >the ISP, so the solution must
work entirely on our end. If you have done </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >this, what was your solution?
We are investigating whether to use our </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >existing FreeBSD router to
accomplish this task, or to purchased dedicated </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >hardware, such as a solution
from Nexland.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> ></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >Speaking of dedicated
hardware, what about your experience with that? I </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >have a client that has a low
budget, and needs to bond two ADSL lines </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >together. The downstream is
600 Kbit/s and upstream is about double that </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >on each line.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> ></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >Does anyone have any good
experiences or recommendations to share on </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >hardware solutions for bonding
DSL lines?</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> ></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >The goal is to increase the
bandwidth to the client's in-house website. </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >Because these are DSL lines
from the Sprint running over BellSouth's last </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >mile, we do not see any
redundancy benefits. Some kind of intelligent </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >fail-over would be nice, but
in general, if one goes down, both will be </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >down. We are definitely
concentrating on increasing bandwidth.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> ></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >Please note that colocating is
not an option for this client.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> ></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >Regards,
Dustin</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> ></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >---</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >Dustin Puryear <[EMAIL
PROTECTED]></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >Puryear Information
Technology</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >UNIX, Windows, and IT
Consulting</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>>
>http://www.puryear-it.com</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> ></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> ></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> ></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>>
>_______________________________________________</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> >General mailing
list</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>>
>[email protected]</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>>
>http://brlug.net/mailman/listinfo/general_brlug.net</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> ---</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> Dustin Puryear <[EMAIL
PROTECTED]></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> Puryear Information
Technology</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> UNIX, Windows, and IT
Consulting</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>>
http://www.puryear-it.com</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>>
_______________________________________________</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> General mailing
list</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> [email protected]</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>>
http://brlug.net/mailman/listinfo/general_brlug.net</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>-- </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>Shannon Roddy</FONT></FONT></I>
<FONT COLOR="#737373"><FONT
SIZE="3"><I>__________________________________________________________________</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>Systems Administrator
California Institute of Technology</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>[EMAIL PROTECTED] LIGO Livingston
Observatory</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>ph: (225)686-3106 19100
LIGO Lane</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>fx: (225)686-7189
Livingston, LA 70754</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>Web Page
http://www.ligo-la.caltech.edu/~sroddy</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>Calendar/Schedule See
Home Page</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>Wireless Email (255 Chars) [EMAIL
PROTECTED]</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT
SIZE="3"><I>_______________________________________________</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>General mailing list</FONT></FONT></I>
<FONT COLOR="#737373"><FONT
SIZE="3"><I>[email protected]</FONT></FONT></I></PRE>
</BLOCKQUOTE>
<A HREF="http://brlug.net/mailman/listinfo/general_brlug.net";><FONT
SIZE="3"><I>http://brlug.net/mailman/listinfo/general_brlug.net</FONT></I></A>
<BLOCKQUOTE>
<PRE></PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=_critter.penguinmonster.com-24472-1026425750-0001-2--
