dixon@gumby.paradyne.com (0000-Tom Dixon(0000)) (02/21/90)
In article <539@opus.NMSU.EDU> rocks@nmsu.edu (Dave Rocks) writes: > We have several Novell networks spread about on campus. They > currently use ELS II, ver 2.12, and have 4 to 8 stations. We > recently connected one of these office lans to the campus ethernet, > using NCSA Telnet and Packet Driver support to connect the stations > to our IBM mainframe databases. Everything works fine and now other > offices wish to put their Lans on the campus net. But their are > problems putting multiple Novell servers on the same wire. As soon > as the second system is fired up, both systems get ROUTER errors and > they both hang up. We have a similar setup. Allow me to deed you with knowledge I wish I had learned before I got it all setup. TOPOLOGY: You have a couple of things to consider before making your topology decision. First, how much interserver use will there actually be? If that number is low, you might want to follow the "typical configuration" as some yahoo vendor described it. Backbone Ethernet -----+----------------+-----------. . . . | | SERVER A SERVER B . . . | | ------------------+ +----------- Server A's local Net. Server B's Local Net. And so forth. This buys you one inportant thing. Your default server is always your local server. Other then being about to connect to other servers, nothing about novell changes. This cuts your learning curve for your users. OR ---- If you are low on interrrupts or feel like being an idiot like me, you can put your servers all on one net. This also saves you the processing load on the servers of having to do the bridging, which might be important to you. It has the drawback of losing control over which server connects to you when you run netx. This is minor, but it can confuse users. Topology Follows: Backbone Ethernet -----+----------------+-----------. . . . | | SERVER A SERVER B . . . You place the workstations right on the main net. RULES OF NOVELL ADDRESSING: Or... How to prevent router config error... When you address each server with a network number, youmust can careful. If you pick the first topology, you assign a unique number for the local networks, and one common number for the backbone. If you pick the second option, you simply pick one number for all servers and rock and roll. Why? Novell, unlike tcp/ip addresses the network and not the node (* sort of... see * below for details) and you must be sure that all servers talking to a network agree on that networks network number. When a server hears another server advertising on a net with a different network error.... ROUTER CONFIG ERROR.... The error includes the ethernet address of the offending server and the number the other server thought this net was. It actually is pretty easy to debug, if you know the number of your network cards in your servers. * I may be way off but I believe that the nodes actual novell address is something like networknumber.ethernetaddress. You set the network number in the server config and the clients pick it up by listening to the net. The servers all babble about what services they offer including router configuration (like RIP, but novell). They don't play nice if they don't agree on the network number..... Hope all this helps. Flames to me email, I love to learn if you know something I missed or trashed. Tom Dixon dixon@pdn.paradyne.com
lim@cwlim.CWRU.EDU (Hock Koon Lim) (02/21/90)
In article <539@opus.NMSU.EDU> rocks@nmsu.edu (Dave Rocks) writes: > > offices wish to put their Lans on the campus net. But their are > problems putting multiple Novell servers on the same wire. As soon > as the second system is fired up, both systems get ROUTER errors and > they both hang up. We have been told multiple servers are possible, > but have as yet been unable to get it to work. WE know that there If you want to put multiple novell servers on the "Single Ethernet" network, make sure every novell server have the same "novell network" number. Most people just choose the novell network number randomly when the run "netgen". The Novell network number is a 8 digits Hex number. You can run "comceck unitlity or syscon and check the file server information to find out you network number. Before someone in your campus want to put a novell server on the campus ethernet, they have to make sure that their server use the campus novell network number. You can read the Netware 286 Installation manual on how to assign a network number(chapter 4-78). Hope this help, -- Hock-Koon Lim, Information Network services Case Western Reserve University; Cleveland, Ohio, USA 44106 (216) 368-2982 lim@cwlim.ins.cwru.edu
alan@oetl.UUCP (Alan Strassberg) (02/22/90)
In article <539@opus.NMSU.EDU> rocks@nmsu.edu (Dave Rocks) writes: [..] > problems putting multiple Novell servers on the same wire. As soon > as the second system is fired up, both systems get ROUTER errors and > they both hang up. We have been told multiple servers are possible, The 'Router configuration error' means the servers have different addresses. Use the same address for both when you netgen. Type 'config' on the server to see the addresses you've used. alan -- Alan Strassberg alan@oetl.scf.lockheed.com (408) 425-6139 ...!uunet!lstc!oetl!alan
cse0421@desire.wright.edu (02/22/90)
In article <539@opus.NMSU.EDU>, rocks@nmsu.edu (Dave Rocks) writes: > We have several Novell networks spread about on campus. They > currently use ELS II, ver 2.12, and have 4 to 8 stations. We > recently connected one of these office lans to the campus ethernet, > using NCSA Telnet and Packet Driver support to connect the stations > to our IBM mainframe databases. Everything works fine and now other > offices wish to put their Lans on the campus net. But their are > problems putting multiple Novell servers on the same wire. As soon > as the second system is fired up, both systems get ROUTER errors and > they both hang up. We have been told multiple servers are possible, > but have as yet been unable to get it to work. WE know that there > might be a technique using multiple ethernet adapters in each > server, but we quickly run into shortages of interrupts, etc., and > don't feel this is the preferred solution. We currently have > requests from 4 sparate office lans to be added to the network. If > anyone can give a step-by-step discription of how to add multiple > Novell servers to a campus wide ethernet network, we would be very > appreciative. > > > Thanx in advance, > Dave Rocks > rocks@nmsu.edu > 505-646-2633 > Q > :q If you are getting what I think you are we ran into this problem at work when we put a second Novell server on our network. When you run Netgen to generate the NetWare one of the parameters it asks you for is Network Address. All Novell servers on the same cable must have the same Network Address. They have different node addresses which are determined by the network card but the Network address must be the same. If they are different you will get routing errors. This Network Address is used by Netware to determine which line to send messages out on and when it receives more than one Network Address from the same card it prints a routing error message. John Wolf CSE0421@DESIRE.WRIGHT.EDU
alawlor@dit.ie (Aengus Lawlor) (02/22/90)
In article <1990Feb20.113920.19222@hellgate.utah.edu>, haas@cs.utah.edu (Walt Haas) writes: > In article <539@opus.NMSU.EDU> rocks@nmsu.edu (Dave Rocks) writes: >> >> We have several Novell networks spread about on campus. They >> currently use ELS II, ver 2.12, and have 4 to 8 stations. We >> recently connected one of these office lans to the campus ethernet, >> using NCSA Telnet and Packet Driver support to connect the stations >> to our IBM mainframe databases. Everything works fine and now other >> offices wish to put their Lans on the campus net. But their are >> problems putting multiple Novell servers on the same wire... If >> anyone can give a step-by-step discription of how to add multiple >> Novell servers to a campus wide ethernet network, we would be very >> appreciative. > > We have about 35 Novell servers on our campus wide Ethernet or its broadband > extension, with no significant problems. Did you make sure that each server > has a unique name? Also I would recommend that you plan for the future and > insist that all Novell machines use ECONFIG to generate Ethernet packet > framing, so that you don't run into problems with 802.2 DSAP=FF SSAP=FF > at some future time. > > Cheers -- Walt Haas haas@cs.utah.edu Two questions. 1) Can somebody explain to me what ECONFIG is for? ( I have seen it mentioned in the dox, but I amn't sure what added functionally it gives me). 2) I expect to soon have the same problem with multiple 3Com servers on a single LAN. Anybody care to give me the same step by step advice for 3Com that Dave Rocks is asking for Novell ? :-) -- Aengus Lawlor Dept of Computer Science. Time flies like an arrow, ALAWLOR@DIT.IE Dublin Institute of Technology. Fruit-flies like a banana Kevin Street. Dublin 8. Ireland.
haas@cs.utah.edu (Walt Haas) (02/24/90)
In article <7270.25e3b569@dit.ie> alawlor@dit.ie (Aengus Lawlor) writes: >In article <1990Feb20.113920.19222@hellgate.utah.edu>, I wrote >> ... Also I would recommend that you plan for the future and >> insist that all Novell machines use ECONFIG to generate Ethernet packet >> framing, so that you don't run into problems with 802.2 DSAP=FF SSAP=FF >> at some future time. >> >> Cheers -- Walt Haas haas@cs.utah.edu >Two questions. > 1) Can somebody explain to me what ECONFIG is for? When a Novell device puts a packet onto an Ethernet, it puts a header around it. There are two standards for such headers: 1) The original Ethernet or DIX (DEC/Intel/Xerox) standard, which consists of: 48 bit destination address 48 bit source address 16 bit protocol type ... user data 2) The IEEE 802.3 standard, which consists of: 48 bit destination address 48 bit source address 16 bit length The two packet formats can be intermixed on one wire, because all Ethernet protocol types have numbers greater than the maximum legal 802.3 length, thus a received packet can be examined and assigned confidently to one class or the other. HOWEVER the proper thing to follow the length field in format 2) is an IEEE 802.2 header. Instead, Novell inserts an XNS checksum of all one's (I think I got that right). This would appear to the world as an IEEE 802.2 DSAP=FF and SSAP=FF. Router vendors who support Novell protocols, such as cisco, deal with the DSAP=FF SSAP=FF packet as a special case. I fear that this hack will break in the next year or two as the use of the 802.3 framing style becomes more widespread. The easiest precaution, and the one that we take here, is to use the ECONFIG option which causes the Novell device to generate header format 1). This makes the packet fully conformant to standard so there should be no problem. Cheers -- Walt
alawlor@dit.ie (Aengus Lawlor) (02/26/90)
In article <1990Feb23.185608.8785@hellgate.utah.edu>, haas@cs.utah.edu (Walt Haas) writes: > In article <7270.25e3b569@dit.ie> alawlor@dit.ie (Aengus Lawlor) writes: >>Two questions. >> 1) Can somebody explain to me what ECONFIG is for? > > When a Novell device puts a packet onto an Ethernet, it puts a header > around it. There are two standards for such headers: > > 1) The original Ethernet or DIX (DEC/Intel/Xerox) standard, which > consists of: > 48 bit destination address > 48 bit source address > 16 bit protocol type > ... user data > > 2) The IEEE 802.3 standard, which consists of: > 48 bit destination address > 48 bit source address > 16 bit length > > The two packet formats can be intermixed on one wire, because all Ethernet > protocol types have numbers greater than the maximum legal 802.3 length, > thus a received packet can be examined and assigned confidently to one > class or the other. > > HOWEVER the proper thing to follow the length field in format 2) is an > IEEE 802.2 header. Instead, Novell inserts an XNS checksum of all one's > (I think I got that right). This would appear to the world as an IEEE 802.2 > DSAP=FF and SSAP=FF. > > Router vendors who support Novell protocols, such as cisco, deal with > the DSAP=FF SSAP=FF packet as a special case. I fear that this hack will > break in the next year or two as the use of the 802.3 framing style becomes > more widespread. The easiest precaution, and the one that we take here, > is to use the ECONFIG option which causes the Novell device to generate > header format 1). This makes the packet fully conformant to standard so > there should be no problem. > > Cheers -- Walt Thanks Walt. This may be a stupid question, but what does this mean in practice. My ethernet has a 3Com server (which I'm told uses XNS packets), a Netware server, and, will probably have some workstations talking TCP/IP. Will Econfiged drivers for Netware allow, for instance, NetBios Broadcast Datagrams from a Novell station to be picked up by a 3Com station? Or will the standard header make Netware-TCP/IP messageing more straightforward? Or is EConfig just going to make life easier sometime in the future? (These are very much "inquiring minds want to know" types of questions. I'm learning a lot here, and I appreciate any extra enlightenment you people out there can through my way!) Thanks, Aengus -- Aengus Lawlor Dept of Computer Science. Time flies like an arrow, ALAWLOR@DIT.IE Dublin Institute of Technology. Fruit-flies like a banana Kevin Street. Dublin 8. Ireland.
jbvb@ftp.COM (James Van Bokkelen) (02/28/90)
The issue of making different "NETBIOS over transport X" implementations communicate is quite different from the Ethernet encapsulations issue. In general, everybody who implemented NETBIOS as a programming interface over some transport layer they liked for other reasons (XNS, IPX, etc.) chose to do it in a way that "seemed reasonable at the time". The only exceptions so far are TCP/IP, where RFCs 1001 and 1002 specify all the grubby details, and a NETBIOS-over-OSI consortium, who demoed at Interop last year. Because all the vendors in each group agreed on a common spec, and because they use the same underlying transport layer, everybody (within each group) interoperates. The case you seem to want to deal with involves two different transports. In order to make a NETBIOS-over-Foo system talk to a NETBIOS-over-Bar system, you need some intermediate translating gateway, which speaks both. I know that 10Net/DCA did this between their private NETBIOS transport protocol and NETBIOS-over-TCP/IP, but I don't know of any others. -- James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
alawlor@dit.ie (Aengus Lawlor) (03/02/90)
In article <883@ftp.COM>, jbvb@ftp.COM (James Van Bokkelen) writes: > The issue of making different "NETBIOS over transport X" > implementations communicate is quite different from the Ethernet > encapsulations issue. In general, everybody who implemented NETBIOS > as a programming interface over some transport layer they liked for > other reasons (XNS, IPX, etc.) chose to do it in a way that "seemed > reasonable at the time". The only exceptions so far are TCP/IP, where > RFCs 1001 and 1002 specify all the grubby details, and a NETBIOS-over-OSI > consortium, who demoed at Interop last year. Because all the vendors > in each group agreed on a common spec, and because they use the same > underlying transport layer, everybody (within each group) interoperates. > > The case you seem to want to deal with involves two different > transports. In order to make a NETBIOS-over-Foo system talk to a > NETBIOS-over-Bar system, you need some intermediate translating > gateway, which speaks both. I know that 10Net/DCA did this between > their private NETBIOS transport protocol and NETBIOS-over-TCP/IP, > but I don't know of any others. > > > -- > James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 > FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 That's what I figured. But, if ECONFIG doesn't let IPX packets be read as TCP/IP / XNS / FOO.BAR / ... packets, then what's it for? (NETBIOS aside, that was just an example) -- Aengus Lawlor Dept of Computer Science. Time flies like an arrow, ALAWLOR@DIT.IE Dublin Institute of Technology. Fruit-flies like a banana Kevin Street. Dublin 8. Ireland.
haas@cs.utah.edu (Walt Haas) (03/04/90)
In article <7314.25ed5fcd@dit.ie> alawlor@dit.ie (Aengus Lawlor) writes: >... if ECONFIG doesn't let IPX packets be read as >TCP/IP / XNS / FOO.BAR / ... packets, then what's it for? (NETBIOS aside, >that was just an example) IPX packets are encapsulated in a low-level protocol appropriate to the hardware medium (Ethernet, Arcnet, token ring etc.) that they travel over. In the case of the Ethernet medium, you have a choice of *two* low-level protocol standards: 1) The old Ethernet standard. 2) The IEEE 802.3 standard. If you use Novell with the ECONFIG option, the software will conform to standard 1) above. If you don't use ECONFIG, the software will behave in a way that is likely to become troublesome if it shares a wire with other software which correctly implements IEEE 802.3 and its corresponding higher level protocol 802.2. So if you ever hope to have Novell running on a large diverse network like we do, use the ECONFIG option. -- Walt