263 lines
10 KiB
HTML
263 lines
10 KiB
HTML
<!--startcut ======================================================= -->
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<html>
|
|
<head>
|
|
<TITLE>The Answer Guy 28: Complex network and NetBIOS </TITLE>
|
|
</head>
|
|
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#A000A0"
|
|
ALINK="#FF0000">
|
|
<!--endcut ========================================================= -->
|
|
<H4>"Linux Gazette...<I>making Linux just a little more fun!</I>"
|
|
</H4>
|
|
<P> <hr> <P>
|
|
|
|
<!-- =============================================================== -->
|
|
<H1 align="center"><A NAME="answer">
|
|
<img src="../gx/dennis/qbubble.gif" alt="" border="0" align="middle">
|
|
<a href="./lg_answer28.html">The Answer Guy</a>
|
|
<img src="../gx/dennis/bbubble.gif" alt="" border="0" align="middle">
|
|
</A></H1> <BR>
|
|
<H4 align="center">By James T. Dennis,
|
|
<a href="mailto:linux-questions-only@ssc.com">linux-questions-only@ssc.com</a><BR>
|
|
Starshine Technical Services,
|
|
<A HREF="http://www.starshine.org/">http://www.starshine.org/</A> </H4>
|
|
<p><hr><p>
|
|
<H3><img src="../gx/dennis/qbub.gif" alt="(?)" width="50" height="28"
|
|
align="left" border="0">Complex network and NetBIOS </H3>
|
|
|
|
<p><strong>From Kate Stecenko on Tue, 14 Apr 1998 </strong></p>
|
|
|
|
<p><strong>
|
|
Hi !
|
|
|
|
<br><br>
|
|
I have some problem, can you help me?
|
|
|
|
<br><br>
|
|
Our network has 2 segments.
|
|
Each segment have a lot of stations Win 95 & Win NT OS.
|
|
Segments are connected via router.
|
|
Router is Linux box with Mars NWE for IPX routing & internal kernel
|
|
IP routing.
|
|
|
|
<br><br>
|
|
I need that all computers from all segments will be visible by each
|
|
other by NetBIOS (in Network Neibourhood/Microsoft Windows Network).
|
|
Not all computers in out network have TCP/IP stack (it's impossible
|
|
by important reasons), so I cannot use NetBIOS over TCP/IP.
|
|
If there are any way to make my Linux box and Samba work with NetBEUI
|
|
or run NetBIOS over IPX?
|
|
</strong></p>
|
|
|
|
<blockquote><img src="../gx/dennis/bbub.gif" alt="(!)" width="50" height="28"
|
|
align="left" border="0">Last
|
|
I heard NetBEUI is not routable. Novell's IPX/SPX is
|
|
routable to about 16 hops --- and a properly configured
|
|
Netware system should automatically route IPX. I don't
|
|
know about IPX routing through the Linux kernel (it
|
|
might require some static tweaking).
|
|
|
|
<br><br>
|
|
I don't know of any way to tunnel NetBIOS traffic over
|
|
IP or IPX.
|
|
|
|
<br><br>Other Options:
|
|
<dl>
|
|
<dt>Bridging
|
|
|
|
<dd>I think you can configure Linux to do ethernet <em>bridging</em>
|
|
(seems that an experimental config option for this has
|
|
crept into the recent 2.0.x kernels). Bridging is a
|
|
process where ethernet frames are copied from one interface
|
|
(segment) to another. This is different from routing in
|
|
that the router works at a higher level in the OSI reference
|
|
model (it's at the transport layer while bridging occurs at
|
|
the network layer and normal ethernet hubs work at the
|
|
physical layer).
|
|
|
|
<br><br>
|
|
One cost of this is that the bandwidth from one segment is
|
|
usually no longer isolated from the other (meaning that
|
|
your utilization may become unacceptable high). Some
|
|
bridges are more "intelligent" than others --- and they
|
|
"learn" which ethernet cards are on which segment (by
|
|
promiscuously watching the MAC --- media access control ---
|
|
addresses on all ethernet frames on each interface).
|
|
|
|
<br><br>
|
|
The smart switches or bridges then selectively forward
|
|
frames between the segments. (I use the term frames to
|
|
refer to ethernet data structures or transmission units
|
|
and "packets" to discuss those from the upper layers).
|
|
|
|
<br><br>
|
|
Some switching hubs (like the Kalpana) are quite expensive
|
|
but perform all of this in hardware/firmware. The advantage
|
|
is that traffic that's local to a segment won't be copied
|
|
to the other --- which should reduce the overall bandwidth
|
|
utilization of this approach.
|
|
|
|
<br><br>
|
|
The disadvantages involve NetBIOS and Netware/IPX. NetBIOS
|
|
is a "chatty" protocol involving <em>lots</em> of broadcasts,
|
|
particularly by servers (which in '95, NT, and WfW is
|
|
<em>every</em> machine with any "shares"). IPX is better, for
|
|
the most part, but most of the servers and services utilized by
|
|
Netware require SAP's (service advertising packets). These are
|
|
broadcasts as well.
|
|
|
|
<br><br>
|
|
(SAP's are why you don't have to configure a Netware client
|
|
system with information about default routers, DNS servers,
|
|
and things like that. The client listens to the wire for
|
|
some period of time and hears a list of these periodic SAP's.
|
|
The disadvantage in large networks with lots of servers,
|
|
print servers, and other services is that the SAP's can chew
|
|
up a sizable portion of your bandwidth --- and they <em>are</em>
|
|
routed).
|
|
|
|
<dt>Gateways:
|
|
|
|
<dd>Rather than trying to get this to work at a layer <em>below</em>
|
|
the transport (NetBIOS, TCP/IP, IPX/SPX) you could try to
|
|
get above it, into the presentation, session or application
|
|
layers. These approaches are generically called "gateways."
|
|
|
|
<br><br>
|
|
However. I don't know of any gateways that are appropriate
|
|
to SMB servers.
|
|
|
|
<dt>Warning:
|
|
|
|
<dd>
|
|
The rumors I've been hearing are that Microsoft will be phasing
|
|
NetBEUI out in favor of TCP/IP. So your organization's
|
|
constraint may not be feasibly in the long run (the next year
|
|
or two).
|
|
</dl>
|
|
</blockquote>
|
|
|
|
<p><strong><img src="../gx/dennis/qbub.gif" alt="(?)" width="50" height="28"
|
|
align="left" border="0">Please tell me what to do.</strong></p>
|
|
|
|
<blockquote><img src="../gx/dennis/bbub.gif" alt="(!)" width="50" height="28"
|
|
align="left" border="0">Conclusion:
|
|
|
|
<br><br>
|
|
Question your management's constraint about TCP/IP.
|
|
NT and '95 both include it (so it can't be a cost issue).
|
|
|
|
<br><br>
|
|
TCP/IP is the most widely used and deployed set of networking
|
|
protocols in the world --- and has been around longer than
|
|
anything else in current use. It is clearly scaleable
|
|
(despite the naysayers and doomsdayers -- "the Death of
|
|
the Internet" is not imminent). It doesn't suffer from
|
|
the limitations of IPX and NetBIOS.
|
|
|
|
<br><br>
|
|
I suspect that your management's proscription is based
|
|
on ignorance. They probably think they know just enough
|
|
about TCP/IP to worry about security and not enough to
|
|
know that protocol selection has little to do with system's
|
|
security. I've seen this discussed several times on the
|
|
<a href="news:comp.unix.security">comp.unix.security</a> and
|
|
<a href="http://www.geek-girl.com/bugtraq/">BugTraq</a>
|
|
mailing lists.
|
|
|
|
<br><br>
|
|
If they are concerned about where to get IP addresses it's
|
|
simply a non-issue. They should read <a
|
|
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc1918.html"
|
|
>RFC 1918</a>. This RFC establishes several sets of IP
|
|
addresses to be used by "disconnected" networks. In this case
|
|
"disconnected" means "behind a firewall" or "not connected to
|
|
the Internet" (your choice).
|
|
|
|
<br><br>
|
|
You can use any of these that you want --- you don't have
|
|
to ask anyone's permission. It is your responsibility to
|
|
prevent any such packets from being routed to the Internet
|
|
(which is where we get all the discussion of "IP Masquerading"
|
|
"NAT: network address translation" and "applications proxies"
|
|
(a form of "gateway").
|
|
|
|
<br><br>
|
|
If their concern is about preventing propagation of "forbidden"
|
|
protocols (applications layer) or "sensitive" information across
|
|
the their routers --- there are well established ways of doing
|
|
that (built right into the Linux kernel, among other
|
|
places). It's much easier to prevent <em>all</em> propagation than it
|
|
is to selectively allow access to specific protocols like
|
|
HTTP (web), SMTP (e-mail) and especially to FTP (which is an
|
|
ugly protocol for firewall designers to support --- but just
|
|
as easy as any other to block).
|
|
|
|
<br><br>
|
|
So, I have to question their "important" reasons and suggest
|
|
that <em>if</em> these reasons are that important and bridging
|
|
is not feasible than the probably have an unresolvable
|
|
conflict in their requirements.
|
|
|
|
<br><br>
|
|
(They might consider running polling processes on the
|
|
Linux Samba/NWE server to replication/mirror all of the
|
|
data that must be accessible between the segments. This
|
|
would be a big win in a couple of ways --- if feasible
|
|
given their usage patterns. It cuts down traffic <em>across</em>
|
|
the routers (speed/latency benefits for all) and ensures
|
|
that an extra "backup" of all the relevant data is available.
|
|
The obvious problems involve concurrency if you allow
|
|
write access on both sides of the fence. However, if the
|
|
data is of a type that can be "maintained" on one side and
|
|
published across in a read-only fashion it is worth a look).
|
|
|
|
<br><br>
|
|
In many ways I'd even question their requirement to share
|
|
these as files. If you have a few-well managed servers
|
|
it may be reasonable to make them all "dual homed" (put
|
|
two ethernet cards in every server and let them all straddle
|
|
the segments). If they are requiring the propagation of
|
|
shares created and maintained by desktop users than they
|
|
probably have a major management problem already.
|
|
</blockquote>
|
|
|
|
|
|
<p><strong><img src="../gx/dennis/bbub.gif" alt="(!)" width="50" height="28"
|
|
align="left" border="0">TIA, Kate Stecenko.</strong></p>
|
|
|
|
<blockquote><img src="../gx/dennis/bbub.gif" alt="(!)" width="50" height="28"
|
|
align="left" border="0">I
|
|
hope the explanation helps. Just off hand it sounds like
|
|
you've been saddled with a poorly considered set of
|
|
constraints and requirements.
|
|
|
|
<br><br>
|
|
It happens to alot of sysadmins and netadmins. While it
|
|
exercises are creativity and encourages us to socialize
|
|
(in our mailing lists and newsgroups) --- it also leads
|
|
to premature graying (or baldness in my case).
|
|
|
|
<br><br>
|
|
Sorry there's no magic bullet for this one.
|
|
</blockquote>
|
|
<!--================================================================-->
|
|
<P> <hr> <P>
|
|
<H5 align="center"><a href="http://www.linuxgazette.com/copying.html"
|
|
>Copyright ©</a> 1998, James T. Dennis <BR>
|
|
Published in <I>Linux Gazette</I> Issue 28 May 1998</H5>
|
|
<P> <hr> <P>
|
|
<!--================================================================-->
|
|
<A HREF="./index.html"><IMG SRC="../gx/indexnew.gif"
|
|
ALT="[ Table Of Contents ]"></A>
|
|
<A HREF="../index.html"><IMG SRC="../gx/homenew.gif"
|
|
ALT="[ Front Page ]"></A>
|
|
<A HREF="./lg_answer28.html"><IMG SRC="../gx/dennis/answernew.gif"
|
|
ALT="[ Answer Guy Index ]"></A>
|
|
<!--startcut ======================================================= -->
|
|
</body>
|
|
</html>
|
|
<!--endcut ========================================================= -->
|
|
|