These questions are addressed in this document:
1. What do you mean by "routing IPX"?
3. What are Ethernet Frametypes?
4. How are IPX network numbers assigned?
5. What are "external" IPX network numbers?
6. Can I load two Ethernet frametypes in my server? in my client?
10. Which subnets are currently routing IPX?
11. Which are not? and when will they start?
16. How did DCNS reach the decision to route IPX vs. some other solution like NetWare/IP?
1. What do you mean by "routing IPX"?
IPX (Internetwork Packet eXchange) is the suite of network protocols natively used by NetWare servers and clients. Until August 1994 IPX packets were not recognized by campus routers and were therefore dropped. (Prior to August 1994 several departments had configured NetWare server-to-server IP tunnels in order to overcome this limitation. See Q12 for more information about NetWare IP Tunnels.) After careful evaluation, DCNS decided to support IPX routing on the campus network. These means that campus routers can recognize IPX packets and will forward them, as necessary, across the campus backbone. As part of this functionality, campus routers keep a table of routes to IPX networks and readvertise these routes according to the IPX RIP (Routing Information Protocol) specification. In this sense, routing IPX is similar to routing IP (Internet Protocol). As IPX routers, the campus routers also maintain a table of services, e.g., file servers, print servers, etc., and readvertise the location of these services using IPX SAP (Service Advertising Protocol).
Strictly speaking, only routers "route" and forward IPX packets. But the term 'routing IPX' has become a short-hand way of referring to the new service; and as a result servers, subnets, and routers are said to 'route IPX'. More accurately servers and subnets are participating in the campus IPX internetwork.
There are two configuration requirements for participation in the campus IPX internetwork: standard IPX network numbers and Ethernet_II frametypes on NetWare servers and clients.
IPX Network numbers: Your server is configured with internal and "external" IPX network numbers. Throughout the campus IPX network numbers two rules must be followed regarding IPX networks:
1. Different networks must be assigned different numbers.
2. The servers and routers on the same network must assign it the same number.
In order to guarantee that these rules are followed, DCNS developed an IPX network numbering scheme based on the IP address of the NetWare servers and the address of subnetworks:
A NetWare server's internal IPX network should be the hexadecimal conversion of its entire IP address. Convert each portion of the IP address (in dotted decimal notation) to hexadecimal. Concatenate the portions. E.g., convert each portion of the server's IP address (equal to 128.32.152.38): 128 decimal is 80 hexadecimal, 32 decimal is 20 hexadecimal, 152 is 98, 38 is 26. Concatenate the four hexadecimal numbers: 80209826. This is the server's internal IPX network number. This guarantees that all NetWare servers will use a unique internal IPX network number (Rule No. 1.)
Similarly convert the network and subnet portions of the IP address to obtain the external IPX network number. E.g., 128.32.152 would be 802098. In this way, all NetWare servers will agree on the IPX network number for subnet 128.32.152 (Rule No. 2). It also guarantees that no external network numbers will collide with internal network numbers.
Ethernet Frametypes: NetWare servers version 3.x and greater support four separate Ethernet framing schemes (version 2.x servers support two.) Two devices framing IPX packets in different Ethernet frame types will not be able to communicate. In order to minimize the number of Ethernet frametypes that servers must load, and to maintain compatibility with other protocols, DCNS suggests standardizing on the Ethernet_II frame for IPX in both your NetWare server and its clients.
Ethernet frametypes are the way network packets are packaged for transmission on the Ethernet. Frames are a method for defining the sender and receiver addresses and the upper layer protocol using the frame. NetWare versions 3.x and 4.x support four frametypes. They are Ethernet_II, Ethernet_802.3, Ethernet_802.2, and Ethernet_SNAP. Ethernet_II is the standard frametype for TCP/IP networks. Ethernet_802.3 is an incomplete implementation of the IEEE 802.3 specification, sometimes called Ethernet-Raw. Novell implemented the 802.3 header but not the fields defined in the 802.2 specification. Instead, the IPX packet begins immediately after the 802.3 fields. The Novell frametype Ethernet_802.2 is a complete implementation, i.e., it includes the 802.3 and 802.2 fields. Ethernet_SNAP includes the 802.3, 802.2 and SNAP (sub- network access protocol) fields. The following tables summarizes, for NetWare servers and clients, which network protocols are supported by which frames:
Fnrame Protocols -------------- ----------------------------------- Ethernet_II IPX and TCP/IP Ethernet_802.3 IPX Ethernet_802.2 IPX and FTAM Ethernet_snap IPX, TCP/IP, and AppleTalk Phase II
NetWare version 2.x supports only Ethernet_802.3 and Ethernet_II.
Internal IPX network numbers are based on the NetWare server IP address. IP addresses are assigned when network connections are completed, i.e., installed. If your server is using a connection but you do not know the IP address associated with it, send email to hostmaster@nic.berkeley.edu with the cable ID, building and room location and, if known, the Application for Network Service (ANS) number. (External IPX network numbers are based on the network and subnet portion of the IP address.)
NetWare manuals never actually refer to an "external" network. They use the term internal network to refer to the logical, or virtual, network within each (version 3.x and 4.x) server. The term external network is commonly used to distinguish between this virtual network and the real network, i.e., the physical network or cabling system. The external network address is configured, in NetWare servers, using the bind command, e.g., bind IPX to E2 net=8020DC. (Internal networks are specified immediately after the server name is specified.)
NetWare server version 2.x will only support one frametype at a time.
Use the Econfig command to change frametype between Ethernet_802.3 and
Ethernet_II. Version 2.x client software, i.e., compiled IPX.com, and
the packet driver version, PDIPX.com, will only support one frametype at
a time. The WSGEN diskette contains a client version of the econfig
command. Use it to change frametype between Ethernet_802.3 and
Ethernet_II. In addition, an Ethernet_II version of PDIPX.com is
available via anonymous FTP on tuna in
/pub/netware/dos_client/packet_driver.
NetWare server OS versions 3.x and greater, can load multiple frametypes and, bind IPX to multiple frametypes. Each frametype/IPX combination should be thought of as a separate IPX network even if they attach to the same physical network. If there is more than one frametype/IPX combination configured, the NetWare server will route IPX packets between them.
For example, Server A is loading Ethernet_II and Ethernet_802.3 frametypes and binding IPX to both frametypes. Server B is loading only the Ethernet_802.3 frametypes. Ethernet_II configured NetWare clients will be able to reach Server B because Server A will route their IPX packets (in Ethernet_802.3 frames) to Server B.
On the other hand, if Server A only loaded Ethernet_II frames, the two servers would be completely isolated from each other.
NetWare ODI clients can set Ethernet frametype in the net.cfg file:
Network card (MLID) section
Frame ethernet_II
Protocol IPX 8137 ethernet_II
Protocol IP 0800 ethernet_II ;protocol headings for other
Protocol ARP 0806 ethernet_I ;useful protocols
Send an email request to hostmaster@nic.berkeley.edu, (include the ANS number) requesting status of your IP address assignment and network connections. IP address assignments are typically made a few weeks in advance of the network connections. If your wish to obtain your NetWare software and install your NetWare server in advance of the network connection send email to Saskia Lund, saskia@ack.berkeley.edu.
An IPX device on your subnet, probably a third-party server, is configured with your old, non-standard IPX network number. These server devices broadcast a service to NetWare clients. They typically learn the IPX network number from a real router or server and broadcast the location of their service using this network address. If a network configuration change is made in a NetWare server, the third-party server will continue to broadcast its service using the now incorrect IPX network number. And the NetWare server console will note the misconfiguration with each service broadcast, once every 60 seconds.
Two NetWare servers (or a NetWare server and a campus router) on the same subnet and using the same frametype, must agree on the external IPX network number or both will report the error condition above.
Typical third-party server devices are not configurable. They learn their network number by listening for IPX RIP packets from 'real' IPX routers or servers. In order for these server devices to pick up the network change they must be power cycled.
Some devices can be configured, using software supplied by the device vendor. In these cases, configure the device to use Ethernet_II frames and your subnet's external IPX network number. An example of this type of device is the LANtronix EPS print server.
Version 2.x NetWare servers are configured with IPX network numbers (external only, they have no internal networks) during the NETGEN process. These servers must be recompiled, i.e., re-run the NETGEN process to change the network number.
The list of IP subnets currently routing IPX (with IPX network numbers).
The list of new subnets that will route IPX once installed.
These subnets are not scheduled to route IPX at this time.
IP Subnet ---------- 128.32.2 128.32.10 128.32.117 128.32.118 128.32.119 128.32.121 128.32.129 128.32.188 128.32.197 128.32.216 128.32.217 128.32.231 128.32.234 128.32.236
Most of the EECS subnets in Cory and Soda halls are routing IPX at this time:
IP Subnet IP Subnet ---------- ---------- 128.32.32 128.32.130 128.32.33 128.32.131 128.32.34 128.32.132 128.32.35 128.32.133 128.32.36 128.32.137 128.32.37 128.32.138 128.32.38 128.32.139 128.32.39 128.32.140 128.32.40 128.32.149 128.32.41 128.32.150 128.32.42 128.32.153 128.32.43 128.32.156 128.32.44 128.32.168 128.32.45 128.32.171 128.32.46 128.32.199 128.32.47 128.32.201 128.32.93 128.32.240 128.32.103 128.32.244 128.32.111 128.32.253 128.32.112
Until IPX routing is available, DCNS will help you set up an IPtunnel from your NetWare servers or clients to the DCNS NetWare server, UTURN. If you would like to setup a temporary IPtunnel please contact Saskia Lund, saskia@ack.berkeley.edu.
The DCNS NetWare server has become the campus IPtunnel hub, of sorts. We would prefer all departments that need to run an IPtunnel to run it to UTURN. This gives DCNS the advantage of identifying IPtunnel routes when trouble-shooting the network. It can also mean unloading that task from your NetWare server.
Yes. Please provide the following information: subnet(s) of NetWare client and server, status of your server, whether the client can attach to any NetWare server, whether the client is able to use TCP/IP applications, and any configuration changes made recently in either your NetWare client or server.
Any NetWare client (using the Ethernet_II frame and on a subnet where IPX is routed) will be able to see your server. NetWare is a fairly secure operating system by default and contains many tools for verifying security and increasing it. There is a lengthy discussion of security in the NetWare Concepts manual.
DCNS evaluated and tested IPX routing and NetWare/IP for the better part of a year. We were evaluating how to enable departments to use and share NetWare resources easily and seamlessly across physical network boundaries. In August 1994 the decision was made to route IPX on the campus backbone. The conclusion follows or see the complete proposal to route IPX, August 1994.
DCNS had maintained a policy of routing only a single, non-proprietary network protocol across the campus backbone. All campus routers were configured to route and forward TCP/IP packets only. IPX-based communication (and, therefore, departmental NetWare servers) were isolated on local subnetworks.
We tested the Novell product NetWare/IP, which allows NetWare services to operate on the TCP/IP protocol suite rather than the IPX protocol suite. We also obtained and tested the IPX module for the campus routers. Both of these solutions allow NetWare resources to be shared across the campus network -- only NetWare/IP complied with the single protocol standard for the campus backbone.
There were several relevant issues in evaluating the two solutions for integrating NetWare services with the Berkeley campus network. These issues range from the pragmatic to the philosophical. They are: support, cost, performance, the costs of heterogeneity, internetwork context, and the use of proprietary protocols vs. promoting non- proprietary protocols.
Neither solution was ideal. NetWare/IP was imperfect because it could not integrate 100% of current services and clients. However, it would maintain homogeneity of the campus network infrastructure and promote non-proprietary standards and solutions. The current problems with NetWare/IP are likely to improve with time, particularly if the network market demands it from both Novell and vendors of third-party server products. This solution also required significant resources from individual departments.
Routing IPX was the only solution that met the current needs of the campus NetWare users. It is a simpler model for providing connectivity between NetWare services and clients. This solution requires significant resources from only one department, DCNS. Within DCNS, the demand on DCNS's Network Services group would have been similar no matter which solution was implemented. However, routing IPX has increased the load on DCNS's Network Operations and Development group.