Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!npd.novell.com!excelan!brian
From: brian@ca.excelan.com (Brian Meek)
Newsgroups: comp.sys.novell
Subject: Re: Encapulation of Novell IPX packets over TPC/IP networks?
Summary: A useful practice... not a panacea.
Message-ID: <2546@excelan.COM>
Date: 29 Dec 90 00:24:46 GMT
References: <1044@rsp.UUCP> <11090002@acf3.NYU.EDU> <19477@netcom.UUCP>
Sender: news@excelan.COM
Reply-To: brian@ca.novell.com (Brian Meek)
Organization: Novell, Inc., San Jose, Califonia
Lines: 61

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