lunde@casbash.acns.nwu.edu (Albert Lunde) (12/08/90)
Does anyone know of products/protocols that can connect between Novell
networks over a TCP/IP internet? I assume that this would involve
enclosing the IPX packets in IP packets and "tunneling" them thru IP.
Our campus network has various Novell networks connected to the campus
TCP/IP network, and we are using ftp and telnet and testing mail bridges
to SMTP, but no-one seems to have a way to link the Novell nets together.
Another approach that has been discussed would be getting our campus
network to route multiple protocols (IPX and IP) directly. This may be
feasible for the backbone which has commercial (cisco) routers. However,
the outlying parts of the network go thru "Morrison" PC routers and UNIX
boxes that can only deal with IP, not IPX.
It seems like this _could_ be done, as we tunnel Appletalk thru IP and
vis-versa. I am looking for news of real or forthcoming implementations.
Albert Lunde Northwestern University Albert_Lunde@nwu.edu
Academic Computingmartino@logitek.co.uk (Martin O'Nions) (12/10/90)
lunde@casbash.acns.nwu.edu (Albert Lunde) writes: >Does anyone know of products/protocols that can connect between Novell >networks over a TCP/IP internet? I assume that this would involve >enclosing the IPX packets in IP packets and "tunneling" them thru IP. >It seems like this _could_ be done, as we tunnel Appletalk thru IP and >vis-versa. I am looking for news of real or forthcoming implementations. I don't know if anyone in Provo would like to comment, but a Novell "Marketecht" (spelling anbody?) was heard to say that this sort of function would be handled over the much awaited NetWare386 IP NLM. This was shortly after the discussion of the same principle over SNA, and in that case at least, it was implemented by a third party. If there's anybody with more info (or even a simple refutation) relating to this. I'd be interested. We are MAC level bridged just about everywhere in the company, but there are time when its nice to stick with one protocol (particularly when it's IP). Comments? Martin -- +------------------------------------------------+-----------------------+ | DISCLAIMER: Nothing Is True (except this) | Martin O'Nions | | ...But if you ask for a rise, it's no suprise | Logitek Group Support | | They're giving none away.... | martino@logitek.co.uk | | (Money - Pink Floyd) | 0257 426 644 | +------------------------------------------------+-----------------------+
joeld@uncecs.edu (Joel Dunn) (12/11/90)
The technique requested here is in use at UNC-Chapel Hill. Last month, the director of our office of Data and Video Communications, Jim Gogan, collected several programs and people together and did just this. In fact, I am using this right now to respond to this note. I'm not a netware guru, but if anyone wants the particulars, drop me a note (longlegs.systems@ mhs.unc.edu) or Jim Gogan (gogan.dvc@mhs.unc.edu), and we'll get you the information. In article <1770@casbah.acns.nwu.edu>, lunde@casbash.acns.nwu.edu (Albert Lunde) writes: > Does anyone know of products/protocols that can connect between Novell > networks over a TCP/IP internet? I assume that this would involve > enclosing the IPX packets in IP packets and "tunneling" them thru IP. > It seems like this _could_ be done, as we tunnel Appletalk thru IP and -- ------------------------------------------------------------------- Joel Dunn, UNC-CH ADP, 440 W. Franklin, Chapel Hill NC 27599-1150 longlegs.systems@mhs.unc.edu RJD@UNC.BITNET -------------------------------------------------------------------
wsadler@copper.ucs.indiana.edu (william sadler) (12/11/90)
lunde@casbash.acns.nwu.edu (Albert Lunde) writes: >Our campus network has various Novell networks connected to the campus >TCP/IP network, and we are using ftp and telnet and testing mail bridges >to SMTP, but no-one seems to have a way to link the Novell nets together. >Another approach that has been discussed would be getting our campus >network to route multiple protocols (IPX and IP) directly. This may be >feasible for the backbone which has commercial (cisco) routers. However, >the outlying parts of the network go thru "Morrison" PC routers and UNIX >boxes that can only deal with IP, not IPX. >Albert Lunde Northwestern University Albert_Lunde@nwu.edu We have just started routing IPX with our ciscos. So far I haven't had any problems. The backbone is 8137 and because of the new cisco ROMs you can have an 802.3 network attached to it that people running 8137 can still see. Before we had a single IPX network with separate IP networks (i.e. we were routing IP but not IPX). Now we are routing both. Too bad about your Morrison PC Routers or it could work great. Will ********************************************************************** *Will Sadler Indiana University Law School-Bloomington * *will@ogre.cica.indiana.edu wsadler@copper.ucs.indiana.edu * **********************************************************************
mitsu@well.sf.ca.us (Mitsuharu Hadeishi) (12/11/90)
Hmm, if all you want is to run TCP/IP and Novell at the same time on the same wire, this is quite easily done, as they coexist with no problem at all. We have a tiny TCP/IP and Novell network both running at the same time with no special software. Hooked to this network is an Apple Macintosh running Mac/TCP and AppleShare, a unix machine running TCP/IP, a couple DOS machines running Novell IPX and an OS/2 machine running PC/TCP for OS/2 and Novell Netware for OS/2. Everything works fine, except the OS/2 machine has to have two network adapters because there is no Clarkson packet driver for OS/2 (FTP PC/TCP uses an NDIS driver which is compatible with 3Com and Microsoft's networking product, but not Novell). Mitsu Hadeishi Open Mind mitsu@well.sf.ca.us apple!well!mitsu
backman@vaxeline.COM (Larry Backman) (12/11/90)
> Hmm, if all you want is to run TCP/IP and Novell at the same >time on the same wire, this is quite easily done, as they coexist >with no problem at all. We have a tiny TCP/IP and Novell network >both running at the same time with no special software. Hooked to this >network is an Apple Macintosh running Mac/TCP and AppleShare, a unix >machine running TCP/IP, a couple DOS machines running Novell IPX and >an OS/2 machine running PC/TCP for OS/2 and Novell Netware for OS/2. >Everything works fine, except the OS/2 machine has to have two network >adapters because there is no Clarkson packet driver for OS/2 >(FTP PC/TCP uses an NDIS driver which is compatible with 3Com and >Microsoft's networking product, but not Novell). > FTP will be providing an ODI TCP driver at some point in the future. This will alleviate the need for 2 cards in the OS/2 machine. Sorry, but at the time we started, NDIS was out there, and ODI was vapor. To answer any follow up questions some point in the future is defined as 9 months from now at the earliest. It will not be in our 1.1 release. Larry Backman backman@ftp.com
mallsop@sunc.mqcc.mq.oz.au (Mark Allsop) (12/14/90)
In article <1770@casbah.acns.nwu.edu> lunde@casbash.acns.nwu.edu (Albert Lunde) writes: >Does anyone know of products/protocols that can connect between Novell >networks over a TCP/IP internet? I assume that this would involve >enclosing the IPX packets in IP packets and "tunneling" them thru IP. > ... stuff deleted There was a mailing on the listserv group recently that would answer your question. I'll include it and ask again if listserv can be channeled into this group permanently..... ---cut here--- Hello All, Today, I got the following announcements from Novells Account Manager: 'Netware 2.20 will ship somewhere in the first quarter of 1991'. The TCP/IP product manager told me the following: 'The TCP/IP NLM will NOT be released by the end of this year. However, the product is nearly finished, and we DO want to sell it. It will probably be released in the first half of 1991'. This TCP/IP NLm will offer the following functionalities: 1. It will make the Netware server act as an NFS SERVER using TCP/IP protocols (no NFs client software announced yet!) 2. It will allow the 'encapsulation' (Novell calls it 'tunnelling') of IPX packets in TCP/IP packets for routing throug TCP/IP internets. Greetings, Bruno --- ZMailQ 1.10 @2:292/500.21503 * Origin: The NETWARE Wizzards (2:292/500.21503) -- Bruno Vandevelde Internet: Bruno.Vandevelde@f500.n292.z1.fidonet.org Compuserve: >internet:Bruno.Vandevelde@f500.n292.z1.fidonet.org -------------------------------------------------------------------------- +Mark. -- Mark Allsop Computer Scientist email: mallsop@suna.mqcc.mq.oz.au The Statistical Laboratory Phone: At MacUni: (61 2) 805-8592 / \ Macquarie University, Australia Fax : : (61 2) 805-7433 | This one goes up to 11.....
karinc@isc.intel.com (Karin Coffee) (12/15/90)
In article <wsadler.660865175@copper> wsadler@copper.ucs.indiana.edu (william sadler) writes: >lunde@casbash.acns.nwu.edu (Albert Lunde) writes: > >>Our campus network has various Novell networks connected to the campus >>TCP/IP network, and we are using ftp and telnet and testing mail bridges >>to SMTP, but no-one seems to have a way to link the Novell nets together. > >>Another approach that has been discussed would be getting our campus >>network to route multiple protocols (IPX and IP) directly. This may be >>feasible for the backbone which has commercial (cisco) routers. However, >>the outlying parts of the network go thru "Morrison" PC routers and UNIX >>boxes that can only deal with IP, not IPX. > > >We have just started routing IPX with our ciscos. So far I haven't >had any problems. The backbone is 8137 and because of the new cisco >ROMs you can have an 802.3 network attached to it that people running >8137 can still see. Before we had a single IPX network with separate IP >networks (i.e. we were routing IP but not IPX). Now we are routing >both. > >Too bad about your Morrison PC Routers or it could work great. We are running Excelan's LAN Workplace for DOS in conjunction with Novell. They don't combine packets, just run side-by-side on the network. In order to do this, we are using Excelan's EXOS 205T intelligent NICs, but the new version of LAN Workplace is due out in early 1991. It is supposed to work with "dumb" cards. Using Windows with Novell, I keep an open telnet session to our Sun network, and then work on the Novell network in other windows. It works well. I'm looking forward to seeing the complete Open-Data-Link from Novell where you can do TCP-IP and IPX and some other protocols at the same time through Novell. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Karin Coffee Intel Supercomputer Systems Division Network/System Administration 15201 NW Greenbrier Parkway The LAN Lords Beaverton, OR 97201 karinc@isc.intel.com (503) 629-7693 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
tom@rsp.UUCP (Thomas Ruf) (12/27/90)
lunde@casbash.acns.nwu.edu (Albert Lunde) writes: >Does anyone know of products/protocols that can connect between Novell >networks over a TCP/IP internet? I assume that this would involve >enclosing the IPX packets in IP packets and "tunneling" them thru IP. We offer such a product for NetWare 2.x. If you're interested, please contact : Schneider & Koch Inc. Phone : (415) 322 3334 Fax : (415) 322 3335 -- Thomas Ruf Schneider & Koch GmbH {uunet,mcvax}!unido!rsp!tom West-Germany
chapman@acf3.NYU.EDU (Gary Chapman) (12/28/90)
Can you explain basically how this works? Who encapsulates ipx/spx in ip and who un-encapsulates? - Gary Chapman, NYU
jbreeden@netcom.UUCP (John Breeden) (12/28/90)
In article <11090002@acf3.NYU.EDU> chapman@acf3.NYU.EDU (Gary Chapman) writes: >Can you explain basically how this works? Who encapsulates ipx/spx in ip >and who un-encapsulates? - Gary Chapman, NYU Take the WHOLE Netware datagram and stick it in a tcp-ip datagram as data. The package from Europe runs as a VAP on a server and acts just like Netware's "bridge" (why oh why does Novell call a router a "bridge", must be the same one who decided that Novell's brain dead 802.2 header quailifies as IEEE). It's the VAP in the servers that incap/unincapsulate. The advantage? Now you can use "real" routers like Cisco or Wellfleet, add HDLC, SLIP and PPP links, router management via SNMP etc, and best of all - get rid of RIP. BTW: Banyan does the same thing (encapsulation) with their "server to server tcp-ip option". -- John Robert Breeden, netcom!jbreeden@apple.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden ------------------------------------------------------------------- "The nice thing about standards is that you have so many to choose from. If you don't like any of them, you just wait for next year's model."
brian@ca.excelan.com (Brian Meek) (12/29/90)
In article <19477@netcom.UUCP> jbreeden@netcom.UUCP (John Breeden) writes: >In article <11090002@acf3.NYU.EDU> chapman@acf3.NYU.EDU (Gary Chapman) writes: >>Can you explain basically how this works? Who encapsulates ipx/spx in ip >>and who un-encapsulates? - Gary Chapman, NYU > >Take the WHOLE Netware datagram and stick it in a tcp-ip datagram as data. > >The package from Europe runs as a VAP on a server and acts just like Netware's >"bridge" (why oh why does Novell call a router a "bridge", must be the same >one who decided that Novell's brain dead 802.2 header quailifies as IEEE). >It's the VAP in the servers that incap/unincapsulate. > Novell folks are really trying to refer to NetWare 286-based internal and external "bridges" as IPX routers these days. Soon even our docs will reflect reality :-). Also, real 802.2 headers are in fact possible today with NetWare 3.1 and DOS ODI drivers (Novell has never had "brain dead 802.2 header(s)", only brain dead 802.3 headers :-). But I'm really writing this to talk about the IPX over IP encapsulation or "tunneling". The Schneider & Koch product "SK-Net IPX/IP Gateway" is actually not a VAP. It is a NetWare v2.15 LAN driver that talks to a FEP TCP/IP stack running on one of their 68000-based intelligent ethernet boards. To install it, one simply runs NETGEN or "BRGEN" with their supplied drivers and assigns an IPX LAN address to the tunnel. Configuring the IPX over IP router involves telling the LAN driver how to handle IPX broadcast requests by supplying a list of IP addresses where peer IPX routers exist. When IPX hands a broadcast packet to the SK-Net IPX/IP LAN driver, the driver wraps it up in a UDP datagram and copies it to each IP address in the peer list. One can define a list of up to 20 IPX/IP peers, last I checked. Of course, all servers / or external _IPX_routers_ must agree as to the IPX network address of the "Tunnel". Hence, the answer to Gary Chapman's question about what does the encapsulation and decapsulation is that it's a byproduct of the NetWare IPX router forwarding packets from a one IPX network to another (one of which happens to use UDP as a transport). S&K also provide IPX/IP client drivers (to use with SHGEN and create an IPX.COM file) that allow NetWare DOS clients equipped with the same board to participate in the tunnel directly. >The advantage? Now you can use "real" routers like Cisco or Wellfleet, add >HDLC, SLIP and PPP links, router management via SNMP etc, and best of >all - get rid of RIP. > Get rid of RIP? I assume you're referring to IPX-RIP since tunneling IPX within UDP has nothing to do with the IP routing protocol in use. Anyway, IPX RIP doesn't go away with this encapsulation scheme, but it does give one the ability to eliminate the broadcasting of RIP packets across IPX internets by hiding all IPX broadcasts in UDP unicasts targeted at specific IP addresses belonging to NetWare servers or IPX routers (good luck parsing that one :-). BTW: Novell views this as a reasonable approach for utilizing existing SPX/IPX based applications and connecting NetWare workgroups together across IP internets. -- brian ____________________________________________________________________________ Brian Meek Novell, Inc. - 2180 Fortune Dr. San Jose, CA 95131 Internet Mail: brian@novell.COM Phone: (408) 473-8375
forster@dustbin.cisco.com (Jim Forster) (01/07/91)
In article <2546@excelan.COM> brian@ca.excelan.com (Brian Meek) writes: Configuring the IPX over IP router involves telling the LAN driver how to handle IPX broadcast requests by supplying a list of IP addresses where peer IPX routers exist. When IPX hands a broadcast packet to the SK-Net IPX/IP LAN driver, the driver wraps it up in a UDP datagram and copies it to each IP address in the peer list. One can define a list of up to 20 IPX/IP peers, last I checked. Of course, all servers / or external _IPX_routers_ must agree as to the IPX network address of the "Tunnel". This is one of the scaling problems -- manual configuration. Not too bad for a handful of tunneling routers, but even if the limit of 20 were boosted, its not a good solution for a large network. >The advantage? Now you can use "real" routers like Cisco or Wellfleet, add >HDLC, SLIP and PPP links, router management via SNMP etc, and best of >all - get rid of RIP. > Get rid of RIP? I assume you're referring to IPX-RIP since tunneling IPX within UDP has nothing to do with the IP routing protocol in use. Anyway, IPX RIP doesn't go away with this encapsulation scheme, but it does give one the ability to eliminate the broadcasting of RIP packets across IPX internets by hiding all IPX broadcasts in UDP unicasts targeted at specific IP addresses belonging to NetWare servers or IPX routers (good luck parsing that one :-). I think Brian's got it, but to be more specific about the problems, run the numbers: if there are 20 tunneling routers, then every 30 seconds each sends a RIP update to all the others, by sending 19 separate packets accross the IP net. And it also receives 19 packets. So the 1 RIP packet per 30 seconds turned into about 20 every 30 seconds, or almost 1 per second. And the IP net sees about 12 per second (20*20/30). Stated another way, this is an N**2 (N-squared) solution, which is not good. BTW: Novell views this as a reasonable approach for utilizing existing SPX/IPX based applications and connecting NetWare workgroups together across IP internets. Well, I suppose if thats all you can manage, it certainly would be useful, but with "'real' routers" and native IPX packets, its much more straightforward, and you still have SNMP, HDLC & FDDI links, etc. Jim Forster cisco Systems
tom@rsp.UUCP (Thomas Ruf) (01/08/91)
forster@dustbin.cisco.com (Jim Forster) writes: >This is one of the scaling problems -- manual configuration. Not too bad >for a handful of tunneling routers, but even if the limit of 20 were boosted, >its not a good solution for a large network. The manual configuration could easily be avoided by adding redundant configuration servers. >I think Brian's got it, but to be more specific about the problems, run the >numbers: if there are 20 tunneling routers, then every 30 seconds each >sends a RIP update to all the others, by sending 19 separate packets >accross the IP net. And it also receives 19 packets. So the 1 RIP packet >per 30 seconds turned into about 20 every 30 seconds, or almost 1 per >second. And the IP net sees about 12 per second (20*20/30). >Stated another way, this is an N**2 (N-squared) solution, which is not good. It's only N**2 if all the routers are neighbors of each other. By building a tree shaped hierachy of routers, it can be reduced to N - at the cost of additional hops in some paths. But Jim is right: our IPX/IP tunneling doesn't scale well - that's the reason we felt a limit of 20 peers *per router* would be appropriate. Meanwhile we increased this limit from 20 to 120 - due to customers requirements. However, when we designed the IPX/IP tunneling, we decided to keep it as simple as possible - if *IPX* doesn't scale well, why should the tunnel ? Thomas -- Thomas Ruf tom@rsp.de Schneider & Koch GmbH Schneider & Koch, Inc {uunet,mcvax}!unido!rsp!tom Germany Palo Alto