I want to continue this thread to clarify some of your points. True, the
original post I made was to clarify information I felt was not completely
correct and true, this post is now not suitable to this group. I apologize
to any members for wasting their time with this thread and I hope this is
the last post I need to make on this subject.
>Chris Brenton wrote:
>Actually, this is incorrect. Developed by IBM for their PC Network LAN,
>NetBIOS was created to be an application program interface (API).
>NetBIOS is designed to be a front end for carrying out inter-application
>communications. NetBIOS defines the interface to the network protocol,
>not the protocol itself. At the time of development it was assumed that
>the application accessing NetBIOS would assume responsibility for
>defining the protocols required for transmitting the information. So
>NetBIOS _is_ a communication protocol, it just has no layer 3 component.
>
NETBIOS was written originally by Sytek. The technology was later used by
IBM. I am willing to concede the point that whether or not NETBIOS is a
protocol in the truest sense of the word is the subject of many debates
>NetBIOS also has a very loose specification for the presentation and
>application layers. There is no standard structure or format specified.
>This has lead to NetBIOS being paired with other protocols such as
>NetBEUI, IPX and IP which can provide a precise specification. It has
>also lead to incompatibility problems as vendors were left to create
>proprietary implementations. Artisoft's LANtastic is a good example of a
>system which communicates using a proprietary NetBIOS implementation and
>is unable to communicate with other NetBIOS systems.
You present good points here. Your point about Lantastic is well taken, but
we all see where Artisoft went with Lantastic against IBM, Microsoft and
Novell operating systems maybe part of this was due to the proprietary
aspects of the product.
>Actually, I would disagree here as well. I spent quite a bit of time
>taking traces and measuring protocol efficiency. IPX/NCP wins in this
>arena with NFS coming in second. NetBEUI is no more efficient that
>NetBIOS over IP, its just easier to configure.
I would need more data on this in order to agree with you. I am willing to
accept that two people's idea of performance is different depending on their
particular area of interest. It depends on what you were measuring in order
to say that one protocol is essentially faster than the other. Your opinion
is respected here. My opinion is that NetBEUI is "faster" than IPX.
>By "NBT" do you mean NetBIOS over IP? If so, this actually came along
>later. IBM formalized the transport framework of NetBIOS into NetBEUI
>around 1985. After that, NetBIOS was run over IPX in order to traverse
>network segments. The problem with NetBIOS over IPX is that the traffic
>is broadcast based so it could quickly saturate a small to medium
>network environment. Routers have to be configured to propagate these
>broadcasts across multiple networks. In the Cisco world this is referred
>to as "type 20 propagation" with is the decimal value of the "type"
>number for this traffic.
I want to clarify a couple of points:
(1) IPX type 20 propogation is used for configurations that need to pass
Novell type 20 NetBIOS traffic in Cisco routers.You are correct it is used
to control the amount of broadcast traffic in larger networks.
(2) NetBIOS uses names for addressing purposes while TCP/IP uses numbers. A
layer between the two must map NetBIOS names to IP addresses, and convert IP
addresses back to NetBIOS names. This layer is known as NetBIOS-over-TCP/IP,
it is described in RFCs 1001 and 1002.
>
>Also, NetBIOS over IP is not backwards compatible as stated above. True
>it uses the NetBIOS structure, but you will never get a NetBIOS over IP
>system to communicate with a system talking straight NetBIOS.
A system talking straight NETBIOS is not known to me. Netbios will not load
on most systems unless it finds the support protocol already defined and
running on the workstation or server.
>Depends. Layer 3 devices will _not_ forward NetBIOS over IP name claim
>or address resolution packets which are broadcast/multicast based. They
>will forward datagram, but the hosts have to find each other first. This
>is where using LMHOSTS or a NetBIOS Name Server (NBNS a la MS WINS)
>comes into play. It eliminates the need for the broadcast portion of
>NetBIOS over IP traffic.
>
>> and you can also configure most layer 3 devices to forward
>> broadcast traffic for functions like DHCP and WINS.
>
>True with DHCP, not true with WINS. Remember that WINS requires that all
>NetBIOS over IP hosts to be unicast based (p-node, h-node or m-node).
>Since no broadcast/multicast traffic is being generated, there is no
>broadcast traffic for the router to forward. This allows a layer 3
>device to support NetBIOS over IP like any other IP protocol (Telnet,
>HTTP, etc.) because all communications are unicast.
NBT can use a variety of mechanisms for name resolution. The simplest is to
simply rely on the default of using broadcasts to locate network resources.
This calls for the node to issue TCP/IP broadcasts for every NetBIOS query.
NBT can convert NetBIOS names to IP addresses in several ways.
(1)Broadcasting � hardly suitable in anything except the most simple
networks.
(2)Pre-load the NBT name cache with an IP address. This is accomplished
using a text file called LMHOSTS
(3) Windows Internet Name Service (WINS) servers. A WINS server is
essentially a p-node as described in RFCs 1001 and 1002
(4)Use DNS servers as name servers
NBT name resolution applies the search in the following order of precedence
until a name match is found. This can be modified by changing the Netbios
Node Type setting.
NBT searches its internal name cache
NBT queries the WINS server(s) defined.
A broadcast is issued.
NBT searches the LMHOSTS file.
NBT issues a DNS query for the NetBIOS name in question.
If no match is found, a name-not-found error is returned to NetBIOS.
Regards,
Lance
[EMAIL PROTECTED]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
