traviswilliam
asked on
NetWare 4.11 + Router + Network Neighborhood = Help
We have a small network here in our college dorm and we just added a Novell NetWare 4.11 Server. We added a second NIC card and use the server as a router between two networks, one on CAT 5 and one on COAX. Now the people on CAT 5 can't see the people on COAX and vice versa through the Network Neighborhood. I think it might have to do with the NetBeui protocol. I am also a Wingate server and everyone can use it, CAT 5 and COAX, so i know the two sides can talk to each other. Thanks for any help!
Couple of things.
First, are you binding IPX and NetBEUI on the clients? And are you enabling NetBEUI over IPX (You might have to turn on File sharing to do this...its been a while since I set it up).
Second, if you are running IP and are trying to route it across the networks, you are going to have to turn on IP routing and point the nic cards to each other through the HOSTS file. If that is what you are trying to do, let me know and I repost a more descriptive answer.
Lastly and just so you know, RJ45 is only used on twisted pair (it looks like a telephone connector only with more pairs). On a COAX segment you would have BNC connectors.
First, are you binding IPX and NetBEUI on the clients? And are you enabling NetBEUI over IPX (You might have to turn on File sharing to do this...its been a while since I set it up).
Second, if you are running IP and are trying to route it across the networks, you are going to have to turn on IP routing and point the nic cards to each other through the HOSTS file. If that is what you are trying to do, let me know and I repost a more descriptive answer.
Lastly and just so you know, RJ45 is only used on twisted pair (it looks like a telephone connector only with more pairs). On a COAX segment you would have BNC connectors.
You got ROUTE ON set in AUTOEXEC.NCF? If not, the cards no-talkie.
M
M
ASKER
Edited text of question
ASKER
Edited text of question
Travis, what version of netware is it first of all?
Have they been setup on two subnets?
SET IPX NETBIOS REPLICATION OPTION = 2
at the console. WIll also work if set to 1 or 3
(This also possible to setup by using servman on nw4.1 and monitor in Nw4.11)
Note: don't forget to place this command in autoexec.ncf
See novell's TID (2915825) "Managing Type 20 (IPX NetBIOS) Packet Traffic
at http://support.novell.com
Also checkou if you have packet forwarding enabled:
at console type "load inetcfg"
go to "protocols"->"IPX"
Set "Packed forwarding" ENABLED
If you use tcp/ip as protocol for M$ client
Set also in inetcfg
go to "protocols"->"IP"
Set "IP Packed forwarding" ENABLED "router"
HTH
at the console. WIll also work if set to 1 or 3
(This also possible to setup by using servman on nw4.1 and monitor in Nw4.11)
Note: don't forget to place this command in autoexec.ncf
See novell's TID (2915825) "Managing Type 20 (IPX NetBIOS) Packet Traffic
at http://support.novell.com
Also checkou if you have packet forwarding enabled:
at console type "load inetcfg"
go to "protocols"->"IPX"
Set "Packed forwarding" ENABLED
If you use tcp/ip as protocol for M$ client
Set also in inetcfg
go to "protocols"->"IP"
Set "IP Packed forwarding" ENABLED "router"
HTH
ASKER
aioudine, all of those settings are already like that and we still have the same problem. Thanks for trying!
jmcclell, here are our client settings, and we are on 1 subnet.
CAT5 COAX
I.P. Address: 192.168.0.xxx 192.168.128.xxx
Subnet mask: 255.255.255.0 255.255.255.0
Gateway: 192.168.0.254 192.168.128.254
DNS: 192.168.0.1 (wingate machine)
For the people on the COAX side of the network, on the wingate machine,
I must use the route command for them to be able to see me.
route add 192.168.128.0 mask 255.255.255.0 192.168.0.254 metric 1
I dont know if any of this will help anyone but here it is.
jmcclell, here are our client settings, and we are on 1 subnet.
CAT5 COAX
I.P. Address: 192.168.0.xxx 192.168.128.xxx
Subnet mask: 255.255.255.0 255.255.255.0
Gateway: 192.168.0.254 192.168.128.254
DNS: 192.168.0.1 (wingate machine)
For the people on the COAX side of the network, on the wingate machine,
I must use the route command for them to be able to see me.
route add 192.168.128.0 mask 255.255.255.0 192.168.0.254 metric 1
I dont know if any of this will help anyone but here it is.
You didn't mention if the coax attached workstations are using newly installed NICs. If so it's common to have an issue with the 'frame type' in use. This can be checked under the 'Advanced' tab of the 'Protocol' section beneath Control Panel, Network. Many vendors drivers offer 'Auto', 802.3, 802.2, etc. I have had 'Auto' be problematic, if you see that the units which are not routing are on 'Auto' you might try another (probably 802.2). This is brought about by differing vintages of some of the drivers. I'm assuming that your server is defaulting to 802.2, you can test this by entering the 'config' command at the NetWare console prompt.. If you're not using EXCLUSIVELY IP (unlikely), I believe you'll find this information to be helpful.... Good Luck!
You have not stated the client platform, so I'll assume its Win95. Is this correct ? It also sounds like your clients are using NetBeui over TCP/IP. Is this correct ?
I take it you have verified basic connectivity by pinging workstations across the router (server) and loaded TCPCON to check the server is forwarding IP frames.
Your problem may be because the Win95 workstations are unable to resolve NetBios to IP names across the NetWare server. From the configuration details you have supplied, it sounds like you are not using WINS, which means your clients are acting as NetBios B-Nodes and require broadcast support to locate other NetBios devices on the network. There are a couple of ways to fix this situation: -
1) NetWare TCP/IP has directed broadcasts disabled. You can enable it by loading INETCFG at the server console, selecting Protocols | TCP/IP | Expert Configuration Options and changing Directed Broadcasts to enabled. Quit INETCFG and enter 'Reinitialize System' at the server console.
2) You can create a LMHosts file in the C:\Windows directory for each workstation. This file needs to contain the NetBios name (typically the same as the IP host name) and the IP address of each workstation. Follow the details in the sample file LMHosts.Sam.
NT workstation supports using DNS for NetBios name to IP address resolution. I'm not sure if Win95 does as well. You'll have to find out it this is so as it is another method of achieving the desired result.
Good Luck.
I take it you have verified basic connectivity by pinging workstations across the router (server) and loaded TCPCON to check the server is forwarding IP frames.
Your problem may be because the Win95 workstations are unable to resolve NetBios to IP names across the NetWare server. From the configuration details you have supplied, it sounds like you are not using WINS, which means your clients are acting as NetBios B-Nodes and require broadcast support to locate other NetBios devices on the network. There are a couple of ways to fix this situation: -
1) NetWare TCP/IP has directed broadcasts disabled. You can enable it by loading INETCFG at the server console, selecting Protocols | TCP/IP | Expert Configuration Options and changing Directed Broadcasts to enabled. Quit INETCFG and enter 'Reinitialize System' at the server console.
2) You can create a LMHosts file in the C:\Windows directory for each workstation. This file needs to contain the NetBios name (typically the same as the IP host name) and the IP address of each workstation. Follow the details in the sample file LMHosts.Sam.
NT workstation supports using DNS for NetBios name to IP address resolution. I'm not sure if Win95 does as well. You'll have to find out it this is so as it is another method of achieving the desired result.
Good Luck.
ASKER
That proposed solution still did not solve our problem of being able to access all of the networked computers from Win95\98 Network Neighboorhood. Thank you for trying!
ASKER
brosenb0, We have a mix of clients using Win95 and 98. I was wondering if our problem is because Windows uses the NetBeui protocol for its networking and Netware uses IPX or TCP/IP, because on the Novell web site, it said that NetBeui is not a supported protocol for NetWare and that it doesn't know what to do with it. I could be wrong, its know to happen. Any feedback is much appreciated!
Travis,
Here's a brief explanation of how the protocols interact. This may help you implement one of the options I described above.
NetBeui is an extension to NetBIOS and stands for NetBIOS Enhanced User Interface. Neither are routable protocols and were originally designed by IBM to run on single segment token-ring networks for use with the IBM PC network program and IBM LAN Server. Microsoft LAN Manager was a spin off from IBM LAN Server, originally built in partnership when the two companies were good mates. All of these products used NetBeui as there basic transport protocol for talking on the network. The network server service of NT Server up to v4.0 is basically the same as that found in LAN Manager and it too relies on NetBeui as its transport protocol.
NetBIOS relies on names to determine which device is which on the network. The name that you give to every Win95/98 machine is the name that is used for NetBIOS on the network and as such, each must be unique. When a NetBIOS node starts up, it registers its name with other NetBIOS nodes by broadcasting on the Network. To find out the addresses of other nodes, it sends out broadcasts requesting the information. NetBIOS is a very broadcast intensive protocol.
To get around the non-routable limitation created by NetBeui, Microsoft decided to encapsulate NetBeui within TCP/IP as IP is routable. A standard NetBeui frame is created which in turn is placed inside a standard IP frame. The IP frame is sent across the network to the receiving node which strips the IP frame and sends the remaining NetBeui frame to the file server kernel. There now exists the problem of associating NetBIOS names with IP addresses of workstations and there are three ways to accomplish this with Win95.
1) To assist this process, Microsoft came up with WINS or Windows Internet Naming Service. WINS is basically a central register of NetBIOS names to IP address relationships, with which a node can register itself and query values of other nodes. WINS is merely an application running on an NT server and would be found in larger, more complex networks.
2) LMHosts. The LMHosts file is a file that contains the NetBIOS name of a workstation and its IP address. It also contains information about NT domain controllers etc. This requires manual administration for every node, but is ideal for small Microsoft networks.
3) Broadcasts. Nodes may attempt to find other NetBeui over IP nodes by sending out IP broadcasts. This would not be recommended in a large network as the amount of broadcast traffic could end up enormous.
Thus as fas as NetWare is concerned, it is routing IP frames and it does not care that the data within those frames is in fact NetBeui frames.
Is this what you need ?
Here's a brief explanation of how the protocols interact. This may help you implement one of the options I described above.
NetBeui is an extension to NetBIOS and stands for NetBIOS Enhanced User Interface. Neither are routable protocols and were originally designed by IBM to run on single segment token-ring networks for use with the IBM PC network program and IBM LAN Server. Microsoft LAN Manager was a spin off from IBM LAN Server, originally built in partnership when the two companies were good mates. All of these products used NetBeui as there basic transport protocol for talking on the network. The network server service of NT Server up to v4.0 is basically the same as that found in LAN Manager and it too relies on NetBeui as its transport protocol.
NetBIOS relies on names to determine which device is which on the network. The name that you give to every Win95/98 machine is the name that is used for NetBIOS on the network and as such, each must be unique. When a NetBIOS node starts up, it registers its name with other NetBIOS nodes by broadcasting on the Network. To find out the addresses of other nodes, it sends out broadcasts requesting the information. NetBIOS is a very broadcast intensive protocol.
To get around the non-routable limitation created by NetBeui, Microsoft decided to encapsulate NetBeui within TCP/IP as IP is routable. A standard NetBeui frame is created which in turn is placed inside a standard IP frame. The IP frame is sent across the network to the receiving node which strips the IP frame and sends the remaining NetBeui frame to the file server kernel. There now exists the problem of associating NetBIOS names with IP addresses of workstations and there are three ways to accomplish this with Win95.
1) To assist this process, Microsoft came up with WINS or Windows Internet Naming Service. WINS is basically a central register of NetBIOS names to IP address relationships, with which a node can register itself and query values of other nodes. WINS is merely an application running on an NT server and would be found in larger, more complex networks.
2) LMHosts. The LMHosts file is a file that contains the NetBIOS name of a workstation and its IP address. It also contains information about NT domain controllers etc. This requires manual administration for every node, but is ideal for small Microsoft networks.
3) Broadcasts. Nodes may attempt to find other NetBeui over IP nodes by sending out IP broadcasts. This would not be recommended in a large network as the amount of broadcast traffic could end up enormous.
Thus as fas as NetWare is concerned, it is routing IP frames and it does not care that the data within those frames is in fact NetBeui frames.
Is this what you need ?
ASKER
brosenb0, Thank you very much, that helps me out alot knowing that it is forwarding NetBeui through IP packets. Now I know they are getting there, I just need to implement your ideas to see if I can get it all working.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Kerry,
For starters we're not talking about tunnelling, we're talking about encapsulation. Two different kettles of fish, but related as tunnelling requires encapsulation. Tunnelling typically involves encapsulation of one frame type in another for the purpose of transport across a point to point link that does not support the transport of the encapsulated frame. In the NetWare world it is common to see IPX encapsulated within IP so it may be tunnelled across an IP network. This requires two end-points for each tunnel.
In the Microsoft Network world, servers & clients automatically encapsulate NetBeui within IP if IP is installed as NetBeui is the core protocol of the MS network. The TCP/IP stack running on a NetWare server does not care that the frames it is routing contain NetBeui.
A NetWare server will support directed broadcast of IP frames, which may contain NetBeui frames. In a large network filters are required on router ports to prevent MS network devices from broadcasting IP traffic containing NetBeui name resolution frames. I have seen sniffer traces to this effect showing broadcast storms across routers.
You may have confused Travis by stating that the MS implementation of NetBeui is not NetWare compatible. If a MS NetBeui frame is the native frame type, ie. it is not encapsulated with IP or IPX then the server will not route it unless the server is running Novell MPR, is acting as a source-routing bridge and the frame contains a valid RIF header. Travis's server is compatible with MS NetBeui if the MS NetBeui frames are encapsulated within IP or IPX.
From a client perspective, MS NetBeui is not compatible with Novell NETBIOS.EXE as the latter encapsulates NetBIOS within IPX (so it can easily be routed) and neither end can decode the other's frames. NETBIOS.EXE was popular years ago before IP became the defacto standard.
For starters we're not talking about tunnelling, we're talking about encapsulation. Two different kettles of fish, but related as tunnelling requires encapsulation. Tunnelling typically involves encapsulation of one frame type in another for the purpose of transport across a point to point link that does not support the transport of the encapsulated frame. In the NetWare world it is common to see IPX encapsulated within IP so it may be tunnelled across an IP network. This requires two end-points for each tunnel.
In the Microsoft Network world, servers & clients automatically encapsulate NetBeui within IP if IP is installed as NetBeui is the core protocol of the MS network. The TCP/IP stack running on a NetWare server does not care that the frames it is routing contain NetBeui.
A NetWare server will support directed broadcast of IP frames, which may contain NetBeui frames. In a large network filters are required on router ports to prevent MS network devices from broadcasting IP traffic containing NetBeui name resolution frames. I have seen sniffer traces to this effect showing broadcast storms across routers.
You may have confused Travis by stating that the MS implementation of NetBeui is not NetWare compatible. If a MS NetBeui frame is the native frame type, ie. it is not encapsulated with IP or IPX then the server will not route it unless the server is running Novell MPR, is acting as a source-routing bridge and the frame contains a valid RIF header. Travis's server is compatible with MS NetBeui if the MS NetBeui frames are encapsulated within IP or IPX.
From a client perspective, MS NetBeui is not compatible with Novell NETBIOS.EXE as the latter encapsulates NetBIOS within IPX (so it can easily be routed) and neither end can decode the other's frames. NETBIOS.EXE was popular years ago before IP became the defacto standard.
ASKER