Olaf Kirch - Linux Network Administrator Guide, Second Edition

The command shown would add a route to the remote IPX network 203a41bcvia the router on our local network 31a10103with node address 00002a02b102.

You can find the node address of a router by making judicious use of the tcpdump command with the -e argument to display link level headers and look for traffic from the router. If the router is a Linux machine, you can more simply use the ifconfig command to display it.

You can delete a route using the ipx_route command:

# ipx_route del 203a41bc

You can list the routes that are active in the kernel by looking at the /proc/net/ipx_route file. Our routing table so far looks like this:

# cat ipx_route

Network Router_Net Router_Node

203A41BC 31A10103 00002a02b102

31A10103 Directly Connected

The route to the 31A10103network was automatically created when we configured the IPX interface. Each of our local networks will be represented by an /proc/net/ipx_route entry like this one. Naturally, if our machine is to act as a router, it will need at least one other interface.

IPX hosts with more than one IPX interface have a unique network/node address combination for each of their interfaces. To connect to such a host, you may use any of these network/node address combinations. When SAP advertizes services, it supplies the network/node address associated with the service that is offered. On hosts with multiple interfaces, this means that one of the interfaces must be chosen as the one to propagate; this is the function of the primary interface flag we talked about earlier. But this presents a problem: the route to this interface may not always be the optimal one, and if a network failure occurs that isolates that network from the rest of the network, the host will become unreachable even though there are other possible routes to the other interfaces. The other routes are never known to other hosts because they are never propagated, and the kernel has no way of knowing that it should choose another primary interface. To avoid this problem, a device was developed that allows an IPX host to be known by a single route-independent network/node address for the purposes of SAP propagation. This solves our problem because this new network/node address is reachable via all of the host interfaces, and is the one that is advertised by SAP.

To illustrate the problem and its solution, Figure 15.1 shows a server attached to two IPX networks. The first network has no internal network, but the second does. The host in diagram Figure 15.1 would choose one of its interfaces as its primary interface, let's assume 0000001a:0800000010aa, and that is what would be advertised as its service access point. This works well for hosts on the 0000001anetwork, but means that users on the 0000002cnetwork will route via the network to reach that port, despite the server having a port directly on that network if they've discovered this server from the SAP broadcasts.

Figure 15.1: IPX internal network

Allowing such hosts to have a virtual network with virtual host addresses that are entirely a software construct solves this problem. This virtual network is best thought of as being inside the IPX host. The SAP information then needs only to be propagated for this virtual network/node address combination. This virtual network is known as an internal network . But how do other hosts know how to reach this internal network? Remote hosts route to the internal network via the directly connected networks of the host. This means that you see routing entries that refer to the internal network of hosts supporting multiple IPX interfaces. Those routes should choose the optimal route available at the time, and should one fail, the routing is automatically updated to the next best interface and route. In Figure 15.1, we've configured an internal IPX network of address 0x10000010and used a host address of 00:00:00:00:00:01. It is this address that will be our primary interface and will be advertised via SAP. Our routing will reflect this network as being reachable via either of our real network ports, so hosts will always use the best network route to connect to our server.

To create this internal network, use the ipx_internal_net command included in Greg Page's IPX tools package. Again, a simple example demonstrates its use:

# ipx_internal_net add 10000010 000000000001

This command would create an IPX internal network with address 10000010and a node address of 000000000001. The network address, just like any other IPX network address, must be unique on your network. The node address is completely arbitrary, as there will normally be only one node on the network. Each host may have only one IPX Internal Network, and if configured, the Internal Network will always be the primary network.

To delete an IPX Internal Network, use:

# ipx_internal_net del

An internal IPX network is of absolutely no use to you unless your host both provides a service and has more than one IPX interface active.

IPX is commonly used to mount NetWare volumes in the Linux filesystem. This allows file-based data sharing between other operating systems and Linux. Volker Lendecke developed the NCP client for Linux and a suite of associated tools that make data sharing possible.

In an NFS environment, we'd use the Linux mount command to mount the remote filesystem. Unfortunately, the NCP filesystem has unique requirements that make it impractical to build it into the normal mount. Linux has an ncpmount command that we will use instead. The ncpmount command is one of the tools in Volker's ncpfs package, which is available prepackaged in most modern distributions or in source form from ftp.gwdg.de in the /pub/linux/misc/ncpfs/ directory. The version current at the time of writing is 2.2.0.

Before you can mount remote NetWare volumes, you must ensure your IPX network interface is configured correctly (as described earlier). Next, you must know your login details on the NetWare server you wish to mount; this includes the user ID and password. Lastly, you need to know which volume you wish to mount and what local directory you wish to mount it under.

A simple example of ncpmount usage looks like this:

# ncpmount -S ALES_F1 -U rick -P d00-b-gud /mnt/brewery

This command mounts all volumes of the ALES_F1 fileserver under the /mnt/brewery directory, using the NetWare login rick with the password d00-b-gud.

The ncpmount command is normally setuid to root and may therefore be used by any Linux user. By default, that user owns the connection and only he or the root user will be able to unmount it.

NetWare embodies the notion of a volume , which is analogous to a filesystem in Linux. A NetWare volume is the logical representation of a NetWare filesystem, which might be a single disk partition be spread across many partitions. By default, the Linux NCPFS support treats volumes as subdirectories of a larger logical filesystem represented by the whole fileserver. The ncpmount command causes each of the NetWare volumes of the mounted fileserver to appear as a subdirectory under the mount point. This is convenient if you want access to the whole server, but for complex technical reasons you will be unable to re-export these directories using NFS, should you wish to do so. We'll discuss a more complex alternative that works around this problem in a moment.